From: Curtis Villamizar <curtis@ans.net> > We can also limit the amount of routing overhead by providing configured > AAB boundaries for a given multihomed site which enclose a path between > the primary and secondary providers. Since this will in some cases > require ... automated tools we don't have yet, don't hold you breath for > that one either. You may not have to wait as long as you think. ... The idea is to provide a means to specify the aggregation boundary within the IRR and provide the tools to transform that specification into router configurations. Oh, I should also mention that Tony Li did have an idea for how to do something like the above (providing a path between primary and secondary) automatically; it involves forwarding a more specific route toward the source of a more generic route. This is worth investigating, I think. One issue with that approach is how good the routes are to the destination if the link to the primary goes down. A lot of traffic might wind up taking two sides of a triangle, but maybe that's OK for a fallback. The configured AAB probably provides better routing after a failure has happened, at higher routing overhead of course. Also, another way to think of these things are as "partition repair" mechanisms. Some routing protocols which support areas also support automatic partition repair mechanisms; IS-IS does this with a tunnel. Maybe we should look into the work that has been done in that area, too. This code will enable ANS to do much better aggregation that we now do regardless as to whether other providers buy into the idea. To accomplish the type of multiprovider cooperation you refer to above, it is a matter of getting someone else doing the same thing, or something similar enough that we have someone to cooperate with. I think that eventually we're probably going to have to look into abstraction control mechanisms that operate on scales larger than a single provider; not clear how urgently that will happen. It's true that we are having to sit fairly hard on the 32-bit space to fit everyone into it, but now that multi-level CIDR is being deployed, that is not as big an issue. The big issues that I see coming up now are things like: - How do we set AAB's and similar configured items; the current hand configuration of things like this just won't keep working. - The need for continuing to add levels of abstraction (we're currently up to about 5 - carrier, ISP, customer, subnet, host) but need to keep going to keep the routing table growth supportable as the growth in net size continues to outpace technology growth. In other words, addresses will likely have to be more organized at higher and higher levels (since the lower ones are already pretty logically assigned), which is going to be very painful indeed. Noel