I am replying to Noel and to Luigi (from the "Re: The death John
McCarthy - LISP, HIP & GSE" thread - since this discussion does not
concern John McCarthy).

I argue that LISP does not create a new namespace - so it is not a
Loc-ID Separation protocol.


Hi Luigi,

You wrote:

> My only point, may be cynical, certainly arguable, is that I do not
> see LISP rename happening.

OK - I was discussing arguments for why it should happen.

> Now please stop sending around mail with the message "Luigi thinks
> that LISP is *the* loc/id separation protocol".

I figure you are aware that GSE, HIP, ILNP and others are
locator-identifier separation protocols.  My point was that by using the
full name of the LISP protocol preceded by "the", as you did in:

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

  > Like Jari and others I do not see the name as disrespectful and
  > it is unrealistic to believe that the loc/ID separation protocol
  > can be renamed. It has been around for more than 5 years it is just
  > too late.
  >
  > On the other hand, the name  can be considered an homage by itself.

without any qualification, your words could quite reasonably be
interpreted as referring to (I wrote "seems that you are both asserting
and assuming") the LISP protocol as if it was not only a
locator-identifier separation protocol, but the only such protocol.

With the LISP protocol's current name, it seems that we have four
choices when referring it:

  1 - "LISP".  This is also a name of the programming language.  Some
       people are confused and/or upset by this usage.  (msg70213)

  2 - "LISP protocol".  I am using this from now on.

  3 - "The loc/ID separation protocol" or some variation, such as
      "The locator-identifier separation protocol", as you did.

      It is natural to prepend "the" to this - even if you don't mean
      to imply that the LISP protocol is the only such protocol.
      Without qualifications, this could reasonably be interpreted as
      implying that the LISP protocol firstly is a locator-separation
      protocol and secondly that it is either the only such protocol,
      or the only one worth mentioning.

  4 - Option 2 or 3 with some qualifications such as:

         (it is not actually a locator-identifier separation protocol)
      or (it is not the only locator-identifier separation protocol)

Options 1 and 3 cause confusion and upset.  Option 3 is very common.
Google reports ~33,500 pages use the phrase:

  "The Locator Identifier Separation Protocol"

though these numbers are not to be taken too seriously, and some of
these instances don't involve "the".  Many of these, with "the", are
written by LISP protocol developers.  Its my impression that very few,
if any, of these include a qualification that the LISP protocol is not
the only such protocol.

Option 2 is brief, but not a proper solution.  Even if LISP people
assiduously referred to "LISP protocol", many other people would refer
to it simply as "LISP".

Option 4 is unwieldy.

Changing the name to something which can't easily be mistaken for
something else in the IT field would eliminate the need to append
"protocol", and avoid further upset and confusion for LISP programming
language people.

Its not just me (who might be discounted as a class of 2007 newbie
troublemaker) who argues that the LISP protocol is not a
locator-identifier separation protocol.  Brian Carpenter (msg70160) and
some other people with much longer experience than me argue this too.


Hi Noel,

You wrote:

>>> And no, none of the LISP advocates have ever claimed that LISP was the
>>> only Locator Identifier Separation proposal or protocol.
> 
>> I think the claim is also implicit in the title of this draft:
>> 
>>   Locator/ID Separation Protocol (LISP)
>>
>> which has remained unchanged
> 
> Wow. So, according to your reasoning, RFC-1050/1057 ("RPC: Remote Procedure
> Call Protocol specification") is (or claims to be) the only remote procedure
> call protocol. Who knew?

Maybe so.  Both these note that they refer to Sun's RPC, so there's no
implication in the document as a whole that they concern the only RPC
protocol.

Unfortunately, as noted above, the current full name for the LISP
protocol is often prepended with "the", which does carry this
implication.  "The RPC protocol" appears in many documents, including
RFC-1831/5531, but this is shorthand for the particular RPC protocol
which has previously been identified.

draft-farinacci-lisp-12 refers to a variety of documents regarding
earlier work on Loc-ID Separation protocols, the first of which is your
document, from 1999 I think:

  http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt

My understanding of this is that you were proposing genuine a new
namespace for identifiers, so this is indeed work on Loc-ID Separation
protocols.

One option you contemplated was "to reinterpret the IPv4 address as an
EID".  This does not involve a new namespace.  This is how the LISP
protocol, Ivip and IRON work - so these protocols do not in fact
separate create a separate namespaces for Identifiers.

If you created a protocol with a new ID namespace using 32 bit integers,
you would be creating a system where a particular value such as
76.54.32.10 means one thing in the IPv4 IP address namespace, and
something else in the new ID namespace.  This is not what happens when
you "to reinterpret the IPv4 address as an EID".  This is not how LISP,
Ivip or IRON works.

Another reference in draft-farinacci-lisp-12 is to:

   RFC-1498 On the Naming and Binding of Network Destinations
            (Originally written in 1982)

which I think is a foundation document (or the foundation document) in
the Loc-ID Separation field, though it doesn't use such terms or propose
an actual protocol.

SHIM6 and HIP are cited as well, as "host-based solutions" and GSE as a
"router based solution", though my understanding is that implementing
GSE now would also require alterations to the IPv6 stack and to all
applications.  SHIM6 doesn't involve a new namespace, so I do not
consider it to be a Loc-ID Separation protocol.  HIP and GSE do.

Also cited is draft-meyer-loc-id-implications-01 but I didn't see any
additional references there to other Loc-ID Separation protocols.


Hosts using LISP-mapped IP addresses (EIDs) do not treat these IP
addresses differently from the current arrangements.  Unless a host does
a mapping lookup, it can't tell whether the LISP system classifies an IP
address as an EID or not.  The IP address is within either the IPv4 or
the IPv6 namespace, in which certain sub-sections are reserved to be
used as independent private network namespaces.  LISP's operation
doesn't concern those sub-sections.  It only concerns the subset of the
IPv4 range of 32 bit values which are global unicast addresses, and
likewise for the IPv6 range of 128 bit values.  (Ivip and IRON are the
same in this respect.)

LISP involves no new namespace.  (Likewise Ivip and IRON.)

76.54.32.10 interpreted as an IPv4 IP address always means the same
thing - it refers either to a physical host which responds to this
global unicast IP address, or in the case of anycast, to multiple such
physical hosts all of which receive packets addressed to this IP
address.  (This is a simplified explanation, since it assumes there is a
host on the IP address - and each such host could respond to other IP
addresses as well.)

An ITR, ETR or other elements of the LISP system may draw a distinction
between whether this 76.54.32.10 IP address is within an EID prefix
(meaning it is mapped in LISP, and the packet with 76.54.32.10 in its
destination field should be tunnelled to the ETR for the matching EID
prefix) or whether it is not in an EID prefix, in which case such a
packet should be forwarded normally.

But the subset of the global unicast address range which is treated as
"EID" is not a new namespace - because the meaning of an IP address
which is classified as an EID is still interpreted according to the same
algorithm as is used for IP addresses which are not classified as EIDs:
the one algorithm which applies to the entire global unicast address
namespace.  (The IPv4 global unicast address space is a separate
namespace from the IPv6 global unicast address space.)

The same is true of Ivip and IRON, with different terminology.

Can you argue why LISP involves a new namespace, or any other reason why
LISP should be regarded as a Locator-Identifier Separation protocol?

  - Robin

More on namespaces:  http://www.firstpr.com.au/ip/ivip/namespace/