Subject: Re: IPv6 Multi-homing BOF at NANOG 35

From: Dan Lanciani <[email-masked]>
Date: Fri, 14 Oct 2005 19:11:53 -0400 (EDT)

"Jason Schiller ([email-masked])" <[email-masked]> wrote:

|On Fri, 14 Oct 2005, Dan Lanciani wrote:
|
|[snip]
|>
|> IPv6 itself does nothing good for (3).  PI allocations may well be available
|> to some set of entities for a while to ease the transition, but that just
|> brings us back to routing table concerns.  There is no general PI solution
|> on the horizon, and shim6 may make such a solution less likely to appear.
|> 
|> 				Dan Lanciani
|> 				ddl@danlan.*com
|>
|Dan,
|You clearly state that PI allocations do not help the concern that
|allowing de-aggregates in the IPv6 routing table could easily scale beyond
|current hardware limitations.

I think PI allocations *create* the scaling concern.

|I think this is what you are referring
|to when you say "There is no general PI solution on the horizon..."  

Certainly I'd settle for a PI solution that does not involve putting
the PIs in a central routing table.  If (as seems to be the case) we
can't even discuss distributed routing tables that appears to require
identifier/locator separation.

|But I want to point out that ARIN does have an IPv6 PI policy proposal on
|the table for the end of October.

Yes, that's what I meant about PI being available to some entities to ease
the transition and preserve the status quo.  For a "general solution" I'd
expect availability to anyone who wants PI, and at trivial cost.  (Cost
includes cost of getting the prefix advertised.)

|This policy does not provide a solution
|to routing table growth (possibly people believe everyone's hardware will
|be capable when the time comes that we need it).  

No, people believe that PI space will be confined to large corporations who
can afford the cost.  Remember, we've been through this before with IPv4.
Provider-allocated aggregated addressing was supposed to be a temporary hack
while the hardware caught up with routing table size.  The hardware caught
up a long time ago but we never went back to generally-available PI addresses.
Instead the nature of the problem somehow changed from storage space to
computation or bandwidth or something else too nebulous to ever be solved by
hardware.

|If the ARIN IPv6 PI policy gets accepted and widely implemented that PI
|addresses are more likely to be leveraged by large commercial networks who
|are currently doing traditional IPv4 multi-homing and traffic engineering
|instead of shim6.  This may greatly decrease the support for and use of a
|shim6 solution.

Yes, though it all depends on just how available those PI allocations are.

|It seems to me that if PI has wide spread adoption then everyone will have
|to commit to solving the large routing table problem in hardware.  If we
|have already decided to solve the large routing table size in hardware
|then why do we need shim6?  

I'm not at all convinced that we need shim6 (or even that it is desirable),
but as far as I know nobody has committed to solving the large routing table
problem in hardware or otherwise.

				Dan Lanciani
				ddl@danlan.*com

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Dan Lanciani <[email-masked]>
Date: Wed, 19 Oct 2005 03:57:04 -0400 (EDT)

Erik Nordmark <[email-masked]> wrote:

|Dan Lanciani wrote:
|
|> I thought I made this pretty clear in the portions of my note which you
|> snipped, but I'll try to run through it one more time.
|> 
|> -Scalable PI space without distributed routing tables probably requires
|> a full identifier/locator split.
|> 
|> -An identifier/locator split almost certainly requires changes to existing
|> code to accommodate a mapping layer.
|> 
|> -Shim6 provides a replacement for one useful attribute of PI space (multi-
|> homing) by leveraging a partial identifier/locator split.
|> 
|> -Shim6 requires changes to existing code to accommodate a mapping layer.
|> 
|> If shim6 is deployed then one of the problems caused by the lack of a general
|> PI solution will be "solved" thus reducing the impetus to find that general
|> solution.  Deployment of shim6 requires changing a lot of existing code.
|> Convincing the world to change all the code a *second* time is going to be
|> a much harder sell.  Implementing a general solution in the presense of
|> deployed shim6 would itself be more difficult because of the interaction
|> of two very similar mapping layers.
|
|Dan,
|
|The issue I have with your description is that you assume that the 
|"mapping layers" are actually of similar complexity,

I don't think that anything I wrote above relies on such an assumption.
I believe that the existence of shim6 will discourage the deployment of
a more general PI solution regardless of their relative complexities.  The
primary reasons are logistical, but the technical issue of two similar
mapping layers (similar not in their complexity but in the type of mapping
they perform) should not be underestimated.  Shim6 need only consider
interactions (including referals) between existing vanilla stacks and
shim6-enhanced stacks.  A general solution that could be deployed in the
presense of shim6 would have to deal with interactions among all three of
vanilla stacks, shim6-enhanced stacks, and generally-enhanced stacks.

That said, I disagree with your apparent assumption that the overall
effort of deploying a general solution would be significantly greater
than that of deploying shim6.  I believe we have a combination of
underestimating the complexity of making the current shim6 work in its
own limited generality and overestimating the complexity of making a
general mapping solution work.  The latter has been debated endlessly
over the past ~15 years and there is little point in repeating the
arguments.  (Though in the past it always seemed that solutions that
involved extensive retrofits on the level that shim6 requires were not
even on the table.)  The former may not become apparent until shim6 nears
full implementation.

In any case, the deployment cost of any similarly pervasive change to
the stack has a large fixed component which is independent of the actual
complexity of the change.  This component may dwarf any difference in
complexity.  It seems a shame to waste a chance to amortize the fixed
cost over the maximum possible functionality gain...

				Dan Lanciani
				ddl@danlan.*com