IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries

Mon Dec 3 18:37:56 UTC 2007

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_________