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

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 14 Nov 2003 11:41:45 -0500

> From: Erik Nordmark <[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?

Ah, I see another terminology alert! Time again for my favourite quotation:

  "I am far from thinking that nomenclature is a remedy for every defect in
  art or science: still I cannot but feel that confusion of terms generally
  springs from, and always leads to, confusion of ideas." 

    -- John Louis Petit, "Architectural Studies in France", 1854

In this case my concern has to to with the term "identifier". I wonder if
each of you has subtly different ideas on what this term means - and if this
lack of a precise common definition is causing communication difficulties.

Do you mean "identifier" as in "a name, with some properties, but without
enumerating/stating those properties", or "a name, but without any properties
at all other than identification"?

"I trust I make myself obscure"? Let me make it a little more concrete: a
street address is the name of a geographical location, but it's also a name
with some properties, which is that it is hierarchically organized by
political/geographic entities. There are other names for geographic locations
(e.g. GPS co-ordinates) with different sets of properties.

I'm trying to think of an example of a name with *no* properties (other than
identification), but I can't come up with one offhand that everyone would be
familiar with. Imagine a hypothetical operating system that named processes
with identifiers which were just random (non-colliding) bit strings - that
would be an example of a name with no properties.

When I use the word "identifier", I generally am using the "name without any
properties" definition (since I use "name" to mean "name with some properties,
but without stating what they are") - but I don't know what you all mean by
it.

    >> The current IP (v4 and v6) architecture uses interface IDs.

Well, the names (IPvN addresses) identify interfaces, but they are names with
properties (they include location, that information is hierarchically
structured, etc).

    >> it is still unclear to me what implications this has for ID or Locator
    >> selection in ID/Loc separation protocols.

Do realize that for most people, when they speak of an "identifier" for the
host/endpoint/stack, they are sometimes thinking of names with no properties
- a subtly different kind of "ID" from the "interface ID" you were just
talking about.

Of course, there are some schemes for host/endpoint/stack "identifiers" in
which those names *do* have properties - they are public keys, or hashes of
public keys, or DNS names, or whatever...

    > 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).

    > The concept of a stack name, where there can be one or more "stacks" on
    > a given host, provides the right granularity to me. Each "stack" can
    > presumbly have one or more network interfaces.

I assume also that each interface can have one or more stacks talking through
it, right?

	Noel

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Nov 2003 21:43:15 -0800 (PST)

> public keys, or DNS names, or whatever...

I guess the issues isn't whether the frobnits has a property or not,
because even your example of a random process id has the properties that they
are random and uniques, but whether this property is important; being
used for some particular purpose.
I think this is shades of grey; a random frobnits can be used as a good
hash key somewhere, which is a much *lighter* usage that the random bits
also being a hash of a public key.

> interface, and its location).

Actually I was thinking more of "makes no sense"= isn't useful in the context
of id/loc split.
If one wants to separate out identifiers from locators for the purposes
of allowing "rehoming" presumably one would want to rehome between different
interfaces and not just between different locators assigned to the same 
interface.

> I assume also that each interface can have one or more stacks talking through

Right.

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2003 09:29:43 +0100

I think we're going to have to face a couple of realities in 
order to make progress.

1. Despite years of discussion, we've never managed to establish
a shared understanding of identifier issues. The NSRG was the most
recent serious attempt, and despite a measure of consensus it didn't really
succeed.

2. These things we call "addresses" have frustratingly ambiguous properties.

We have to deal with these realities pragmatically - we simply will not
have mathematical precision about the meaning and properties of "addresses,"
but reality forces us to use them anyway. 

Conceptually, upper layer protocols have been taught to think of addresses
as a perfect blend of locator and identifier, and the lower layers know well
that they are only locators. Multi6's job is to reconcile these two views
as part of our solution.

   Brian
   co-chair hat mainly on

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 20 Nov 2003 12:44:57 +0900

Brian;
 
> but reality forces us to use them anyway.

According to the end to end principle of the Internet, what's
important on the Internet is end systems.

So, addresses, IDs and locators address, identify and locate
end systems and they occur at the Internetworking layer.

> that they are only locators. Multi6's job is to reconcile these two views

By definition of "layering", layers other than the Internetworking
layer may use anything (including something used by the Internetworking
layer) for identifiers.

On the other hand, "locator" locates something only at the
Internetworking layer though other layers may use the "locator"
for other purposes.

>    co-chair hat mainly on

Just rely on not chairmanship but the end to end principle.

							Masataka Ohta