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".
>
> 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 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_________
|
