Subject: RE: LISP is not a Loc-ID Separation protocol

From: [email-masked] (Noel Chiappa)
Date: Thu, 3 Nov 2011 00:20:29 -0400 (EDT)

> From: "Templin, Fred L" <[email-masked]>

    > on the subject of identifiers, Robin is right. What the IETF protocol
    > known as LISP calls "identifiers" are actually IP addresses. And, IP
    > addresses name *interfaces*; they do not name *end systems*.

I've had this same debate about 6 times, and it was boring after the first 2
or 3, but since you posted this to the main IETF list, I feel I ought to
briefly recap some of the points I have made before for the benefit of those
who haven't seen the previous N iterations.

LISP is intended for a variety of usage cases, and in _some_ the 'LEID' does
have _some_ location information (useful within a limited scope), but... in
others it has none at all. LISP is intended to work with unmodified hosts,
which means we're kind of limited in how radical a change we can make to the
semantics of various namespaces - we are not working with a clean sheet of
paper.

In at least one usage case, i) the 'LEID' is the address on an internal
'virtual' interface, and ii) _there is no route to that interface address
anywhere in the IGP/AS_. You may say 'well, it's still naming an interface',
to which I reply 'hey, it walks like an EID, quacks like an EID; it has
exactly the _semantics_ of an EID (i.e. pure identity, no location info of any
kind, cannot be used for forwarding anywhere) - what difference does it make
whether you call it a duck or an "interface address"'?

	Noel

---

From: Robin Whittle <[email-masked]>
Date: Thu, 03 Nov 2011 16:08:12 +1100

Hi Noel,

> who haven't seen the previous N iterations.

I don't recall you or anyone else arguing convincingly that LISP
protocol EID addresses are in a new namespace.

> semantics of various namespaces - we are not working with a clean sheet of

Indeed - the LISP protocol can work with unmodified host stacks and
applications, which is not the case with Locator-Identifier Separation
protocols.

> whether you call it a duck or an "interface address"'?

An EID walks and quacks like an IP address.  Hosts don't need to know an
IP address is part of the EID subset of the global unicast address
space.  Without a mapping lookup, they can't tell.  Only LISP protocol
boxes (ITRs and ETRs) take an interest in whether an a particular IP
address is within the EID subset or not.

I don't think Fred's discussion of whether IP addresses refer to
specific hosts or to particular interfaces (such as a wired Ethernet
interface of potentially many such interfaces, or a WiFi Ethernet
interface, or a serial port) is relevant to the arguments I raise.

  1 - The LISP protocol does not introduce a new namespace for
      Identifiers (for hosts, interfaces or whatever).

  2 - Therefore, it is not a Locator-Identifier Separation protocol.

I argued this for LISP-protocol-aware folks here:
  http://www.ietf.org/mail-archive/web/ietf/current/msg70239.html

and for those without a LISP protocol or scalable routing background:
  http://www.firstpr.com.au/ip/ivip/namespace/lisp-not-loc-id/

Can you or anyone else argue against either of these?

If so, then you would be able to provide a definition of "namespace"
which matches your claim that LISP protocol EIDs are in a new namespace.
 I argue that for any meaningful definition of "namespace", that the
subset of global unicast addresses which are in EID prefixes are not in
a new namespace: they remain in the global unicast namespace which
applies to all global unicast IP addresses.  (Actually, there's one such
namespace for IPv4 and another for IPv6.)

  - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 3 Nov 2011 07:00:54 -0700

Noel and others, 

Let's say we have an end system with as many ISP
connections as you like - each with its own "locator"
address. Let's say the end system also has multiple
loopback interfaces - say it has two, for example.

The end system connects to a first VPN and receives
the "endpoint" address A, which it assigns to the
first loopback interface. The end system also connects
to a second VPN and receives the address B, which it
assigns to the second loopback interface.

Which one (A or B) is the end system's identity?

Thanks - Fred
[email-masked]