> | yeah, I really wish those who are trying to improve network routing
> | (an endeavor which I respect in principle) would consider that
> | applications really do need stable endpoint identifiers which
> | are globally scoped, exchangable with other applications, and
> | reliably usable from anywhere to reach the process listening
> | to that endpoint.
> 
> Understood, and that was probably never a non-goal.
> 
> The problem about overloading topology and identity is that it's hard
> to think about separating the overloaded meanings from one another.

this might be in part because there are several different kinds of 
overloading going on.  IP addresses are used as, or as part of: network
topology locations, subnet identifiers, network interface identifiers, 
host identifiers, service identifiers (groups of hosts performing
a common service), and connection endpoint identifiers.  (and I've
probably left out one or two uses).  

to separate them all would impose far too much overhead.  even
to separate "host" related things from "network" related things
imposes significant overhead both in bandwidth and in maintaining
the mappings from one to the other.

> Worrying that breakage can happen is perfectly understandable from both the
> perspective of someone needing to work with the "where" (topology locator)
> and someone needing to work with the "who" (identity name), since
> in a large, complicated network, the overloading really can be
> a zero-sum game.  A proper separation (or initial non-overloaded design),
> however, can satisfy both namespace needs.

I'm not sure there is such a thing as "proper".  overloading of IP
address to mean both "host" and "network" was a useful optimization
in the days when bandwidth was scarce,  links were slow,  hosts were 
stationary, the network didn't change topology often, and the net was 
small (and thus easier to route).  overloading of IP addresses
is *still* useful because many of the above conditions still exist,
and will continue to exist, for large portions of the network.
At the same time the overloading gets in the way in the (increasing
number of) cases where some of the above conditions are violated. 

IMHO what we need to change is the *implicit* association between
"host" related identifiers and "network topology" related identifiers -
so that coders treat them as separate entities, and provide a way
for the two to be different at the IP layer - while still allowing
the optimization to take place where it makes sense.  then you
only need to maintain the mapping for the case where the identifiers
are different.

I'm still waiting for folks to see this "overloading" as a design compromise
rather than a pure evil.  not overloading at all would be even more evil.
what we need now is a different compromise, rather than a design which
is "proper" according to some idealistic principles.

> Incidentally, the IRTF's NSRG (http://www.irtf.org/charters/namespace.html)
> exists to study this problem, and there are a number of interesting ideas
> being developed there that will meet your wishes expressed above.

as it happens, I'm in the NSRG.  but I also think it's useful to have these
issues aired (briefly) on the wider IETF list.

Keith

Reply via email to