Noel,
Following up on your thoughts, which I largely agree with...
It is not only the fact that we need levels of routers group
that will help different parts (read "groups and levels") of
the system to converge independently of each other, but also
the fact that routers need to talk using different *terms*
at different levels. E.g., at the lowest level, the terms
would be actual links and routers, at a higher level, those
would be border/boundary routers with connectivity through
the areas/groups (of course, the higher-level terms cannot
be a 1:1 translation of the lower-level ones).
Speaking different terms allows for implicit topology
aggregation, i.e., n+1'th level groups do not know n'th
level details of other groups. So, if I'm on Mars, I will
only see a group Earth with details of connectivity to and
through it, without really knowing the details of how lower-level
groups (read ASes) are interconnected there. Also (echoing your
words on policy), policy routing on different levels will be
done with different level of detailization.
Now is the most "scary" thought... Once we have different
levels speaking different terms, we can think of independent
addressing at each level. In this case, the complete address
of a node would be a combination of addresses at each level
of hierarchy. The main benefit of this approach is in the
implicit address aggregation, since n'th level addresses
do not have to be known to higher level (a refinement could
suggest leaking some n'th level info to only n+1'th for
more optimal routing). So, my Mars level-boundary router will
not be flooded with millions of prefixes when Saturn gets
plugged into the Net. There are definitely questions here,
e.g., how we account for dynamically changing levels of
hierarchy, or how we map this to IPv6...
Just thoughts...
-- Alex ZininWednesday, December 12, 2001, 8:56:31 AM, J. Noel Chiappa wrote:
> > From: smd@ebone.net (Sean Doran)
> > the intra-domain/inter-domain split was probably not caught because of > > the heavy interest in the problems with the current inter-domain system > > exposed by both reality and various bits of research she and her > > colleagues (and others) have done.
> I've been thinking a bit about this whole intra/inter split a bit, and I > think I've got a better handle on what causes me to be so upset about it > (above and beyond the fact that it was a hack put in as a "quick fix" to > certain problems caused by other people trying to GGP with the BBN routers).
> For one thing, it's going to be kind of hard to produce the thorough reform > that I think routing needs if you "boat-anchor" yourself with the existing > IGP's - so looking exclusively at inter-domain routing is bad from that angle > alone.
> For another, and more importantly, in trying to understand how to make > dynamic routing practical in a very large system, I've come to realize that > it's important to have multiple layers of aggregation not just in the > topological elements of the network (i.e. addressed elements), but in the > devices which are exchanging and computing routing information. In other > words, in addition to a hierarchy of topological "areas", we also need a > hierarchy of router "groups".
> The reason for this is rooted in one of the key requirements of a real > routing system, which is stabilization. For paths to stabilize in a network > of arbitrary size, you have to carefully control the "impulse rate" of the > routing. In other words, in a simplistic "envelope-back" analysis, you have > two lines on a graph (of which the X-axis is network size). The first is > "time to stabilize after a change", and that of course goes up, and the > second is "time between changes", and that of course goes down (assuming a > constant per-element failure rate). Obviously, at some point those lines will > cross, which is a Bad Thing.
> (I'm aware that this model is way simplistic, and a topology change effects > only a subset of destinations, and over usually-limited scopes, so two > changes will probably not interact in any case; and in any case, even if they > do, the effect is not necessarily fatal. But to a 1/2th order, I think there > is some truth to it.)
> Now, it may well be that a more sophisticated mathematical analysis (sort of > Kleinrock/Kamoun II) will show that the scope of the affected nodes decreases > over time, so things are effectively stable after all, but even if that's > true, I'd still be reluctant to rely on it to produce a *robust* routing > system - and I think robustness is a key requirement.
> We have to be able to really control the dynamicity, to absolutely prevent > instability - which is of course more likely to happen at times when things - > due to some sort of catastrophe - are failing all over: which is exactly when > you *most* want the thing to work reliably!
> A key part of that, I've decided, is the ability to set up a hierarchy of > router groups, so that you can exert control over when a group at level N > reports a change to the group at level N-1.
> Yet another reason to want a hierarchy of groups is that it will be natural > for the "operating mode" to be different at different scopes, in the sense of > what kind of policies you have, how responsive you want the system to be to > changes, etc, etc.
> In both of these cases (operating modes, and stabilization), a simplistic > two-level inter/intra split is simply not good enough. We need a more complex > hierarchy - and if you have that, the inter/intra split is pointless.
> Finally, of course, there are all the problems caused by the kind of "hard" > split you often see between IGP's and EGP's, where it's very difficult to > "leak" information across that boundary in a way that does what you want, > because of the incompatable architectures of the two system. Yes, the fact > that they use a single addressing scheme helps (and a lot), but there are > still many problems.
> If we had a single system, albeit one with mutiple levels, it ought to be > easier to allow for the kind of information flows that a real system needs.
> Anyway, that's my thinking on this.
> Noel
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT