Robin, I think and hope you excluded TARA from Loc/ID Separation when you wrote the part from below. Otherwise you should think about how useful it were to give the term Loc its genuine meaning "location": With TARA a mobile host may change its CoA eventually such that the CoA's TARA-Locator changes only with respect to its square minute #, or even just with respect to its longitude and latitude seconds. The consequence: the changed TARA-locator has to be communicated well scoped just inside the unchanged square-degree geopatch (and of course to the current mobile partner). DNS update may occur with the DNS's typical speed. Robin, I voted Yes while assuming that it would not mean a switch to LISP or ILNP or anything else that creates only additional complexity to an insane (DV based) concept. Heiner In einer eMail vom 23.11.2010 10:08:12 Westeuropäische Normalzeit schreibt [email protected]:
Loc/ID Separation involves no tunneling. However, as far as I know, there's no Loc/Id Separation approach to mobility which avoids these fundamental problems: 1 - The MN (mobile node) can't be behind NAT. It needs a global unicast address (Locator) so any other host can send it packets directly, and without any preliminaries. 2 - Every time the MN (mobile node/host) changes its CoA (current "Care of Address" in the current system, in Loc/ID Sep.: "Locator") it has to do several things: a - Securely tell all its CHs (correspondent hosts) of its one or more new Locators and about which ever ones it has just relinquished. b - Securely update the centralised ID->Loc mapping system with the new Locator information so other hosts can initiate contact with it. Depending on the design of the Loc/ID Sep. architecture, this may be the same thing as DNS or the DNS server also needs to be updated. (With Loc/ID Separation, every host needs a DNS entry as well as an entry in a potentially separate ID->Loc mapping system.) Similar problems apply to the current LISP approach to mobility:
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
