The SWAMP

Mailman List Mirror (Read Only)
1

> 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

2

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