> From: Robin Whittle <rw at firstpr.com.au>
> The "split" referred to in LISP's name involves classifying some IPv4
> addresses into "EID" addresses and others (the remainder?) into "RLOC"
> addresses.
> ...
> EIDs and RLOCs are still within the single IPv4 namespace.
If you look at the LISP Map-Reply packet format, you'll notice a field called
"Loc-AFI". (The documentation doesn't really talk about it.) Ever notice that
field, and wonder what it was there for? Any guesses as to why it is there?
To repeat yet again something I said a while back in email to the LISP list,
to many of the people working on LISP, LISP is not just what is in the current
documents, but also a long-term development path of which the current stuff is
only step 1 of about 5 - or more.
Many of the current documents contain small 'hooks' intended to be used (or
necessary) at some of these later stages - such as the one I just pointed out
above. No, it's not all written down; neither was all of TCP/IP, when we
started that, either. With limited time/energy, don't expect documents that
describe things that won't be used for years to get written now.
Also, deploying a new namespace can be a major job of work, _especially_ if it
needs to be a _structured_ namespace, which is what a new locator namespace
would need to be. (Unique identifiers picked singly and probabilistically out
of a large identifier range are a whole different, and much simpler, kettle of
fish.)
Try planning all the pieces you'd need to be able to deploy a new locator
namespace - starting with agreement on the politics of how they'd be
allocated. (Note that politics has just driven the allocation of IPv6 PI
addresses - a completely non-sensensical decision from the routing engineering
point of view.)
For the initial stages of deployment, deploying a new namespace is just a
major, and unnecessary, distraction. As the old joke goes, how do you get
down off an elephant?
Noel
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.