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

[Robin Whittle <[e-mail]>]

Short version:   The Locator functions of a LEID (LISP EID) are
                 performed differently by an ITR than the usual
                 approach.  But the destination LEID is still the
                 Locator, just as much as a non-LEID IP address.

                 There is no other Locator in the packet.

Hi Noel,

You wrote:

>> From: Robin Whittle <[e-mail]>
>
>> if the LEID destination address is for a host in a network different
>> from that of the sending host, then for part of the journey to the
>> destination host, the LEID address has its Locator semantics
>> interpreted by a new "Algorithm 2", which ITRs execute.
> 
> An LEID _has no general location semantics_.
> 
> The fact that you _always_ _have_ to do a mapping from an LEID, to get
> something that _does_ have full location semantics (the RLOC) is the surest
> sign of that.
> 
> Saying that a particular name 'has location semantics' because there's a
> mapping system that translates that name into _another_ name, one which
> _does_ unquestionably have location semantics, is totally ludicrous. By that
> reasoning, DNS names have location semantics.

OK - but from the point of view of the host which sends the packet, the
LEID IP address is like any other global unicast IP address: the routing
system uses it to get the packet to the destination.  The destination
address is both a Locator and an Identifier of the destination host.

What's different about an LEID is that it will be forwarded to an ITR
which has a different method of sending the packet closer to its
destination than the method used by ordinary routers.  That's the
Algorithm 1 method by which the ordinary routing system implements the
Location function of the destination IP address.  This information in
the FIB of each router is generated automatically as part of the routing
system, such as the DFZ BGP system.

LEIDs are part of a special subset of the global unicast address space
which is handled by an enhancement to the routing system - ITRs, ETRs
and a mapping system.  The ITR has a different algorithm for
implementing the destination IP address's Locator function.  It doesn't
use its ordinary FIB approach or directly use the best-path information
generated by the BGP or iGP control plane.  The ITR uses LISP mapping
and the ITR-style FIB to tunnel the packet to an ETR, rather than
forwarding it to a neighbour.

There's nothing explicit about the IP address:

  18.26.0.122

which says the host it identifies is in MIT.  If a router in Sydney
looks at this address, its Algorithm 1 response will be to forward it to
a neighbouring router - maybe in Sydney, maybe in Los Angeles, maybe in
Singapore.

At present, considering the contents of all the FIBs of routers around
the world, "18.26.0.122" in the destination field will cause the packet
to be sent towards MIT and eventually to the particular host known as
"mercury.lcs.mit.edu".

The BGP control plane is self-organising system exchanging information
to set up the FIBs of all participating routers.  Where the packet
addressed to "18.26.0.122" will be sent depends entirely on that
information.  Right now, it will be sent to MIT.

The LISP mapping system is a separate system where end-user networks
provide explicit information about one or more ETRs to which packets
should be sent.

If the destination address was a LEID and the ITR was in Sydney, or
anywhere else, then each ITR would use Algorithm 2 to tunnel the packet
to an ETR which would then use Algorithm 1 to forward the packet to the
destination, potentially through other routers which also use Algorithm
1.  The packet wouldn't be sent to an ITR again, because by the time it
gets to the ETR, there is a more-specific route which matches its
destination address than the default route (which would send it either
towards an ITR, or out to the DFZ and then to a PTR).

Packets addressed to "core" addresses are only handled by Algorithm 1.

Packets addressed to "edge" addresses, (LEIDs) are handled usually by
Algorithm 1 till they get to an ITR, then by Algorithm 2 at the ITR
where they are tunneled to ETR (the packet being forwarded according to
Algorithm 1 operating on the outer header's destination address) - and
then by Algorithm 1 again to the destination host.

LISP, or any other CES architecture, provides an enhancement to the
routing system, which handles an "edge" subset of the global unicast
address space as Locators, with different semantics then Algorithm 1.  I
agree it depends on a mapping system - and this mapping system doesn't
care at all about physically or topologically where the ETR is.

The CES architecture involves a different algorithm for part of the
packet's travel - with a different semantic system by which the
destination LEID address acts as a Locator.

The LEID IP address still performs as a Locator just as much as any
other non-LEID ("core" = RLOC != "edge) IP address.  This is an
important change, but still the LEID is the only destination Locator the
packet has.

CEE architectures implement Locator/Identifier Separation, which is much
more radical.  Then the packet has separate source and destination
Locator and Identifier fields.

  - Robin