|
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 Sat, 22 Dec 2007, Greenhalgh, John wrote: 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 table. 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". We don't normally point default anywhere (other than null0), but I knew I'd have to before adding the route filter...so 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. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ |