> From: "Joel M. Halpern" <j...@joelhalpern.com>
> the value of ID / Locator separation
There's a reason that I always phrase it 'separation of location and
identity', i.e. describe the architectural goal at a high level, in terms of
abstract properties, not in terms of specific naming mechanisms.
Alas, it doesn't seem to be catching...
> even within this limited community, there have been significant
> differences is when the term "identifier" should be used.
I agree. "Identifier" is an _existing_ term which _already_ has meaning(s),
and trying to use it for yet another (ill-defined) thing is to virtually
_invite_ confusion.
There's a reason that I introduced a new term ('EID'); which I defined to
have the following semantic/syntactic properties: 'globally-unique,
location-insensitive, fixed-length (and relatively short, i.e. < 128 bits or
so), binary (i.e. not-human friendly)'. (See Section 10.2 of the 'Endpoints
and Endpoint Names' document.) I.e. it has a fairly well-defined set of
semantic and semantic properties.
If people wanted a term for, say, 'an identifier which names an endpoint in a
way which is globally-unique and location-insenstitive', a _unique_, _new_
term should have been created - not reuse an existing one, a step which is
virtually _guaranteed_ to _increase_ confusion.
> In my book, an IEEE MAC address is an identifier.
True - but it also names an _interface_, not an _endpoint_ - and that's
_another_, very distinct axis along which the classic 'IP address' is
confused/ambiguous.
> In a true MP-TCP environment, one might well want to view the
> identifier as being above the TCP flows. .. in a regular TCP
> environment, placing the identifier below TCP so that TCP picks up a
> significant degree of locator invariance without needing MP-TCP is also
> valuable.
> ...
> I do not want to get tied up in the question of which layer should hold
> the identifier.
A very interesting and powerful observation.
After brief thought, I don't think the issue is that we have too few
namespaces at hand (e.g. we are lacking sessions, or something). I think in
this case the problem is that we are trying to have 'TCP' work with only
_one_ namespace. (I put 'TCP' in quotes for a reason - see below.)
In fact to really do some of the things MP-TCP is trying to do (e.g. make use
of host multi-homing for multiple, parallel sub-streams), it does in fact
need to know about _two_ separate ones - the identity of the endpoint which
it is talking to, and the locations of the interfaces through which it can be
reached.
So uni-cast TCP and MP-TCP do occupy slightly (and significantly) different
places in the architectural 'stack', which is why the endpoint->interface
binding ideally happens _below_ 'classic' TCP, and _in_ MP-TCP.
Noel
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
