Noel,
I am very specifically addressing the set of drafts as specified and
having just been
last called.
I do understand that there are a lot of ideas floating around about
how to use LISP to
do various things - some in charter and some out.
To be implemented interoperably based upon reading the drafts, I don't
think there is
another option. At this point, it seems to me that much of the
probability cloud around
LISP has to resolve.
I'm not trying to be architecturally pure - I want to see something
that has the assumptions
written down and can be implemented.
At least one case of parts that don't work when the same bit-pattern
is used as an EID for one
host and as an RLOC (or globally routeable address) for another is:
ANYWHERE that a lookup in the mapping database is done to
determine if an address is an EID or RLOC
Alia
On Thu, Jun 23, 2011 at 3:04 PM, Noel Chiappa <[email protected]> wrote:
> > 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
