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 ZininWednesday, 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