> From: Alia Atlas <[email protected]>
> So - although theoretically the value A can be an EID and an RLOC,
> the LISP protocol as specified does not permit this.
Well, yes and no. As long as you include the "as specified", perhaps. But
there are some places (e.g. mobility, where the mobile entity moves into a
LISP site) where a particular value is both an 'EID' (but not really, in
semantic terms - only in terms of the protocol operation - see below) and
an RLOC.
For the example of the mobile node which has moved inside a LISP site,
it's actual EID is first mapped to a 'temporary care-of EID' (a term I
just made up), which is its 'address' inside the LISP site. That TC-EID
then has to be mapped to the RLOC of the LISP site. (And the packets wind
up double wrapped, so that each ETR which it traverses can remove one
layer - one at the site boundary, and one at the moble node.)
The 'temporary care-of EID' looks like an RLOC in a sense, because it is
the _output_ of a mapping stage ... but in the very next moment it's also
the _input_ to a mapping stage, and thus an EID in a sense.
The thing is that because it's an incremental, interoperable, add-on to
the existing architecture, things in LISP as not always as clear and crisp
as one might like - and they often change from case to case. (The LISP
EIDs are an example - and a lot of people are somewhat unhappy that they
are called EIDs, with some justification: sometimes they have no location
information in them, sometimes they do.)
So, applying that general concept to this particular case, while one might
say, in theory, that there is a crisp division between EIDs and RLOCs, in
practice it's probably going to be a bit muddy.
> Without that assumption, various parts of what is specified simply
> do not work.
Ah, why not?
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
