Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00

From: [email-masked] (Noel Chiappa)
Date: Mon, 26 Feb 2007 19:40:27 -0500 (EST)

> From: "Henderson, Thomas R" <[email-masked]>

    > LISP is an ID/locator separation .. only in the context of a
    > particular address allocation and routing policy.
    > ...
    > .. it would be more precise to define it in terms of multiple locator
    > spaces that are tunneled over one another, for purposes of core
    > routing scalability.

This analysis doesn't seen sound to me. Here's my take on the situation.

To begin with, it's important to recognize that LISP - especially in its
early deployment stages - is just not going to provide clean *anthing*,
simply because of the "change engines while the airplane is in flight"
situation - and in particular, its desire (for good reasons) to want to be
deployable without benefit of host hanges (e.g. HIP or GSE).

So, to get a clearer picture of what LISP is actually doing, you need to
look further down the deployment path (e.g. to when the LISP functionality
is pushed down to the first-hop routers).

To turn to a more architectural analysis, the LISP EID's are "locators"
(some claim) which are i) globally unique (modulo NAT issues, let's put
that off for a moment), ii) indicate where the named entity is - in the
sense of having topology information embedded *in the name* - only within a
*very* limited scope. Moreover, to find out where, in a *larger* (global)
scope, the named entity is, you *have* to map the EID into a different kind
of name, one which *does* have more topological information embedded within
the name.

So here's my question: if I have a "locator" which globally, uniquely
identifies something, but which includes topological location information
in the name for only a limited scope, what happens in the limiting case,
where that scope is reduced to the the named entity itself? In what sense
is that "locator" a locator any more?

Now put that observation together with my first point, and when you do
that, here's what you see: as the LISP mapping functionality is pushed
closer and closer to the hosts (e.g. into the first-hop routers), the EID's
of LISP start acting more and more like real EID's.

So I think their terminology is a reasonable attempt to deal with an ugly,
complex and confusing reality. Hopefully, if things unroll the way the LISP
proponents plan for, over time things will clear up some.

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Feb 2007 00:12:26 -0800

> of name, one which *does* have more topological information  

Well said.

> is that "locator" a locator any more?

Interesting comment. I guess the outer headers will always be  
Locators and when packets reach the egress tunnel routers and the  
header gets stripped they are no longer useful. So in this case,  
these "outer addresses" are always just Locators.

But the inner header has the limited scope Locator-then-just-ID as  
you state above.

> of LISP start acting more and more like real EID's.

Yes, in this case they are used as a key to get a MAC address to  
physically forward to the last-hop system.

But I would argue in this case they are used as keys for the ARP  
cache where when they are egressing a site, they are used as keys for  
the Locator lookup.

> proponents plan for, over time things will clear up some.

And there probably will be more "devil in the details" as we proceed.

Dino