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. --Eric _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
