On Apr 7, 2009, at 8:52 PM, Tony Li wrote:
Hi all,
As the conversation has died down, I'm going to guess that we've
converged. The consensus check can be found here: http://doodle.com/9sybb8dmk5phvp99
Please vote for or against these definitions:
locator A locator is a name for a point of attachment within the
topology at a given layer. Objects that change their point
of attachment(s) will need to change their associated
locator(s). 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)).
Also tied up with day job stuff recently...
I don't think this one is quite there yet since it doesn't directly
address the question of how (a) namespace semantics and (b) the
associated routing system are involved in characterizing the name of
an attachment point as a locator (or not). I think some of this
relation is implied in the language above, but it is still fuzzy...
Using the postal example,
123 High Street,
Bigtown,
Green County,
Outer Luvania
We would agree (I think) that if an object / person moved next door,
and still wanted to be reachable, it would need to use a different
locator (say, 125 High Street). However, what if larger sections of
the geography itself move - perhaps today Green County is beside Blue
County, but tomorrow it is next to Red County. Some of the location
information is stored outside the locator itself - in a map of some
sort. This map could be a static reference that all components of the
system are aware of through outside means (e.g. a traditional
geographic map), or it could be a dynamic map (e.g. the current system
state of a routing system). Depending on the nature of the "change to
the point of attachment", and the characteristics of the system
geography and map of that geography, the (i) locator name may need to
change or the (ii) map itself may need to change.
R,
Dow
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
