Dow Street allegedly wrote on 03 29 2009 10:09 PM: > Thinking about this some more... > > Given a system that has a notion of geography or topology, we can assign > names to different points within that geography or topology. So, as a > starting point, it seems reasonable to define a locator as (1) a name > for a point (or location) in a geography or topology.
I like the recent development that a locator can refer to a whole prefix. I would like to retain that. We used to say a locator was a particular attachment point and we left prefixes kind of hanging out there. > Depending upon the nature of the geography or topology, it may be > possible to devise a namespace (and set of semantics) for these names so > that the name (value) itself (2) encodes information about the > geographic or topological position of the point being named. > > I think some people have been defining a "locator" as a name that meets > condition (1). Others seem to have been defining a "locator" as a name > that meets condition (2), and still others seem to be thinking it must > meet (1) and (2) (i.e. have location semantics and be "in use" in that > context). I think it's both because of the point made in the last few messages that the issue is usability. Noel pointed out that MACs as administered are not _usable_ as locators because of their structure. > For example, I would argue that a MAC address meets condition (1) - i.e. > it names a location in a topology - but it does not meet (2), because it > does not encode in the name (value) itself any topological information. Aha ... A MAC names an interface but not an attachment point. A MAC is a property of the device, not the network. > On the other end of the spectrum is a > switched ethernet, where knowing the location name (MAC) tells you > nothing about the relative topological position of the point being named > by the MAC. However, the MAC (in my mind) still serves as the name of a > location. A MAC is a property of the device, not the network. Contrast it with an attachment point name. > IP routing usually falls somewhere between these two. The proximity > semantics of IP allow some relative positional information to be encoded > in the name. For this to be of benefit, though, the routing system must > be (a) designed to take advantage of the proximity semantic (e.g. by > passing around prefixes instead of individual addresses) and (b) the > points in the geography must be named in a supporting manner (i.e. > locations named with sets of addresses that allow for aggregation). > What is important here is that "if location information is only partly > encoded in the name, a secondary system (e.g. routing) is needed to > complete the mapping function". Sounds good. > I think this leaves us with a spectrum > of cases, for example... > > Geographic Coordinate System > - the position in the geography is fully encoded in the name of the > location (coordinates) > - no supplemental "routing system" needed > > Internet Routing > - location in the topology is partly encoded in the name of the location > (IP address) > - routing system does *some* work. > > Ethernet Switching > - location in the topology is not encoded in the name of the location > (MAC address) > - routing (i.e. switching) system does "all" the work. OK, this is useful. It could be incorporated as an attribute of "locator" (clearly an identifier, being topology-independent and being able to change independently of topology changes, does not encode anything about position). Something like: A locator may encode some amount of topological position information in its value. > A key part of the RRG routing problem (if I understand correctly) is > that it is hard to embed positional information in a location's name > when the geography or topology of the system (graph) has Internet-like > properties. Grids are easy, trees are easy, but Internet-like > topologies are not. So what we do currently (again, if I understand > correctly), is devise the semantics for the IP address namespace to make > it efficient to embed position information for points on a tree, and > then use routing as glue between this tree representation and the actual > topology. As such, if we are relying on aggregation as our scaling > tool, the less tree-like the topology, the more routing state there will > be (even in the *best* case where names are assigned in a maximally > aggregatable manner.) All true. This is what we have arrived at based on experimentation but also on history (the "Internet" was overwhelmingly hierarchical, with ARPAnet at the core, until 1987). What do you suggest? Scott _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
