> From: Sam Hartman <hartmans-ietf@mit.edu>

    >>> Darrel discussed an idea with the authors of expanding EID as
    >>> end-site identifier.

    >> That's not really correct, though, because an _individual_
    >> LISP EID names an individual host (well, perhaps even an
    >> interface, as Fred Templin pointed out). So they don't
    >> identify "sites".
    >> ...
    >> (I picked 'device' to be deliberately am[b]iguous as to whether an
    >> LEID names a host or an interface, to avoid semi-endless debates about
    >> what it does name.

    > I think it's very clear that it names an interface

My main issue, originally, was with the notion that a particular EID named an
"end-site", which to most people would mean a whole chunk of the
internetwork. I now see (below in your message) that you intended to mean
something other than that with the term "end-site", so if we don't use the
potentially confusing word 'site' I don't think there's an issue there.

But now that you mention it, I think an IP address (and a LISP EID) name
_more_ than an interface, they also name a host (or stack); for instance, in
TCP they name the fate-sharing entity at the far end of a TCP
connection. (Just for grins, I'll also very briefly take a page out of Robin's
book, and point you at RFC-791, "Internet .. Protocol Specification", where we
read that "hosts [are] identified by fixed length addresses".) Hence my use of
a new, ambiguous term, neither 'host' nor 'interface', because IP addresses
actually name both at the same time (to our great confusion).


    > At least in the applications area, never using the term identity
    > definitely seems to be the running approach.

The problem is that the term 'identity' has been in use for a long time in
discussing these issues at the internetwork layer (see e.g. RFC-1498, which
is the famous paper from Saltzer from 1982).

    > How with LISP as we are scoping it today can you avoid some internal
    > subnetting?

If I have a site (i.e. a piece of the internetwork) with only a single
logical physical network (i.e. I have at most bridges, and no routers), there
is only one subnet at that site, and thus no reason to dedicate any of the
'local' part of the EID to designate the subnet; the entire field can be used
to number hosts/interfaces.


    > I'd like to say that the global portion is what is mapped into an RLOC.

This gets into a bit of definitional mud here here, because I seem to vaguely
recall that there were plans to have multiple ETRs divide things up, so that
not all traffic to a single 'site' (as I am using the term) goes to a single
ETR. (However, that's the operational side, and I'm not totally up to speed
on the plans in that area, so I can't say for sure.)

Anyway, the upshot is that a single 'site' might have a single LEID block
assigned, but different parts of that LEID block might resolve to different
RLOCs. So is the 'global' part just the high part (i.e. the block issued to
the site as a whole), or does it include everything down to the last bit that
the mapping system looks at to produce a mapping?


    > I think that a case where the same 32-bit number was used for an RLOC
    > and an unrelated EID would be a significant difference from LISP today.
    > ...
    > call for something to be said answering to what extent we expect EIDs
    > and RLOCs to overlap.

In my experience, on the Internet, generally if something isn't absolutely
impossible, people will figure out a way to do it - and they will do it no
matter whether there's a document saying that they should or should not do it.
(And they often are very clever in doing so - look at things like web site
load-sharing traffic dispatchers, where a number of machines share a single IP
address.)

So if it's _possible_ to use the same bit pattern as both an EID and an RLOC,
my guess is people will do it, no matter what the documents say. And my take
is that, because of _other_ concerns (e.g. limiting routing overhead), it
will be technically possible, which means people probably will do it no
matter what we say in any documents.

	Noel