>From: Fleischman, Eric >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. Scott Brim and I had a private discussion concerning the impact of HIP on RLOC-EID liveness. As part of that discussion, he recommended that I forward to the list my following additional opinion concerning the above first paragraph: My suggestion in my first paragraph above was a possible extension to HIP or other EID-RLOC separation systems. HIP doesn't do liveness now in the base HIP specs. However, the HIP community is currently considering eventually possibly adopting two different liveness alternatives: using SIP's ICE for NAT traversal and SHIM6's REAP for multihoming -- I believe these proposed approaches are unacceptably resource consumptive, which is why I made the above suggestion. Regardless, HIP doesn't do either today but it currently does protect the transport layer and above from having to care about multihoming or network issues. Specifically, the session doesn't care what RLOC is used to support that session at the IP layer -- any packet duplications will be handled at the transport or application layer. It's simply not a problem. My previous suggestion (above) was how to respond to the liveness problem for HIP should the current network path fail in multihoming environments. Currently, if the routing layer doesn't have a live path to an RLOC supporting that EID, then the session is not receiving packets. If the network layer is not aware of an alternative RLOC (which is what I expect to be the norm), then it can't use that alternative remote multihomed RLOC unless it is redirected to it by a mechanism that is unrelated to routing tables (i.e., routers should only deal with RLOCs). My original paragraph above suggested a way to alert the remote peer to the existence of another RLOC supporting that EID so that it could try that alternative path. This presumes a non-symmetric routing blockage (i.e., not due to a blockage affecting all of a peer's transmissions regardless). Regardless, I believe that the id/loc split concept presumes that the session layer needs to handle multihoming and the IP layer need to handle routing between RLOCs. The two concepts (RLOC, EID) need to remain separated without becoming confused by needless dependencies. _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
