Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both?

From: [email-masked] (Noel Chiappa)
Date: Thu, 23 Jun 2011 15:04:24 -0400 (EDT)

> From: Alia Atlas <[email-masked]>

    > 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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 23 Jun 2011 16:30:54 -0400

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-masked]> wrote:
>    > From: Alia Atlas <[email-masked]>
>
>    > So - although theoretically the value A can be an EID and an RLOC,
>    > the LISP protocol as specified does not permit this.
>
>    > Without that assumption, various parts of what is specified simply
>    > do not work.
>
> Ah, why not?
>
>        Noel
>