From: Jon Lewis (no email)
Date: Mon Dec 03 2007 - 13:37:56 EST
On Mon, 3 Dec 2007, Andy Davidson wrote:
> As you nearly point out, it's 100% of the traffic for some networks, and will
> still be high for other networks. The only way to feel confident that
> traffic is unaffected by routing table compression is to aggregate
> sensitively. This is where my "permit one deagg" question came from.
What positive effect do you hope to get from allowing one level of deagg
beyond RIR minimums? The route table fat that's trimmed away by imposing
an RIR minimums filter basically falls into 3 categories.
1) gratuitous deaggs done by networks devoid of clue. They see their
CIDRs as collections of "class c's" and announce them largely as such
with no covering aggregates.
2) traffic engineering deaggs. One would hope that a network with enough
clue to be doing this would announce both the deagg and the covering
RIR-assigned CIDR.
3) PA-space multihomers announcing small CIDRs (/24, /23, etc.).
I don't see how allowing one additional deagg beyond RIR minimums will
help in any of these cases. Case 1 is hopeless. Case 2 doesn't generally
need any help. Case 3, unfortunately is unlikely to see much benefit
either, because their CIDRs are so small relative to RIR minimums.
As someone else suggested (I can't remember if it was in the earlier
thread or private email) another filter that might be interesting to "run
the numbers on" would be one that instead of using RIR minimums to build
the filter, looked at actual RIR assignments. That would obviously be a
much larger filter and might pose issues for either CPU load or config
size.
----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
|
|
|