[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Re: Should the identifier be used as local locator
Brian and Tony -
But you're correct too. Whether a bit string is a locator or an
identifier depends entirely on context. (That's why I've objected to
EIDs in LISP being called EIDs from the start - once they hit the
network, they become locators instantaneously; they are only
identifiers in the global context.)
Indeed. It's pretty clear that we can still have semantic cleanliness
tho, as we can isolate a particular bit string as having L3 identifier
semantics (coupled with L2 locator and L2 identifier semantics) and
distinct from L3 locator semantics.
You define the terms "identifier" and "locator" based on whether you
can route on them. This is why an identifier can become a locator, or
vice versa, if you look at it in a different context.
Hitherto, my definition of the terms was independent of whether you
route on them or not: I thought of a "locator" as a place in network
topology, and of an "identifier" as a name for a host (or for some
entity on the host such as an interface card or an application
session). In other words, given an attachment point to the network, a
the locator described something on the network side of it, and the
identifier described something on the host side of it. With this
definition, whether a name is an identifier or a locator does not
change with the context.
Decoupling what a name describes from what you can do with the name is
sensible IMHO because only the latter depends on the context: Within
small scope, routing based on identifiers may certainly be feasible. A
good example is the bridge you mentioned, which maps MAC addresses
(which are identifiers according to my definition) onto "next-hops".
For global scope, routing based on identifiers fails due to
scalability issues because identifiers cannot facilitate aggregation
of next-hop information in routers or switches due to host mobility
and multi-homing. Locators do facilitate such aggregation, provided
they have a suitable structure, which is why they are more appropriate
for global-scope routing.
Anyway, I have no problems changing my definition if the research
group wants to use a different one. Let's just agree on one of them.
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg