> 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