Subject: Re: [arch-d] Benefits of identity/location separation?

From: [email-masked] (Noel Chiappa)
Date: Wed, 25 Apr 2007 10:08:53 -0400 (EDT)

> From: John Day <[email-masked]>

    >>> As we both know solving the loc/id split is not the whole problem.

    >> What would you say is "the whole problem"?

    > RFC 1498. You need another identifier. Just having points of
    > attachments and application names isn't enough. 

You've got me thorougly confused - and I suspect others as well! I thought a
significant ancillary point of the location/identity split was the the two
different names would not only have different semantics (location versus
identity), but would also name *two different classes of objects* - to wit,
interfaces and "stacks".

(I'm going to totally skip the whole debate on whether or not, with a
blank-sheet design, you'd even want to name stacks - we don't have a blank
sheet.)

Were you assuming the two kinds of names would name the same class of objects
(and if so, what)? What is the advantage (if any) in doing that?
If not, what classes of objects did you think they named, and what additional
class of objects would be like to see explicitly recognized and named?

    > The loc/id split characterization points at a solution space that won't
    > scale.

This also I don't understand. Could you give us some more detail?

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: John Day <[email-masked]>
Date: Wed, 25 Apr 2007 10:37:44 -0400

;-)  My understanding of loc/id split given the proposals that 
purport to address it and the discussions here and elsewhere is that 
when interpreted in terms of RFC 1498;

The loc is a point of attachment address and

the id is seems to be an application name since it is always 
location-independent  Strictly speaking it is probably more an 
"application-protocol-instance-name" rather than an application name 
since it seems to identify a single flow/connection/communication to 
an application.  Although in some proposals the id seems to be a 
"transport address" (whatever that could be) but is still 
location-independent.

If what you mean by "stack name" is what I think you mean by stack 
name, ;-) then I think they need to be location-dependent in some way 
without being route dependent.  This being what 1498 calls node 
*address.*  Not a node name.

Then I guess if you think "stack name" is node address, then I think 
it has the wrong properties!  ;-)  And we are in for scaling problems.

That clearer?  ;-)
John