Erik Nordmark <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
