On Apr 2, 2009, at 12:38 PM, Tony Li wrote:
Hi all,
Thank you all for the highly spirited debate and my apologies for
being unable to contribute. Other high priority matters have been
in the foreground.
I've read the entire debate so far and am struck by the fact that we
made a change in the 2nd pass and early in the thread and I don't
think everyone picked up on the importance of the distinction.
Specifically, it's vital to understand that a locator and identifier
have semantics that are only relevant at a particular layer.
Furthermore, talking about identifiers and locators in absolute
terms is not constructive; they are necessarily relative terms.
Agree the definitions are relative. I don't think "layer" alone is
quite the right way to frame scope, though it is one way to frame it.
Remember that both identifiers and locators start off as simply
tokens. Names that we assign to things. We assign them semantic
values that happen to matter at a particular layer. When regarded
outside of that layer, those names then are simply opaque.
Mostly agree - I would say outside of a particular scope, where being
of a different "layer" is an example.
For a better example, let's stop arguing about Ethernet. We have to
operate with many link layers and our terminology must reasonably
apply to all of them. Let's look at what happens with IP over X.
25. An X.25 address is a long string of bits and within the X.25
network, if administered in a sane fashion, the address is
hierarchically assigned and nicely structured. However, from the
perspective of layer 3, it is wholly opaque. Just a token, nothing
more. It has no semantics _at layer 3_. Similarly, from the
perspective of layer 2, the IP address is neither locator nor
identifier. It's just payload bits.
I think some of us want these definitions to make sense in a general
and consistent manner across the various parts of the overall
architecture. Agree that if we call certain things out of bounds for
this discussion, and that may make it easier.
The key point here is that the semantics of a namespace is only
relative to the layer where it is applicable. The rest of the time,
it's just opaque bits.
Mostly agree - same note as above.
As another example, let's look at the FQDN. At the application
layer, it's clear that it's a practical identifier. We map it
through DNS to get an IP address that gives us a network layer
identifier and locator. However, at the network layer, the FQDN
itself is nothing but a string.
So, it's all relative.
Putting this all together, here's pass 3. Again, if I missed
something or have misunderstood, please feel free to bring it up.
The goal here is to reach rough consensus on these definitions and
we're definitely close.
Regards,
Tony
---------------------------------------------------------------------------
locator A locator is a name that has topological sensitivity at a
given layer and changes if the point of attachment at that
layer changes. By default, a locator refers to layer 3.
It is also possible to have locators at other layers.
Locators may have other properties, such as their scope
(local or global (default)) and their lifetime (ephemeral
or permanent (default)).
It is this "point of attachment at that layer" phrase that is still
problematic. If a host disconnects from one place on an ethernet
segment and connects to another, it can still be reachable without
changing it's IP address. Are you defining this as not changing the
point of attachment (in terms of layer 3)?
Also, to say that that a locator changes when the point of attachment
changes depends on the nature of the routing system. The locator
could stay the same, and there could be a change to the routing state
instead. So there are some "relative topological scope" types of
considerations in "this locator-ness" check, but the definition above
does not capture those.
R,
Dow
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
