Scott, >>Eric Fleischman wrote: >> 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.
>Scott Brim wrote: >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. Thank you for sharing your insights. Concerning this specific insight, I believe that what RLOC-EID split systems like HIP primarily do is to disambiguate the semantic confusion so that routing (i.e., RLOC) issues are local to the IP layer and EID concepts are local to the HIP session layer. I fully concur with you that the IP (routing) layer is responsible to find viable paths between RLOCs, which can be challenging in the highly mobile environments in which I primarily focus. Our research has demonstrated that a key benefit of HIP in highly mobile environments is that the HIP session layer provides a buffer that shields the transport and application layers from network effects such as multihoming and mobility. Our experiments have demonstrated session persistence even within highly unstable network environments caused by substantial MANET mobility. We have demonstrated that HIP session layers simply need not care about underlying IP layer issues such as whether the underlying network is using IPv4 or IPv6. We've demonstrated HIP sessions that cleanly and transparently persisted through real-time underlying network swaps from IPv4 to IPv6 and back. In our private discussions I observed that because routing can only see RLOCs and therefore can't discern the existence of multihoming, multihoming needs to be handled at a layer that has visibility into EIDs where it can be seen. I received strong push-back on that private list to my suggestion that multihoming should be an optional service function of the session layer, perhaps using an optional timer value in the session layer to substitute a different RLOC source ID value in the underlying local IP layer if the current RLOC hasn't received any traffic in a given time quantum. I am comfortable receiving push-back on my suggestion in the previous paragraph because this idea of mine hasn't been adequately examined. What I am not comfortable with is any approach that attempts to solve multi-homing at the IP layer because I believe that routing should solely aggregate and forward packets based on RLOCs -- anything else needlessly complicates routing and harms Internet performance and scaling. Therefore, multihoming is not a function of the IP layer. I realize that this belief of mine conflicts with IETF work and thought (e.g., the domain discussed by draft-meyer-loc-id-implications-00.txt), but this nevertheless is how I see things. --Eric _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
