Eric, >-----Original Message----- >From: Fleischman, Eric >Sent: Thursday, January 15, 2009 10:42 AM >To: [email protected] >Cc: [email protected] >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 [email protected] > >--Eric > > >_______________________________________________ >rrg mailing list >[email protected] >http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
