[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [RRG] On "jack-down" models



 

Hi Robin,

|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.


Please note that I was suggesting that was going to be part of Mark's
approach.  It's not intrinsic to all jack-down approaches.


|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.


Interesting.  So where do they fit?


|So if your problem space ignores incremental deployability as a
|consideration and assumes architectural cleanliness, then maybe your
|split is correct.


I'm interested in trying to characterize the full solution space, including
the good, the bad, and the ugly.


|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.


Well, I'd claim that they are indeed a new namespace, or at least could be
if the proposals were generalized.  To see that this is possible, consider a
case where we used some other new network layer for doing the encap.
Imagine, for example, that LISP used v6 to encap v4.  As far as I can tell,
logically, the entire proposal still works.  [Yes, I'm sure there would be
bugs, that's not what I'm after...]


|I regard the goal of complete separation of locator and identifier
|spaces as unnecessary and counter-productive.


Please note that my goal was 'independence', not separation.  I have no
problem with some nodes having points in both namespaces.  That's not a big
deal.  The interesting property to me is that one should be able to function
within one namespace without resulting in changes to the other namespace.

For example, one could embed their v4 identifier into their v6 locator.
This would create a coupling between the locators and identifiers that I
would expect would cause problems.

Tony


--
to unsubscribe send a message to rrg-request@psg.com 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