The ATM routing protocol PNNI
ftp://ftp.atmforum.com/pub/approved-specs/af-pnni-0055.000.pdf
also has this group/level/address concatentation. See section 3 in the
document.
Steve
----- Original Message -----
From: "Alex Zinin" <azinin@nexsi.com>
To: "J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>
Cc: <irtf-rr@puck.nether.net>
Sent: Wednesday, December 12, 2001 6:00 PM
Subject: Re: requirements sub-group draft
>
> 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