Subject: RE: Some Comments on ID/Loc Separation Proposals

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 18 Nov 2003 23:26:05 -0500

> From: <[email-masked]>

    >>> The use of the term "Identifier" or "ID" sweeps an important issue
    >>> under the rug in some cases: Is this a host ID or an interface ID?

    >> or a 'stack id' or an 'endpoint id'? and what do these mean,
    >> precisely.

    > Noel .. referred to a host/endpoint/stack ID as though a host, an
    > endpoint and a stack are all the same thing. But are they really the
    > same thing? Is there even a 1:1:1 correlation between these things?

I was being a little loose there, for which I apologize. Let me expand a bit
on that "host/endpoint/stack" thing.

"stack" is a term that gained increased prominence in the NSRG, which used it
to name some new "thing" that they might name. I don't think there was rough
consensus there on what a "stack" might be; I don't even think there was RC
on whether it was below the transport layer, or what - I'd have to look at my
notes from the NSRG meeting to see (if anyone cares).

"endpoint" is a term I have been using for a long time now (defined in this
note - http://users.exis.net/~jnc/tech/endpoints.txt) to name a class of
entities I thought we should explicitly add to the architecture; they are the
things that do end-end communications like TCP (fate-sharing regions, in
other words).

I'm not sure if there is a significant difference between "stack" and
"endpoint", but that might depend on who you talked to, and what the term
"stack" meant to them.

"host" I assume means a physical computer. I just threw that one in in case
people were confused by the stack/endpoint terminology. Most people have a
pretty good handle on what a "host" is.

In a simple model, the kind we mostly have now (modulo things like the IBM
web server farm), a host is an endpoint.

If we included endpoints as first-class objects, presumably you could do
things like have multiple endpoints in a particular host, and probably allow
them to move from host to host. But that's all just architectural sketches.

	Noel

---

From: "Tony Li" <[email-masked]>
Date: Tue, 18 Nov 2003 23:15:24 -0800

Noel,

From my perspective, we've been quite consistent with
using locator for the topological naming for an interface, while
an identifier is the name for a host.

Yes, I realize that we haven't taken this quite as far
as you (or I) would like.  However, if you consider that we
have managed to get consensus on this much separation, I'd
say that we've come a long way, baby.

Tony

|  -----Original Message-----
|  From: J. Noel Chiappa [mailto:[email-masked]] 
|  Sent: Tuesday, November 18, 2003 10:33 PM
|  To: [email-masked]
|  Cc: [email-masked]
|  Subject: Re: Some Comments on ID/Loc Separation Proposals
|  
|  
|      > From: Erik Nordmark <[email-masked]> 
|  
|      >>> An interface ID makes no sense to me.
|  
|      >> Perhaps because you, in contrast, are thinking of 
|  "ID" as "name with
|      >> no properties"? I think you will agree that 
|  interfaces do need names
|      >> of some sort - our familiar "locators" (i.e. an 
|  address which *only*
|      >> names an interface, and its location).
|  
|      > Actually I was thinking more of "makes no sense"= 
|  isn't useful in the
|      > context of id/loc split.
|  
|  Actually, now that I think about it some more, perhaps you 
|  had a completely
|  different meaning in mind here.
|  
|  Did you in fact mean to say that "I don't see any need to 
|  provide any kind of
|  name for interfaces, either one with topological 
|  significance, or any other
|  kind"?
|  
|  (The "name with topological significance for an interface" 
|  is what I've been
|  calling a "locator".)
|  
|  
|  In other words, when you talk about "id/loc split", are you 
|  thinking that
|  we'll have two different kinds of names for endpoints/stacks 
|  - "ids" which
|  are not related to any particular locations, and some sort 
|  of "location" name
|  which is?
|  
|  	Noel
|  
|

---

From: <[email-masked]>
Date: Tue, 25 Nov 2003 13:28:57 -0500

> an identifier is the name for a host.

Ahhh...  This pretty much answers my question (I think :-)).

In your taxonomy, the "ID" portion serves as a host/endpoint 
identifier and the "Locator" portion allows you to topologically 
locate a particular interface on the network, right?

If I understand correctly,  the 8+8/GSE world uses a different 
breakdown between ID and Locator...  The upper 8 bytes
are only a topological locator for a particular link (which
may have many attached interfaces), and the lower order 8 bytes 
are used to identify a particular interface on that link.

I consider this to be a fairly important architectural 
distinction, as the two models offer different levels of 
abstraction to ULPs.

Margaret

---

From: "Tony Li" <[email-masked]>
Date: Tue, 25 Nov 2003 12:38:41 -0800

|  > From my perspective, we've been quite consistent with
|  > using locator for the topological naming for an interface, while
|  > an identifier is the name for a host.
|  
|  Ahhh...  This pretty much answers my question (I think :-)).
|  
|  In your taxonomy, the "ID" portion serves as a host/endpoint 
|  identifier and the "Locator" portion allows you to topologically 
|  locate a particular interface on the network, right?

Correct.  More specifically, we have not introduced any terminology
with respect to an 'endpoint'.

|  If I understand correctly,  the 8+8/GSE world uses a different 
|  breakdown between ID and Locator...  The upper 8 bytes
|  are only a topological locator for a particular link (which
|  may have many attached interfaces), and the lower order 8 bytes 
|  are used to identify a particular interface on that link.
|  
|  I consider this to be a fairly important architectural 
|  distinction, as the two models offer different levels of 
|  abstraction to ULPs.

Granted, however, from the macro point of view, this seems
somewhat less critical.  Our goal has been to "break as little
as possible" and towards that end, we have naturally gravitated
towards interface abstractions.  This is not a religious
requirement -- rather it's driven more by the pragmatics of
finding a solution that will gain widespread acceptance without
some very painful educational processes.

Tony