Re: Some Comments on ID/Loc Separation Proposals

[Brian E Carpenter <brc@zurich.ibm.com>]

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

Erik Nordmark wrote:
> 
> > 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...
> 
> 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.
> 
> >     > 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.
> 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.
> 
> >     > 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?
> 
> Right.
> 
>   Erik