Re: Geographic v. topological address allocation

From: Sean Donelan (no email)
Date: Mon Nov 17 1997 - 15:16:57 EST


>You are confusing transport address (describing a location
>in a topology) with an object name (a book, a computer, a
>process running on a computer).
>
>An object name like an ISBN does not need to be
>hierarchical because they do not describe discrete
>locations. Introducing hierarchy improves managability
>and efficiency of databasing. Many hierarchies can be
>imposed on object names.

If there isn't, there should be a theory in computer science
with enough levels of indirection you can solve any problem,
i.e. ISBN->Call Number->Shelf Location. Trick question: Does
a LC Call number describe a location in a topology or an object
name?

Many hierarchies can also be imposed on an object's location,
especially when that location is connected by a rich topological
mesh.

>Remember: at each level of naming there can be different
>and completely disjoint hierarchies. There are
>scalability implications in all of them, most notably when
>the names used have size limits or are distributed
>non-hierarchically (like ethernet addresses or the COM
>domain). However, the important thing is that when a name
>is used as a LOCATOR in a topology, in order to be
>scalable that name must be related to that topology and in
>large networks must lend itself to aggregation in order to
>reduce the amount of information needed to have that
>locator be used throughout the network.

Another axis of the problem is the stability of the names used as
locators. Otherwise you have just moved the problem up a level,
translating the object name to its instantaneous location. Love
that indirection. Propagating the change in object name->locator
name when a route flaps, or every corporate merger or acquisition,
doesn't scale well any better than the current system. Who is going
to tell Bert or Bernie that all those MCI customers need to renumber
when they merge their respective networks? Geographic addressing
only has the advantages in that continental drift moves at a much
slower pace than the changes in most network topologies. How you
get to Cleveland might change, but Cleveland tends to remain in
the same relative position.

However, strict hierarchies have the disadvantage you can wipe out a
subtree by simply targeting a higher level node. Being able to wipe
out Cleveland by disrupting the Cleveland NAP is not a desirable feature
of geographic hierarchical addressing. So you need some redundancy
between the subtrees (i.e. a mesh), which means you have to keep track
of that redundant information. Since that redundant information is likely
based on the providers' facilities in and out of Cleveland, it looks like
topological addressing. So do you name objects based on how you get
to Cleveland, or based on their presence in Cleveland? But I think
everyone has heard this argument before.

Trade-offs, trade-offs.

-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation







Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD