[rrg] LEIDs, SPI & ordinary IP addresses as both IDs & Locs

[Robin Whittle <[e-mail]>]

Short version:  LISP EIDs, Ivip SPI addresses are global unicast IP
                addresses which - like any other global unicast IP
                address used by a host - function as both host
                Identifiers and as Locators, both with global scope.

                Its just that LEIDs, SPI (Scalable PI) addresses or
                whatever are part of the "edge" subset of the address
                space, created by the Core-Edge (addresses) Separation
                (CES) architecture  which involves them having a
                different method of encoding their Locator semantics.
                This different method is interpreted according to a new
                algorithm performed by special routers also provided by
                the CES architecture: ITRs.

                To get to the ITR, the usual routing algorithm is used.
                Once decapsulated at the ITR, the usual algorithm can
                take the packet to the destination host.


Hi Noel,

Further to your discussion (msg06064) of Lixia's alternative LISP
critique, you wrote:

>> Thus "EID" in LISP is not a host identifier, but IP addresses used
>> within a site for packet delivery.
>
> We keep going around and around on this.
>
> The LEID is used to identify the host, and does so across a global
> scope - in both sense of the term - i.e. it is the same everywhere
> in the network, and it is also used for that purpose everywhere in the
> network. Hosts _everywhere_ in the Internet will _always_ use that
> identifier for communicating with the host named by that LEID.

Yes.  A LEID (LISP EID) or an Ivip SPI address is exactly the same as
any other global unicast IP address in this respect.  A host may have
one or more global unicast IP addresses and (except for anycast and
fancy things which spread load over back-end servers) each unique global
unicast IP address identifies a single host.

When a host addresses a packet to a given global unicast IP address -
including an LEID or an SPI address - then, assuming there is a host
which uses this address, two things can be assumed:

  1 - The packet will probably be delivered - but may be dropped.

  2 - If the packet is delivered to a host, it will be to the one host
      which this IP address identifies, not any other.

> So it _is_ a host identifier, and is used for _more_ than just
> 'packet delivery ... within a site'; the wording above is, at best,
> misleading.

I agree.


> In _some_ cases it _also_ has location semantics, with local scope
> (i.e. that location information is _not_ useful outside that local
> scope - even though it _is_ unique). However, in other cases it
> doesn't.

This is where we disagree.  I am sure that the LEID always has Locator
semantics.  How else does a packet with a LEID in its destination field
get delivered reliably to the correct destination host, from anywhere in
the world?

Packets addressed to global unicast IP addresses - including LEIDs or
Ivip SPI addresses - all get delivered to their destination host based
on the destination IP address.  The packet carries no other information
to aid the routing system determine how to handle the packet.

In the case of an ordinary global unicast IP address - one not covered
by the Core-Edge Separation architectures ITR, ETR, mapping system etc.
(that is, not in the "edge" subset - not an LEID or an SPI address) then
the mechanism by which the routing system gets the packet to the
destination host is in principle the same at every router:

Algorithm 1

   Look at the destination IP address from the left until a match is
   found with the most specific prefix in the FIB, and use the
   information stored there to determine what to do with the packet -
   which will be forwarding out one or another interface, including
   via a LAN to another router, or eventually to the destination host.

   Here the Locator role of the IP address is being implemented in a
   particular manner, but this is not the only way the IP address could
   be used as a Locator.  In principle, the above approach could be
   used by all routers in the world, down to a /32 match, but this would
   be unscalable.  In practice, routers which match prefixes longer
   than /24 are only found in the local routing system of the
   destination network, since by convention, prefixes longer than /24
   are not propagated in the IPv4 DFZ.


>From a host HA in one end-user network (EUN-A) to another host HB in
another EUN-B, both with different ISPs:

  From HA in EUN-A to ISP-A:      Alg. 1
  In ISP-A to DFZ:                Alg. 1
  Across DFZ to ISP-B:            Alg. 1
  In ISP-B to EUN-B:              Alg. 1
  In EUN-B to HB:                 Alg. 1


In the case of a packet whose destination address is an LEID or SPI
address, Algorithm 1 is followed by conventional routers until the
packet arrives at an ITR.  Then a completely different algorithm is used
to implement the Locator function of this destination IP address:

Algorithm 2

   The ITR recognises the destination address is an LEID or SPI
   address and does a mapping lookup using the full address (assuming
   it has not got mapping already cached).

   The mapping arrives, and this enables the ITR to decide which ETR to
   tunnel the packet to.  The mapping system can work (for IPv4) down to
   a resolution of a single IPv4 address - so all 32 bits can be used
   for the IP address's role as a Locator.   This is scalable since the
   mapping system doesn't burden the DFZ control plane.

   Once the packet arrives at the ETR and is decapsulated, the ETR
   has more specific routes for its destination address which use
   Algorithm 1, as noted above, to deliver the packet to the destination
   host.

Assuming ITR and ETR functions are performed in the CE routers of both EUNs:

  From HA in EUN-A to ITR:        Alg. 1

  In the ITR:                     Alg. 2 which generates a packet with
                                         the ETR's address in the
                                         destination field.  This
                                         packet is handled by:

      (From ITR, trough ISP-A to DFZ:    Alg. 1)
      (Across DFZ to ISP-B:              Alg. 1)
      (In ISP-B to ETR:                  Alg. 1)

  ETR decapsulates original packet.

  From ETR, through EUN-B to HB:  Alg. 1


CES architectures such as LISP and Ivip do not in any way alter the
current naming model of IPv4 or IPv6:

          Role             Level           Conventional IP & with CES

          Text name  <---- FQDN
          Identifier <---] IP address
          Locator    <---]

CES architectures create a subset of the global unicast address - the
"edge" subset, known as EID space in LISP or SPI space in Ivip - in
which the Locator functionality of the IP address is implemented
differently by certain new routers: ITRs.

The LIED or SPI address is still fully compliant with the two-level
naming model of IPv4 or IPv6.

LISP, Ivip and other CES architectures do not implement
"Locator/Identifier Separation".  All CEE (Core-Edge Elimination)
architectures do - they have having two separate objects, two separate
items in packets, one to perform the Identifier role and the other to
perform the Locator role.


> The LEID does not _cleanly_ correspond to either an endpoint
> identifier or an interface locator, because depending on the
> circumstances, and because of the backwards compatibility, it can in
> some cases have mixed semantics.

I don't think "backwards compatibility" or "mixed semantics" are
accurate descriptions for what I am trying to explain.

Because LISP introduces ITRs which use the new Algorithm 2 to interpret
the LEID bits in a way which differs from the traditional router
approach of Algorithm 1.  It is arguably "architecturally unclean" to
introduce this, and ITRs, into the Internet - but compared to
introducing CEE architectures with their Locator/Identifier Separation
naming model, I argue (msg05865) that LISP, Ivip etc. is is much cleaner
and better.

> Asking whether an LEID is 'an identifier, or a locator' is thus akin
> to asking if an octagon is a square or a circle.

Indeed - a LEID is like any other global unicast IP address.  It can be
used to get a packet to a destination host and is playing the roles of
both Identifier and Locator.  Its just that the Locator role of an LEID
or SPI address relies on ITRs, ETRs and the mapping system, since
ordinary routers don't do Algorithm 1.


> If you absolutely _have_ to stuff it into either the round hole or a
> square hole, I'd say the 'endpoint identifier' one is a better fit,
> because it _always_ has identification semantics on a global scope,
> whilst on the other hand, i) in _no_ circumstances does an LEID ever
> have global location semantics (which is what I think of a locator as
> having), and ii) in _some_ circumstances it has no location semantics
> _at all_.

As a card-carrying member of the Octagon Liberation Front, I urge you
not to play along with the oppressors by trying to comply with their
conceptual framework.


> How can a thing which _always_ has endpoint identity semantics, and
> sometimes has _no_ interface location semantics, be an 'address'?

Sure it can be an "address".  It has location semantics, but they are
only able to be interpreted by an ITR using Algorithm 2.

 - Robin