Subject: Re: [rrg] Mobility, Loc/ID Separation, ILNP, LISP-mn, TTR Mobility, IPv4 & IPv6

From: [email-masked]
Date: Tue, 23 Nov 2010 05:34:28 EST

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-masked]:

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: