Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces

[Robin Whittle <rw at firstpr.com.au>]

Short version:  I think these I-Ds contain incorrect usage of the
                term "namespace":

          http://tools.ietf.org/html/draft-farinacci-lisp-12
          http://tools.ietf.org/html/draft-lewis-lisp-interworking-02

                Maybe "address range" would be better.

                A NANOG presentation, IETF Journal article and a
                mailing list message contain incorrect statements
                about LISP creating separate namespaces for RLOC and
                EID addresses - but they can't be updated.

Hi Dino,

You wrote:

>>> Robin, you can have n namespaces with the same AFI value. RFC 2547 VPNs
>>> is an example of this. And there are plenty more examples as well.
>>
>> Maybe so, but this is nothing to do with LISP.
> 
> But that is how you'd implement an EID namespace that doesn't overlap
> with an RLOC namespace.
> 
> You could use, say 10.1.1.1 in both namespaces to mean two different
> things. That is, an address used as an endpoint TCP connection
> identifier and the other to number a CE/PE link from a PA-block on a CPE
> router.

Within the IPv4 namespace, which encompasses 0.0.0.0 to
255.255.255.255, there are RFC 1918 regions 10/8, 172.16/12 and
192.168/16 which do provide a separate namespace for every private
network which uses such space.

I think what you wrote:

  1 - Has nothing to do with anything I have ever read about LISP.

  2 - Is of no practical value since LISP is intended to be a
      scalable routing solution and since EID addresses must be
      globally unique - as must RLOC addresses.

  3 - Wouldn't work anyway, even within an ISP, ignoring the rest of
      the Net, since internal routers can't tell anything about
      which namespace context you might intend for a packet whose
      destination address is within 10/8.  You are using the same
      address range for two namespaces, which is fine in principle,
      but can't work without modified routers and an extra bit in the
      IPv4 header to communicate which namespace the address should
      be interpreted according to.

      Your example would allow traffic packets from one host being
      sent to a second host with a destination (EID) address of
      10.1.1.1 and packets being tunneled by an ITR to an ETR where
      the ETR has an "RLOC" address of 10.1.1.1.  (Also, an ITR
      having 10.1.1.1 and an ETR sending it a packet.)

      Ordinary routers and hosts wouldn't know or care.

      But you can't make ITRs work.  ITRs advertise EID prefixes,
      in this case 10/8.

      An ITR would accept any packet addressed to a 10/8 address as
      a traffic packet with a destination address which matches an
      EID prefix.  The ITR would therefore look up the mapping for
      10.1.1.1 and encapsulate it to a 10/8 address in an effort to
      tunnel it to an ETR.  Then the emitted packet, if it ever left
      the ITR, would be routed straight back to the ITR and be
      encapsulated again because it matches the EID prefix which the
      ITR advertises!


I think you and your colleagues were mistaken in the use of the term
"namespace" in the I-Ds, presentation and mailing list message I
cited and quoted:

  LISP WG: Loc/ID separation - not separate namespaces
  http://www.ietf.org/mail-archive/web/lisp/current/msg00273.html

It is too late to change the mailing list messages and the
presentation.  In those, there were explicit statements about LISP
creating separate namespaces for RLOCs and EIDs.

I think you should correct the two I-Ds I cite:

   http://tools.ietf.org/html/draft-farinacci-lisp-12

     Versions 08, 09, 10, 11 and 12 since I first pointed out
     this LISP "namespace" problem on 2008-06-27.

   http://tools.ietf.org/html/draft-lewis-lisp-interworking-02

     Versions 01 and 02 since 2008-06-27.

In neither of these I-Ds is there a statement that two separate
namespaces are being created.  I think the problem is that you are
using the word "namespace" when something like "address range" would
be the correct term.

So these are simple corrections.

But first, I think you would need to agree with me that LISP, if it
is to be useful on a global basis as a routing scaling solution,
cannot create separate namespaces for RLOCs and EIDs, because both
types of address need to be part of the existing namespaces of IPv4
or IPv6 in order for them to be:

   Useful to unmodified hosts as EID addresses.

   Useful as RLOC addresses, which requires that the existing
   global routing system be able to carry carry packets with such
   source and destination addresses to and from all the world's
   ITRs and ETRs.

With LISP (and likewise with APT, Ivip and TRRP) "separation" is
creating separate regions of the existing address space, which only
ITRs and ETRs need to know about.  Ordinary routers and hosts treat
packets with these addresses as they always have.

All these architectures are core-edge separation architectures, with
the new kind of address space for end-user networks (EID space for
LISP, Scalable PI micronet space for Ivip) being in specific prefixes
known to all ITRs and the mapping system.  The remaining addresses
are "core" addresses, known in LISP as "RLOC" addresses.


In June 2007, I mistakenly using "anycast" as part of Ivip's "Anycast
ITRs in the core".  One of the LISP team mentioned this to me several
times and I finally got it, renaming them "Open ITRs in the DFZ" in
March 2008.  I appreciate his efforts to improve Ivip.  Now I am
returning the favour for LISP.

  - Robin