Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp)

[jnc at mercury.lcs.mit.edu (Noel Chiappa)]

    > From: "Templin, Fred L" <Fred.L.Templin at boeing.com>

    > I'm not sure about the analogy. If I assign the same interface ID on
    > multiple interfaces of the same node, it works fine ... But, if I
    > assign the same IP address on multiple interfaces of the same node 

Which is part of why I said "the properties of the LISP EID are extremely
similar to an IEEE Interface ID" - not 'identical to'! The problem you point
out was one of the differences I identified, in thinking about it.


To be exact, even if mapping-encapsulation functionality is in first-hop
routers at a site, if an ETR is connected to multiple physical networks at
such a site, then when a packet arrives either:

- i) the ETR has to have a table, identifying which physical network each
  LISP EID is on; or
- ii) something in the LISP EID must identify which physical network the
  host the packet is for is attached to; or
- iii) something in the RLOC must identify said network.

i) isn't exactly infeasible - that's basically what bridges do already. ii)
is what the current scheme is - and it means that LISP EIDs have to retain
some location semantics. iii) would need some support, probably through
assignment of a new RLOC AFI to carry a tuple (the ETR's locator, plus a
destination physical network selector), plus some information in the
encapsulation header(to carry the destination physical network selector). Not
sure which is best - or perhaps all might be used, in different situations.


    > I am still offering Endpoint Interface iDentifeir (EID)

I like it, but... if LISP evolves to the point where LISP EIDs become purely
stack identifiers (which is what I would like to see, long-term), and
interfaces are named from a new locator namespace (yes, I know this requires
host changes), then LISP EIDs would not in fact name interfaces any more.

The only piece of functionality that _cannot_ be leached out of an IPvN
address, _if interoperability with unmodified hosts is to be maintained_, is
their identification of stacks. (Note that having interfaces named from a new
locator namespace is perfectly feasible, because that would only be visible
_locally_ - the host on the far end of e.g. a TCP connection would not
necessarily be aware that that was happening on the other end.)

	Noel