|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries
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.
|