> From: Geoff Huston <gih(_at_)telstra(_dot_)net>
> part of the characteristics of today's Internet is that its is
> flattening out. The concept of hierarchical connectivity with
> 'upstreams' and 'downstreams' ... as I understand the current
> deployment plan there are TLAs and sub TLAs, and an apparent
> hierarchical view of the world again.
I'm not quite sure if this is what Ted was referring to - and we have indeed
wandered a bit. Your point is an important one, though - but the answer takes
us even further afield, into routing theory. (Briefly!)
There is a great misconception, in the IETF as a whole, that hierarchical
location-names mean that either i) topological connections have to be
hierarchical, or ii) paths have to be hierarchical. Both suppositions are
absolutely, completely, untrue.
As to the first, if you will consult the classic paper on hierarchical
routing:
Leonard Kleinrock, Farouk Kamoun; "Hierarchical Routing for Large
Networks: Performance Evaluation and Optimization"; Computer Networks 1
(1977); North-Holland Publishing Co.; pp. 155-174.
you will see that their work utilizes a random graph (that's a technical
definition, not a judgemental term :-), so that disposes of the first one. It
does use strictly hierarchical routing (i.e. their abstraction naming
boundaries are congruent with their abstraction action boundaries), but even
so it's worth noting their conclusion:
"As regards the network path length, we were able to place an upper bound
on its increase due to the introduction of hierarchical routing ... in the
limit of very large networks, enormous table [size] reductions may be
achieved with essentially no increase in network path lengths"
Use of non-hierarchical routing with hierarchical location-names is a complex
topic, one I can't explore here because it's tied in with all sorts of hairy
conflicting optimization (overhead, path length, etc) questions. However, it
is easy to provide non-hierarchical routing, even when the naming system you
are using is hierarchical.
> part of the issue we face now is the semantics of the address ... Is an
> address an identification of identity? A key to absolute location? A
> key to relative location? An encoding of the local topology?
There are interesting questions, and ones that unfortunately have not been
previously settled in a consistent way across the community.
(I would say more about the fundamental technical issues, in particular what
technical tasks we ought to be using "place-names" for, but this probably
isn't the right time/place.)
> in looking at the structure of V6 addresses ... we appear to have
> adopted an approach which is not far removed from the provider address
> hierarchy structure of V4 today.
From my point of view, the problem is not with the hierarchical nature of the
IPv6 address (since something like a hierarchy exists in every large-scale
routing system I've ever seen), but rather with the point you just raised -
just what it is that those things name, and how they name them.
> My lurking concern is that it is not working in the V4 routing system
> given the large percentage of table entries which are more specific
> advertisements of aggregate announcments (approx 40%) and it won't work
> for V6 either
The problem you're touching on, of multi-homing, is basically not a problem
with the addressing. It is a problem of i) the overall system architecture,
and ii) the architecture of the routing system.
It's a problem with the overall system architecture because providing the
benefits of multi-homing by imposing the cost of supporting it *entirely* on
the routing system - which is the way we are supporting multi-homing now -
may not be the way to go. Multi-homing is a complex topic, but I do think
there are other mechanisms which might be more cost-effective *in some
circumstances* than shoving the whole job off on the routing (e.g. use of
multiple addresses - but note that these addresses are still hierarchical).
(And may I take a moment to point out that if we were charging for routes,
the costs of having the routing "do it all" would be more apparent, and there
would be more incentive to explore other mechanisms.)
It's a problem with the routing architecture because in many cases, one
needn't expand to a global scope for the advertisement of a multi-homed site,
but the routing system as currently architected has no tools to help us with
either i) determing, or ii) setting scopes. All we have is either i) purely
local, or ii) global.
> It appears that the intended address structure and deployment structure
> appear to be at variance, and when that happens the temptation to alter
> the address in flight to suit each local region's environment may well
> be overwhelming.
I can't conceive of any reason that the path selection would want to change
an address (at least, in the sense of "location-name") in flight.
That doesn't mean there aren't lots of other things that would. NAT is one,
but for anything (e.g. traffic aggregate based forwarding) that needs "bits
in the header" that aren't there now, mutating the address is an obvious
kludge.
Noel