Actually, I am not sure that the protocol should see different terms. It
is certainly true that the devices at different levels are sometimes aware
of differences, but I see no reason why the protocol should reflect this.
For example,if we assume that there is aggregation of information going up
the "hierarchy", most of the items appearing at high levels will actually
be such abstractions. But there should be no reason why an individual
device or link can not appear there, and there is no reason why any other
device should know that it is an individual device vs an aggregate. (Not
even for purposes of determining whether in a map based system one can ask
for more detailed information. Some "devices" can give more detailed
information, and some aggregates can not.)
Similarly, except for limitations of identification / naming, it should be
hard / impossible for an individual device participating in what it things
is a low level of the hierarchy to tell whether other devices it sees are
actually aggregates.
Yours,
Joel M. Halpern
At 04:00 PM 12/12/01 -0700, Alex Zinin wrote:
>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 Zinin
>
>Wednesday, 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