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

throughout the satellite industry. So if we didn't deaggregate RIR
blocks, we'd have at least one RIR allocation per discontiguous network
and so would be contributing the same number of prefixes to the global

True, but I've seen enough networks that deaggregate because they just don't know any better. If we were to make an exception for every network that had reasonable cause to deaggregate, that probably wouldn't scale. Relaxing the filters by a few bits might work. I'll have to run a few tests to see what happens to the route savings if I filter on APINC RIR+1 bit, RIR+2 bits, etc. The worst abusers are the ones to whom their RIR allocations are "collections of class C's" so it may be that there's enough savings at RIR+2 to make that worth using as a compromise.

I just filtered you (before
seeing your message) as we're now filtering APNIC on "RIR Minimums".

The timing of my mail was pure coincidence. I am assuming that unless
our immediate Tier 1 upstreams start filtering, we won't see any
significant degredation as people start implementing these filters.

We don't normally point default anywhere (other than null0), but I knew I'd have to before adding the route you're still reachable as long as the networks between us aren't filtering.

For anyone interested, the filter I'm using is the APNIC section of the ISP-Ingress-In-Strict filter posted to nanog a few months ago, plus around 10 additional deny rules that we'd normally have via an input distribute-list...since IOS doesn't seem to allow both an input distribute-list and input prefix-list on the same BGP peer.