Re: [lisp] [ipdir] LISP WG

[[e-mail] (Noel Chiappa)]

    > From: Margaret Wasserman <[e-mail]>

    > I am concerned about the accuracy of calling this mechanism an
    > ID/Locator split mechanism

Well, if it is not intended to separate location and identity, what's the
point of creating a mapping database, to maintain maps from one namespace to
another? And two of the capabilities it explicitly provides/supports are
provider independence and multi-homing - two things for which separation of
location and identity are generally held to be fairly crucial.

If one has to pick one _short_ phrase to describe the goals and point of
LISP, it is indeed 'separate location and identity'. Only when one gets to a
longer description does one have the room to add the complex caveats of 'not
complete separation _in the initial stages_, because initially LISP EIDs
still retain some location semantics, and also name interfaces as opposed to
stacks'.

Yes, it is not absolute separation of location and identity (at least in the
short term), but that is because LISP made the strategic choice to support
_unmodified hosts and site-local routers_ - and since conflation between the
two concepts is deeply embedded into the code in those classes of devices,
it's therefore inevitable that one won't get a perfect split (at least, in
the short term).

I do think it's a good idea to carefully point out those limitations clearly,
and fairly early on in any writing about LISP, but at the same time, what
other _short_ description of the goals and mechanism of LISP is appropriate?


    > it does not actually separate IDs and Locators within the edge network.

Not initially, no (and it would be good to say so clearly). However, as the
boundary between the mapped/un-mapped portion of the network gets closer to
the host, the location semantics leaches out of the LISP EID, and when the
boundary reaches the host's first-hop router, it's entirely gone.

Getting rid of the interface naming semantics will be harder - that can't
really be done without host changes. However, it is a possible long-term
evolutionary step.


    > As just one small example, if we had a true ID/Loc split mechanism, a
    > host could maintain a constant ID as it moved throughout the network,
    > somehow updating the ID/locator mapping as it moved. However, that is
    > not a property of LISP EIDs.

If things get to the point where LISP mapping happens at all first-hop routers
within domains (as posited above), this capability would in fact be available
_without any host changes_ (assuming, as you point out, that the mapping could
somehow be updated), or indeed _without any changes to LISP itself_.

I would therefore argue that to the extent such movement _anywhere_ is not
possible (because some domains haven't converted internally), then that
limitation is in fact a deployment issue, and not an _architectural_
limitation of LISP itself.

	Noel