Re: [rrg] No liveness requirement in the ID/Loc Split concept

["Templin, Fred L" <[e-mail]>]

Eric,

>-----Original Message-----
>From: Fleischman, Eric
>Sent: Thursday, January 15, 2009 10:42 AM
>To: [e-mail]
>Cc: [e-mail]
>Subject: [rrg] No liveness requirement in the ID/Loc Split concept
>
>Coworkers,
>
>In response to the draft-meyer-loc-id-implications-00.txt I-D, I sent
>private observations to the authors of that I-D together with a small
>subset of interested parties. Somebody (Dave Meyer??) requested that
>this private dialog should rather be moved to this email list for
>participation of the larger community. Towards that end, I would like
to
>summarize the view from my knothole about the RLOC/EID split issue to
>this list:
>
>1) Routing systems using RLOCs naturally reference RLOCs for routing
>aggregation. Every network system that I have worked with except for IP
>(e.g., OSI, SNA, BSC, XNS, etc.) instead does routing on EIDs. These
>latter systems do not recognize RLOCs.
>
>2) In historic IP, IP addresses became semantically overloaded with
both
>RLOC and EID semantics. I surmise that the IP designers originally
>thought they were doing EIDs like every other protocol then existing
but
>they actually invented RLOCs, without recognizing the implications of
>the difference. Regardless, both semantic concepts became located
within
>the IP layer. In practice this meant that EIDs were not operative for
IP
>routing at all: EID is usually NULL for traditional IP routing; EID
>primarily semantically appears for protocols operating above the IP
>layer, causing cross-layer protocol dependencies in such systems.
>
>3) IP combined the RLOC and EID concepts into a single system that
>lacked the ability to disambiguate between them. Consequently, some
>systems (e.g., routing) presumed that they were talking with an RLOC
and
>other systems presumed that they were talking with an EID. The IP
system
>didn't provide any assurance that either reference or presumption was
>actually the case (e.g., anycast). This became known as the "IP
identity
>problem", which is a fundamental and pervasive security flaw within IP
>systems that is solved by the RLOC/EID split concept (e.g., HIP).
Within
>historic IP we either locate something without identifying it or else
we
>identify it without locating it. This provides the foundation for
>"Rekhter's Law". That we cannot authoritatively know which reference is
>operative provides the foundation for the "IP identity problem".
>
>4) Multihoming is an EID concept. EID-based routing systems naturally
>and transparently support multihoming. RLOC-based routing systems
cannot
>naturally support multihoming because they lack the information to be
>able to naturally recognize the occurrence of multihoming.
>
>5) In RLOC/EID separation systems like HIP, the RLOC and EID each
occurs
>on different layers of the protocol stack. Therefore, attempting to get
>IP routing, which works on the IP layer (i.e., RLOC layer) to be aware
>of multi-homing, which occurs on the EID layer (i.e., the session layer
>within HIP), is a protocol layer violation.
>
>6) IP routing is not equipped to natively be able to do multi-homing
and
>attempts to enhance it to do so further complicate the RLOC-EID
>confusion and actively harm the Internet. Attempting to enhance routers
>to handle multi-homing inherently violates the loc/ID split concept.
The
>desired distinction between EID and RLOC needlessly becomes replaced by
>mutual dependencies between the two concepts. By adding EID
dependencies
>to RLOC, there cannot be "better aggregation in the RLOC space" because
>no RLOC space can exist. Rather, that space potentially becomes
EID*RLOC
>space, which probably represents significantly worse aggregation than
>the historic IP routing system.
>
>7) The RLOC-EID split concept therefore means that multihoming needs to
>be solved at a layer above the IP layer that can naturally see the EID.
>Attempts to simultaneously achieve a Loc/Id split and have routing
doing
>multihoming are vectors that internally war with each other. The net
>result are the types of problems identified in
>draft-meyer-loc-id-implications-00.txt, problems that cannot occur if
>the RLOC-EID distinction is done properly (i.e., RLOC and EID at
>different layers of the protocol stack).
>
>8) When RLOC-EID is done properly (e.g., like HIP where each concept
>appears on a different layer of the protocol stack), there is no
>liveness problem (nor can there be one). Rather, the "liveness problem"
>described in draft-meyer-loc-id-implications-00.txt is a generic
problem
>of map-and-encaps systems, not of RLOC-EID. The title and text of
>draft-meyer-loc-id-implications-00.txt is therefore inappropriately
>scoped as being caused by RLOC-EID when it is rather a common attribute
>of map-and-encaps. Note that LISP is a map-and-encaps system.
>
>9) It is useful to discuss both map-and-encaps and multihoming from the
>insights contained within Fred Templin's VET/RANGER/SEAL I-D trilogy.
>This trilogy discusses scalable map-and-encaps systems and indicates
how
>to resolve the liveness problem for those systems. It also provides an
>important context for describing multihoming because it identifies the
>recursive nature of the "enterprise" concept. Without leveraging the
>insights of this trilogy, multihoming may appear to mean different
>things in different contexts: Autonomous systems can be multihomed.
>Mobile platforms can be multihomed. Hosts can be multihomed. Etc. These
>different environments are recursive instances to different sized
>"enterprise" entities. Failing to realize this complicates discussions
>about multi-homing.

FWIW, this is completely consistent with the latest version of
VET that I have just posted:

http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-27.txt

but I think you will find that the new version is much more
comprehensive in terms of PI addressing, site multi-homing,
ingress filtering, routing scaling suppression, MTU robustness,
locator liveness determination, etc. etc.)

Thanks - Fred
[e-mail]

>
>--Eric
>
>
>_______________________________________________
>rrg mailing list
>[e-mail]
>http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[e-mail]
http://www.irtf.org/mailman/listinfo/rrg