>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