Subject: LISP is not a Loc-ID Separation protocol

From: Robin Whittle <[email-masked]>
Date: Sat, 29 Oct 2011 16:39:27 +1100

>From the "Re: [IETF] The death John McCarthy - LISP, HIP & GSE" thread:

Hi Luigi (and other LISP people),

I wasn't directly discussing your opinion that the LISP protocol
shouldn't have its name changed.

My objection was to referring to the LISP protocol by its formal title
"Locator/ID separation protocol" without any qualification, especially
since you preceded it with "the" - as if LISP was the only Loc/ID
Separation protocol.

Do you and other LISP folks agree that GSE, HIP and ILNP are Loc-ID
Separation protocols?  GSE was the earliest and ILNP is based on GSE.
The term was used in the title of a 1997-07-30 draft:

  Separating Identifiers and Locators in Addresses:
  An Analysis of the GSE Proposal for IPv6
  http://tools.ietf.org/html/draft-ietf-ipngwg-esd-analysis-01

Four months earlier, Version 00 included a formal definition of the
Loc/ID Separation concept - with a note that the idea had been
"conventional wisdom for some time":

    Consequently, conventional wisdom for some time has been that
    having separate values for location and identification could
    be of significant benefit. The GSE proposal attempts to make
    such a separation.

Assuming you agree that GSE, HIP and ILNP are Locator - Identifier
Separation protocols, how do you argue that LISP is as well?  LISP
operates on completely different principles.

In this debate about whether the LISP protocol should be renamed, a
vital question is whether LISP really is a Locator-Identifier Separation
protocol.

GSE, HIP and ILNP are.  They involve new host protocols and a new
namespace.  All hosts use numbers (which some people do not regard as
"addresses") from a new ID namespace to identify themselves for the
purposes of communicating with other hosts.  The routing system,
including any routing functions in hosts with more than one interface,
uses conventional IP addresses (Loc) to get packets to their
destination.  This requires a fast, secure, global mapping system so a
router or host can look up an ID's one or more current Locs.

According to some perspectives - which have apparently been well
regarded in the IETF for 14 years or more -  Loc-ID separation is
desirable, elegant and supports mobility.  However, I think it would be
a really bad idea, even if it could be easily introduced:

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

There's no prospect of transitioning to any Loc/ID Separation system
because no substantial benefits accrue until all hosts and their
application programs are upgraded to the new system.  As far as I can
tell (and apart from unsupported assertions, no-one argued otherwise)
ILNP cannot support existing applications.  GSE and HIP can't.  So all
applications would need to be completely rewritten and all operating
systems of all hosts changed to the new system before we can realise the
benefits and turn off the old system.  I argue that there are few, if
any, benefits in the transitional period where hosts and applications
have to cope with other hosts being Loc/ID capable or not (or perhaps
not being able to determine this) and therefore having to support both
communication systems at the same time, without getting the benefits
(multihoming, mobility) of using Loc/ID Separation for all traffic.

Even if Loc/ID Separation was adopted in place of the current system
("overloading" ID and Loc functions onto IP addresses, in both IPv4 and
IPv6), it would be impossible to support seamless mobility suitable for
VoIP, due to the time delays inherent in securely updating mapping
systems and in getting all sending hosts to recognise the change,
whenever the Mobile Node (MN) changes its IP (Loc) address.

The most serious critique of Locator ID Separation concerns the extra
work, including extra packets and delays, which hosts must engage in for
any communication where that the packet to be sent must not be allowed
to arrive at any host other than the one with the specified ID.  Due to
the security problems of information leakage, I think this probably
includes most Internet communication.  More on this below.

LISP, Ivip and IRON operate on completely different principles to GSE,
HIP and ILNP.  LISP, Ivip and IRON do not involve a new host protocols
(so there's no need to rewrite applications or host stacks), or a new
namespace.

  http://www.firstpr.com.au/ip/ivip/namespace/

LISP, Ivip and IRON are changes to the routing and addressing system,
which can be introduced incrementally, with full benefits of multihoming
and perhaps mobility accruing to the networks which adopt it, no matter
how few or how many other networks adopt the new system.

I believe that the current system of "overloading" the ID and Loc
functions onto a single IP addresses is a very good idea, since it
reduces the workload of host operating systems and applications and
reduces the delay times in establishing communications, compared to the
Loc-ID Separation approach.

The primary reason for this is that in the current system (or with LISP,
Ivip or IRON partially or fully adopted) the routing system can be
relied upon to either deliver a packet to its intended destination IP
address (which operates in part as the destination host Identifier) or
to drop the packet.  That is to say, the current system can be relied
upon not to deliver packet to any host other than the one with the
packet's destination IP address.  (With anycast, this can be multiple
physical hosts, but that is fine.)

A Loc-ID Separation architecture can't do this, so hosts need to go to a
lot more trouble, looking up mapping etc. before they can send a packet
to the desired host - assuming, as is commonly the case, it is important
that the packet is never delivered to a host other than the desired one.

This is argued in the above-mentioned message and in:

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

So I am arguing against Loc-ID Separation (also known as "Core-Edge
Elimination") architectures and for "Core-Edge Separation"*
architectures, which includes LISP, Ivip and IRON.

LISP and Ivip can use the TTR Mobility system to do glitch-free mobility
of the MN's IP address(es) - as is required for VoIP.

  http://www.firstpr.com.au/ip/ivip/#mobile

However, the LISP folks have never been interested in this.  LISP's
current mobility system can't support MNs behind NAT, while TTR Mobility
can work with hosts behind any depth of NATs.  IRON uses the principles
of TTR Mobility - including for non-mobile networks.

So I argue that its a good thing that LISP is not a Locator-Identity
Protocol.

I have many criticisms of LISP, such as the mobility arrangements, the
impossibility of scaling well when each ITR is required to figure out
reachability on its own, and the impossibility of building the ALT
network so it is both robust against single points of failure and
provides a path with minimal number of hops and minimal geographic
distance.

However LISP is the right kind of architecture - a Core-Edge Separation
architecture - not a Locator-Identifier Split (Core-Edge Elimination)
architecture.

  - Robin

* History of scalable routing taxonomies 2010-09-07:
  http://www.ietf.org/mail-archive/web/rrg/current/msg07307.html

http://www.ietf.org/mail-archive/web/ietf/current/msg70190.html
On 29/10/2011 12:41 AM, Luigi Iannone wrote:
> Hi Robin,
>
> Thanks, but no thanks. I do not want to be  dragged in such kind of
> discussion.
>
> I expressed my opinion, please do not  attribute to me things that I
> did not say or meant to say.
>
> Thanks
>
> ciao
>
> Luigi

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 29 Oct 2011 17:52:55 +0900

> Hi Luigi (and other LISP people),

As a member of the LISP people (I wrote an interpreter and
a compiler for 8080), your statement above is irritating.

						Masataka Ohta

---

From: Robin Whittle <[email-masked]>
Date: Sat, 29 Oct 2011 21:06:55 +1100

Hi Masataka,

I mean no offence.  I try to keep my messages brief, and it would be
tortuous to write "the LISP protocol" at every point in this discussion.

In the context of the IETF, I think "LISP" means the protocol.  I was
not discussing the LISP programming language at all.

  - Robin

---

From: John E Drake <[email-masked]>
Date: Sat, 29 Oct 2011 10:17:43 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Robin Whittle
> Sent: Saturday, October 29, 2011 3:07 AM
> To: [email-masked]
> Subject: Re: LISP is not a Loc-ID Separation protocol
> 
> Hi Masataka,
> 
> I mean no offence.  I try to keep my messages brief,
[JD] 

This is a joke, right?

> and it would be
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Robin Whittle <[email-masked]>
Date: Sun, 30 Oct 2011 06:10:51 +1100

Hi John,

Along with 30 other carelessly un-trimmed lines of little interest to

>> I mean no offence.  I try to keep my messages brief,

No.

  - Robin

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 30 Oct 2011 05:37:06 +0900

> not discussing the LISP programming language at all.

You have demonstrated that the problem is what "the LISP people"
means within IT community including, but not limited to, IETF.

Thank you and I acknowledge that your demonstration was brief enough.

						Masataka Ohta

---

From: Robin Whittle <[email-masked]>
Date: Sun, 30 Oct 2011 15:31:22 +1100

Hi Masataka,

Thanks very much for your response.

Returning to the discussion of the LISP protocol, I received the
following in an off-list message:

> And no, none of the LISP advocates have ever claimed that LISP was the
> only Locator Identifier Separation proposal or protocol.

I think this claim is implicit in the opening words of the main LISP
protocol draft http://tools.ietf.org/html/draft-ietf-lisp-15 which have
been present since version 08 of 2010-08-13:

  This document describes the Locator/Identifier Separation Protocol
  (LISP), . . .

I think the claim is also implicit in the title of this draft:

  Locator/ID Separation Protocol (LISP)

which has remained unchanged since draft-farinacci-lisp-00 of 2007-01-17.

I think the claim is also implicit in the absence of any references to
other Locator-Identifier Separation protocols: GSE, HIP and now ILNP and
lesser known RRG proposals: GLI-Split, Name-Based Sockets and RANGI.
(See RRG msg06219.)

All these Loc-ID Separation protocols involve new host protocols to
implement the central principle of Loc-ID Separation: a new (ID)
namespace for uniquely identifying hosts.  This requires a new
stack<->application interface and for all current applications to be
substantially rewritten - though ILNP is claimed not to require either.

The LISP protocol operates on totally different principles, which I
consider a good thing - as I wrote in the first message in this thread.

Does anyone have arguments as to why the LISP protocol is a Loc-ID
Separation protocol like those just mentioned?

Alternatively, does anyone argue why the definition of "Loc-ID
Separation" should be extended to include the LISP protocol's approach?
 I believe that to extend its meaning to include this approach - and
therefore the approaches of Ivip and IRON - would fudge an important
distinction and render the term meaningless.

  - Robin