Isn't the argument of the non-default routing tables growing by an additional 13 entries or not is specious noise? The routing bucket is leaking through bloody great open chasms and we are wondering about the incremental damage throuigh a pinhole!
The 13 additional entries are not the issue. The issue is one of setting a bad high-profile example. Any suggestions for closing the open chasms in the routing bucket? - Havard
On Mon, 9 Sep 1996 Havard.Eidnes@runit.sintef.no wrote:
Any suggestions for closing the open chasms in the routing bucket?
Gather weekly stats of top 10 worst offenders (ala Tony's old list) and ask Bob Metcalfe to publish them in his rag? He did say he wanted to help.. ;) -dorian
Isn't the argument of the non-default routing tables growing by an additional 13 entries or not is specious noise? The routing bucket is leaking through bloody great open chasms and we are wondering about the incremental damage throuigh a pinhole!
The 13 additional entries are not the issue. The issue is one of setting a bad high-profile example.
Quite frankly with the root nameservers the issue os one of stable and highly reliable functionality! The profile of the general applicability of the adopted mechanism is a minor consideration I'd suggest. But of more importance is the question:
Any suggestions for closing the open chasms in the routing bucket?
My humble suggestion is forced non-local proxy aggregation. Where an aggregrate and more specifics are visible through the same next AS hop, the specific advertisements can be dropped without change in the the policy environment. Similarly where multiple advertisements can be aggregated into either a single cohesive aggregate, or aggregates plus different specifics, then if the operation reduces the number of routing entries then the routing tables can be aggregated. Right now the routing tables in the default free areas are expressing a forwarding table which has very little to do with the scope of forwarding decisions at the default free zone (as such a decision table is quite small as there are not a massive number of paths into such zones and forced non-local aggregation appears to be potentially beneficial here) and more to do with diversity in AS paths for networks reachable from the zone. However I know I'm covering well worn paths with this suggestion and that such a mechanism can yeld coarse outcomes which may not produce a precise match to desired traffic flow policy in all situations, as information is being masked through this process. Here again the issue becomes a qualitative issue of whether its better to damp down the routing tables at the expense of close accuracy to express traffic flow preferences or to allow the tables to grow to ensure absolute integrity of traffic flow preferences across the entire Internet. Thanks, Geoff
My humble suggestion is forced non-local proxy aggregation. Where an aggregrate and more specifics are visible through the same next AS hop, the specific advertisements can be dropped without change in the the policy environment.
In the presence of multi-homing, this will create shorter prefixes visible through the path which proxy-aggregates, thereby changing policy another hop away and changing the load distribution. This is similar to Sprint's aggregating multi-homed customer announcements at Sprint's external borders. They justify this with words about saving prefixes, which might be credible if one did not look at the rest of what they actually announce. Rant, rave, foam, ...
such a mechanism can yeld coarse outcomes which may not produce a precise match to desired traffic flow policy in all situations
I suspected you might have seen the problem.
Here again the issue becomes a qualitative issue of whether its better to damp down the routing tables at the expense of close accuracy to express traffic flow preferences or to allow the tables to grow to ensure absolute integrity of traffic flow preferences across the entire Internet.
I suspect that we will get the major part of the win if folk clean up the messes they are making today, and we can hold proxy aggregation in reserve if that does not work. I have hope that Tony will resume publishing, and that will encourage some serious offenders to clean up their announcements. randy
participants (4)
-
Dorian R. Kim -
Geoff Huston -
Havard.Eidnes＠runit.sintef.no -
randy＠psg.com