Excerpts from Fleischman, Eric at 10:45:43 -0800 on Mon 1 Dec 2008: > I believe that map-and-encaps should solely be a network > infrastructure design alternative. To be effective, the hosts should > not be aware that map-and-encaps (or any other network topology > tool) exists. > > In my biased opinion this means that claims such as "LISP provides > an identifier-locator split" is fundamentally unrelated to the fact > that HIP provides an identifier-locator split. Quite obviously, HIP > does so in a manner that is real to the host (including > applications) while LISP does so in a manner that is known to > routers only. [My own bias is that LISP's claims in this regard are > marketing while HIP's claims are close to what the ROAD Group > originally intended.]
After a lot of arguing with others, I've come to see the similarities wrt "locator/identifier split". Look at it this way: the difference is one of granularity. An endpoint-based LIS separates an identifier for a stack in that endpoint from its attachment point(s) to the topology. A network-based LIS splits a whole chunk of "identifiers" from its attachment point(s) to the topology. LISP calls those EID prefixes. Vince Fuller suggested having EID stand for "end site identifiers". Sometimes the "identifiers" within those chunks are also used by forwarding functions as locators within the scope of the final site, but they need not be (see GSE, ILNP etc.). Just as source endpoints need to keep track of which destination locators are functional, ITRs maintain liveness checks for an EID prefix and forward packets to whichever locators for the EID prefix are up. When the set of locators for an endpoint identifier changes, the endpoint updates its correspondents somehow. An ETR responsible for for an EID prefix will let sources sending to that identifier know which locators are up for it (in LISP this is done with loc-reach bits). And so on. Of course there are differences -- in map-and-encap there are no higher stack layers to utilize identifiers for higher layer functions -- but I think you see the parallels. Scott _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
