Subject: Re: [lisp] [ipdir] LISP WG

From: [email-masked] (Noel Chiappa)
Date: Fri, 13 Mar 2009 14:12:21 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > I am concerned about the accuracy of calling this mechanism an
    > ID/Locator split mechanism

Well, if it is not intended to separate location and identity, what's the
point of creating a mapping database, to maintain maps from one namespace to
another? And two of the capabilities it explicitly provides/supports are
provider independence and multi-homing - two things for which separation of
location and identity are generally held to be fairly crucial.

If one has to pick one _short_ phrase to describe the goals and point of
LISP, it is indeed 'separate location and identity'. Only when one gets to a
longer description does one have the room to add the complex caveats of 'not
complete separation _in the initial stages_, because initially LISP EIDs
still retain some location semantics, and also name interfaces as opposed to
stacks'.

Yes, it is not absolute separation of location and identity (at least in the
short term), but that is because LISP made the strategic choice to support
_unmodified hosts and site-local routers_ - and since conflation between the
two concepts is deeply embedded into the code in those classes of devices,
it's therefore inevitable that one won't get a perfect split (at least, in
the short term).

I do think it's a good idea to carefully point out those limitations clearly,
and fairly early on in any writing about LISP, but at the same time, what
other _short_ description of the goals and mechanism of LISP is appropriate?

    > it does not actually separate IDs and Locators within the edge network.

Not initially, no (and it would be good to say so clearly). However, as the
boundary between the mapped/un-mapped portion of the network gets closer to
the host, the location semantics leaches out of the LISP EID, and when the
boundary reaches the host's first-hop router, it's entirely gone.

Getting rid of the interface naming semantics will be harder - that can't
really be done without host changes. However, it is a possible long-term
evolutionary step.

    > As just one small example, if we had a true ID/Loc split mechanism, a
    > host could maintain a constant ID as it moved throughout the network,
    > somehow updating the ID/locator mapping as it moved. However, that is
    > not a property of LISP EIDs.

If things get to the point where LISP mapping happens at all first-hop routers
within domains (as posited above), this capability would in fact be available
_without any host changes_ (assuming, as you point out, that the mapping could
somehow be updated), or indeed _without any changes to LISP itself_.

I would therefore argue that to the extent such movement _anywhere_ is not
possible (because some domains haven't converted internally), then that
limitation is in fact a deployment issue, and not an _architectural_
limitation of LISP itself.

	Noel

---

From: Robin Whittle <[email-masked]>
Date: Wed, 18 Mar 2009 11:58:23 +1100

(I am replying to Noel's "Re: [lisp] [ipdir] LISP WG" message.)

Short version:       Neither LISP nor any of the other core-edge
                     separation approaches to the routing and
                     addressing scaling problem involve separate
                     namespaces for "locators" and "identifiers".
                     The nature of the "split" is operational.

                     While the proposed LISP charter does not
                     mention namespaces, there is a danger that
                     without clarification, the erroneous notion
                     of separate namespaces in LISP etc. will
                     be propagated.  This is especially the case
                     since several LISP-ALT documents explicitly
                     claim that there are separate namespaces.

                     I raised this critique in March 2008 and still
                     people are mentioning separate namespaces for
                     EIDs and RLOCs as if this is an accepted truth.

Noel wrote, in part:

> another? 

In LISP, RLOC addresses and EID addresses are not in separate
namespaces.  Assuming IPv4 for the discussion, both RLOC and EID
addresses are within the 32 bit IPv4 namespace.

I am unable to find an authoritative definition of the term
"namespace" but these strike me as pretty good:

  http://en.wiktionary.org/wiki/namespace

    (computing) A conceptual space that groups classes, identifiers,
    etc. to avoid conflicts with items in unrelated code that have
    the same names.

 http://en.wikipedia.org/wiki/Namespace

    ... an abstract container providing context for the items
    (names, or technical terms, or words) it holds and allowing
    disambiguation of items having the same name (residing in
    different namespaces). ...

The "split" referred to in LISP's name involves classifying some
IPv4 addresses into "EID" addresses and others (the remainder?) into
"RLOC" addresses.  I think this is fine, but I agree with the
critique that other approaches, such as HIP, have a stronger claim
to being a system which truly splits Locator and Identifier addresses.

LISP's "split" is an operational matter.  An ITR will recognise some
addresses as being RLOCs and others as EIDs.  (Ordinary routers or
hosts need make no such distinctions.)

EIDs and RLOCs are still within the single IPv4 namespace.

Arguably, a true split would be a conceptual one - which HIP
certainly does - into two separate namespaces for RLOC and EID
addresses.

In principle, it would be possible for both RLOC and EID addresses
to be in separate namespaces while both being 32 bit integers.
However, then each such address would need to come with sufficient
context for the device to know which namespace to interpret these
bits within.

If IPv4 LISP really had separate namespaces for EID and RLOC, then
the number 1.2.3.4 would mean one thing in the EID namespace and
another in the RLOC namespace.

It is probably too late to change LISP's name.  However, I think
there should be a truth in labelling notice in all LISP documents
that the "split" referred to is an operational matter within the
IPvN namespace, and not the creation of two separate namespaces.
Furthermore, I think it would be good to note that HIP and I guess
other proposals really do split addressing into two separate
namespaces for identifier and locator.

Below my signature are some links to prominent items which appear
when searching for:

  LISP split EID RLOC namespace

These include some I-Ds and other material from the LISP-ALT team
which erroneously state that LISP involves two separate namespaces.

  - Robin             http://www.firstpr.com.au/ip/ivip/

http://www.google.com/search?hl=en&as_q=LISP+split+EID+RLOC+namespace

LISP documents referring to 2 namespaces
----------------------------------------

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

   Another approach is to have the ITR not encapsulate a multicast
   packet and allow the the host built packet to flow into the core
   even if the source address is allocated out of the EID namespace.

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

   EID Sub Namespace:  A power-of-two block of aggregatable locators
   set aside for LISP interworking.

   PTRs (Proxy Tunnel Routers) attract traffic by announcing the
   LISP EID namespace into parts of the non-LISP-speaking global
   routing system.

http://www.isoc.org/tools/blogs/ietfjournal/?p=158
http://www.isoc.org/tools/blogs/ietfjournal/wp-content/uploads/2007/10/IETFJournal0302.pdf

   IETF Journal Vol 3 Issue 2 2007-10  David Meyer

   Most of the existing routing and addressing proposals leverage
   the one or more levels of indirection inherent in the ID/Locator
   separation idea to create one or more new namespaces. In most
   cases, two namespaces are utilised. One namespace-the End-point
   Identifiers (or EIDs)-is used to address hosts. The other space,
   known as Routing Locators (or RLOCs), is used for packet routing
   across a transit domain.

http://www.nanog.org/mtg-0710/presentations/LISP-cons.pdf

   What is LISP?
   * Locator/ID Separation Protocol (LISP)
     – draft-farinacci-lisp-03.txt
   * Creates two namespaces: IDs and Locators ...

Mailing list message from LISP-ALT team referring to 2 namespaces
-------------------------------------------------------------------

http://www.ietf.org/mail-archive/web/rrg/current/msg01293.html

  Dino:   Well an EID/RLOC split adds one new namespace to address
          systems out of. That gives you more addresses on the order
          of the total addressable address space of the namespace's
          address family (IPv4 or IPv6). You could iterate to build
          multiple levels of hierarchy. Just like people have done
          with multi-level NAT.

Critiques of the notion that LISP provides separate namespaces
--------------------------------------------------------------

None of the three core-edge separation techniques which are
documented in I-Ds provide separate namespaces for "locators" and
"identifiers":

   http://www.lisp4.net
   http://tools.ietf.org/html/draft-jen-apt-01
   http://www.firstpr.com.au/ip/ivip/

This question of namespaces has been discussed before, including:

http://www.ops.ietf.org/lists/rrg/2008/msg00797.html   RW 2008-03-16

   Hi Tony (Li),

   You wrote, in part:

   > We've also accepted as axiomatic that we would like to separate
   > this functionality into two independent namespaces.  I want to
   > stress here that for the architectural result to be in any way
   > clean, independence is mandatory.  Any linkage whatsoever would
   > be a clearly suboptimal result.

   ...

   I don't think any of the map-encap approaches - LISP, APT, Ivip
   or TRRP - involves the creation of a completely independent
   namespace.  I can't imagine any incrementally deployable solution
   which would.

  (Tony's response strikes me as quite abstract and doesn't really
   tackle the critique that for LISP etc. these are not separate
   namespaces: http://www.ops.ietf.org/lists/rrg/2008/msg00817.html)

http://www.ops.ietf.org/lists/rrg/2008/msg00829.html   RW 2008-03-18
   [On "jack-down" models - independent namespaces]

http://www.ops.ietf.org/lists/rrg/2008/msg01637.html   RW 2008-06-27
   [Not separate namespaces: Loc-ID-separation, map-encap etc.]