Re: requirements sub-group draft

From: Joel M. Halpern (joel@stevecrocker.com)
Date: Thu Dec 13 2001 - 15:10:11 EST


Exerience suggests that policy goals which some group thinks are unique to
their "level" of the hierarchy will turn out to be similar to groups that
folks operating at other "layers" of the hierarchy have.
Yours,
Joel

At 12:59 PM 12/13/01 -0700, Alex Zinin wrote:

>Joel,
>
> From the topology & resource abstraction and aggregation perspective,
> the PNNI way is definitely good, as hierarchy is transparent to
> the nodes.
>
> I guess where it becomes not obvious is when we think about policy
> routing and address aggregation (whether address aggregation is a
> goal or a non-goal is a different question).
>
> I think that policy routing at different levels may have different
> objectives expressed in different terms, and it is pretty hard
> to translate policies at level N to terms understandable and
> (more importantly) meaningful at lower levels.
>
>--
>Alex Zinin
>
>Wednesday, December 12, 2001, 4:18:39 PM, Joel M. Halpern wrote:
>
> > 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