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, and AFAICT they are
quite different; the shim uses a "re-mapping" layer (which remaps the
ULIDs to alternative locators it has exchanged with the peer). But for a
generalized identifier/locator split you need a mechanism to *lookup* an
identifier to find some working locators.
The complexities of defining such a lookup mechanism is nothing that the
shim needs; the complexity is closely tied to what the identifier name
space looks like (hierarchical allocation, and HIP-style hashes are two
examples).
A complete identifier/locator split would also need to redefine what
information goes in the DNS (e.g., should we have some form of ID RRs or
not?).
If and when we have workable solutions for those pieces, we can still
reuse the shim as the mechanism for providing failover between different
locator pairs. So I don't see how *technically* doing the shim prevents
people from working on the above, hard problems.
We already have HIP exploring one way to do this (based on a flat ID
space). If folks want to explore doing it based on a hierarchical ID
name space as well.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
