Hi Noel,

I am absolutely certain that LISP as currently defined does not
involve new namespaces for Locators or Identifiers.

You wrote, in part:

>> 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?

Loc-AFI is a 16 bit field with two currently defined options: IPv4
or IPv6.

If LISP is encapsulating IPv4 EIDs to an IPv6 RLOC or vice-versa
then the EID and RLOC addresses are in separate namespaces.  However
this has nothing to do with LISP - it is because IPv4 and IPv6
addresses use different namespaces.


> 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.

My critique cites I-Ds, presentations and mailing list messages from
the LISP designers.  I can't anticipate or comment on whatever you
might think of in the future.


> Also, deploying a new namespace can be a major job of work, ...

One does not deploy a new namespace.  I think you are using the term
"namespace" at times when "addressing system", "routing system" or
similar would be more appropriate.

Anyone can invent a new namespace, simply by defining the types of
names which it encompasses and supplying a definition of how each
individual name is to be interpreted.

For example, here is a new namespace IPvBTFUSD:

   IPvBTFUSD names are 32 bit binary numbers.

   An IPvBTFUSD name is interpreted by reversing the order of the
   bits and inverting their state.  The resulting 32 bits are
   interpreted according to their accepted meaning in the IPv4
   namespace).


In the future, LISP *could* define a new namespace for RLOCs which
by prohibition or impracticality was never used for EIDs.  This
would indeed be a true case of Loc/ID separation.

To be useful in a scalable routing solution, EIDs must remain in the
namespaces recognised by hosts (IPv4 or IPv6).

You could define IPvCP [1] as an RLOC namespace, but it would be no
use in a scalable routing solution until there was firstly a global
network between ITRs and ETRs which delivered packets whose
destination addresses were specified according to the IPvCP
namespace and secondly until most end-user networks were happy with
this new network's delay and reliability.

 - Robin


[1]  IPvCP is an 84 bit addressing scheme using a namespace in
     which the bits are interpreted to provide centimetre accurate
     geographic location: 32 bits for latitude, 32 bits for
     longitude and 20 bits for elevation.

     While a scalable electronic global routing system is under
     development, initial deployment of the network involves carrier
     pigeons trained to respond to signals from skull-mounted GPS
     devices.

     This may be practical if all ETRs and ITRs could be located
     in pigeon-accessible sites.  Hosts in general cannot be
     pigeon-accessible and are frequently mobile, so any network
     which relies on the IPvCP namespace for addressing is
     unsuitable for use by hosts and therefore for carrying
     EID packets.