Hi Tony, You wrote, in part:
> We've also accepted as axiomatic that we would like to separate > this functionality into two independent namespaces. I want to > stress here that for the architectural result to be in any way > clean, independence is mandatory. Any linkage whatsoever would be > a clearly suboptimal result. If this is a discussion about practical solutions, then I think incremental deployability is a principle which is more important than any other. I don't think any of the map-encap approaches - LISP, APT, Ivip or TRRP - involves the creation of a completely independent namespace. I can't imagine any incrementally deployable solution which would. I can't imagine how a "jack-down" system such as you describe could be incrementally deployable, or how the system could support the instantaeous delivery of packets the Net can do today, without prior arrangement, since you mention key pairs for session keys for encrypting the traffic. Since you ask whether this division into "jack-up" and "jack-down" covers every possible solution, and since I don't recognise the current map-encap schemes as matching "jack-down", I am trying to imagine how they match your "jack-up" description. I don't think they do. So if your problem space ignores incremental deployability as a consideration and assumes architectural cleanliness, then maybe your split is correct. However, if your solution space doesn't insist on complete architectural cleanliness, and the existing map-encap proposals would fit within this space, them I wonder whether they are within the "jack-up" class, or whether some new division is required. > In what Noel has characterized as the "jack-up" model, we would lift up the > operating Internet today, let what we think of as addresses continue to be > used, but demote them to the role of pure identifiers. We would then > install a new namespace of locators underneath it, provide a mapping between > identifiers and locators, and work out a forwarding plane adaptation so that > we only dealt with locators in the core. None of the map-encap schemes involve a truly new namespace for the ETR addresses - ETRs are located on some subset of the address space which is not itself subject to mapping by ITRs. Theoretically, one might be able to deploy the map-encap scheme to the point where no host every used a non-mapped space, and that only routers, including ETRs and BGP routers, used this non-mapped space. But in all these map-encap schemes hosts can still send packets to the ETRs, because they are addressable as ordinary IP addresses - unless some kind of filtering fence is erected everywhere to stop "hosts" sending packets to or from any device in "locator space", which might be the case with fully deployed APT. I regard the goal of complete separation of locator and identifier spaces as unnecessary and counter-productive. For instance, some hosts are part of the support system for the map-encap scheme, and they need to be on non-mapped (RLOC) addresses to avoid circular dependencies. Yet those hosts need to talk to hosts which use mapped addresses - so the idea of complete separation makes no practical sense to me. I conclude that if your solution space is limited to architecturally pure outcomes, then it almost certainly cannot include solutions which are incrementally deployable. If your solution space includes all solutions which are incrementally deployable, then I think it must include architectures which are not completely clean. I am only really interested in incrementally deployable solutions. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
