Excerpts from Fleischman, Eric on Thu, Jan 15, 2009 10:42:12AM -0800: > 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.
Nor should it. IP routing itself should deal with finding paths to destinations (and forwarding should deal with forwarding individual packets). Determining that that sending to either of two apparently different destinations gets the packet to the same higher layer entity has nothing to do with routing. > 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. However, map-and-encap adds a new control and OAM relationship, between the "funnel" ingress and egress points. These are beyond the knowledge or control of endpoints, yet they promise to deliver packets, therefore they have a responsibility to find and use viable paths. They are not _just_ routers at this point. They are also endpoints in their own right. They are doing more than discovering paths and forwarding packets. Since _sites_ have multiple ingress points, multihoming applies here too, they have a responsibility to handle multihoming just as endpoint stacks do. Even if the session endpoints are already taking care of multihoming themselves, they are only capable of doing so over the choices that are given to them by the "funnel" endpoints. I don't think you can say the endpoints should take care of everything -- they can't. Anymore than the endpoints take care of everything when running over any underlying switched network. But the "funnel" endpoints do not know enough about what the session endpoints want or need -- is the endpoint already taking care of multipathing? Does it require session continuity and thus must have backup paths lined up at all times? And so on. Therefore the funnel endpoints overdo their responsibility. It's clear that pure endpoint-based multipathing, à la Shim6 REAP, cannot scale. Putting path failure detection and recovery in ITRs instead of in the endpoints can greatly reduce the number of messages flying around, but a simple approach there doesn't scale either, and without information they don't have much choice. One thing we could do is to couple them. The endpoint could periodically tell "the network" what it needs, so the network only needs to do just enough. Another thing we can do is cut back on our requirements, at least for a while. > 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. I don't see it. HIP properly removes dependency on location-based names from identification functions, but it does nothing to solve the multipath problem. You still need to find viable paths, ascertain that multiple locators refer to the same entity (difficult when one or both are moving -- rendezvous servers may be required, tsk), detect path failure and switch to another one. The same is true for Shim6, or Trilogy multipathing ... or anything where you have the chance of using multiple paths. A simple host in a simple PI-based AS can't, and therefore doesn't have a problem to solve. Adding HIP in fact makes the problem possible. > 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. I'm partway through them. Sorry for not being able to respond about this part. Scott _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
