Excerpts from Brian E Carpenter at 09:41:25 +1300 on Wed 10 Dec 2008:
> > After a lot of arguing with others, I've come to see the
> > similarities wrt "locator/identifier split". Look at it this way:
> > the difference is one of granularity. An endpoint-based LIS
> > separates an identifier for a stack in that endpoint from its
> > attachment point(s) to the topology. A network-based LIS splits a
> > whole chunk of "identifiers" from its attachment point(s) to the
> > topology. LISP calls those EID prefixes. Vince Fuller suggested
> > having EID stand for "end site identifiers". Sometimes the
> > "identifiers" within those chunks are also used by forwarding
> > functions as locators within the scope of the final site, but they
> > need not be (see GSE, ILNP etc.).
>
> This is true and it shows the risk of trying to use a concept
> loosely.
>
> I've said this from the beginning but I'll try once more: I get much
> less confused about LISP if I use different terminology, because the
> LISP "EID" is not an EID. Think of it as a local locator (which also
> happens to be globally unique) and call it LOC0 for example.
A LISP EID names a network attachment point. It is a locator with
global uniqueness but potential use by routing and forwarding is local
(near the beginning and end of a packet's path).
> Then the LISP "RLOC" is a less local locator that just happens to be
> globally routable as well as globally unique;
You need to be specific on "less local locator". That's a question of
the functions that use it as input, not a property of the thing itself.
A LISP RLOC is a locator with global uniqueness, just like an EID, but
potential use by routing and forwarding is "less local".
> call it LOC1 for
> example. As HAIR points out (and I pointed out last year) the
> obvious conclusion is a recursive model with any number of layers of
> locator scope.
HAIR has other issues, but let's go there tomorrow :-). But yes you
can add another level. The big question there is, if you have enough
of a scaling problem that another level of indirection looks
attractive, is that the right solution? Perhaps just sticking with
the one level of indirection and using other means to reduce
rate*state is better. TBD. First let's get some experience with one
level (or none, depending on how things work out).
> GSE/ILNP and HIP are deeply different in that they genuinely
> separate a unique *non-locator* ID from one or more locators. Trying
> to use the phrase "loc/id split" to cover both of these models is
> certain to lead to confusion.
This seems to be a good time to reiterate a rant. The names of things
("it's a locator! No, it's a floor wax!") don't matter nearly as much as
* what they name
* the scope of that naming
* how they are used by the functions performed at various points
ILNP and GSE identifiers name devices. They might name network
attachment points. They are not guaranteed to be globally unique but
they are carried in every packet and are used by forwarding in the
destination network. They only way they are not locators is that they
are not topologically aggregatable into forwarding directives, so
routing doesn't use them. HIP HIs are globally unique but are not
carried in every packet (HITs are). They are not used by routing or
forwarding anywhere.
I don't think we can divide all of this up into simple categories like
"locator" or "identifier". We can say "it's a locator" as shorthand for
"a forwarding function uses it as a forwarding directive" but we almost
_always_ get into trouble when we do so.
By the way there are three categories of identification functions that
are relevant here
* access authentication
* initial location of a correspondent
* session authentication and control
Enough mumbling for the moment. Your point about LISP EIDs is correct
but we have to be careful about trying to classify everything into just
two buckets.
Scott
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
