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_________