I sent this yesterday and never saw it on the list. After convincing myself
of the absence of black helicopter mail censors, I'm resending it:
----- Original Message -----
From: "Willis Consulting" <willisconsulting@swillis.org>
To: "Alex Zinin" <azinin@nexsi.com>; "J. Noel Chiappa"
<jnc@ginger.lcs.mit.edu>
Cc: <irtf-rr@puck.nether.net>
Sent: Wednesday, December 12, 2001 6:21 PM
Subject: Re: requirements sub-group draft
> 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