Hi Richard,
I was working on almost the same thing... 
As from next Friday, my routing report will include the top 20 ASes which are announcing prefixes more specific than the registry minimum allocation (/20), more specific than a /24 from 192/8 space, more specific than a /16 from former B space, more specific than a /8 from former A space...
A taster follows:
Advertised prefixes smaller than registry allocations
I was working on almost the same thing...
routing report will include the top 20 ASes which are announcing
prefixes more specific than the registry minimum allocation (/20),
more specific than a /24 from 192/8 space, more specific than a /16
from former B space, more specific than a /8 from former A space...
I've always been suspicious of using registry allocation boundaries, there
are too many legitimate ways to set it off. There are lots of reasons to
have some diverse /22 announcements in your network for example. On the
other hand, if you have 200 seperate /24s announced from the same /16,
with the same aspath, and the origin owns the entire block, there is
simply no reason for this.
11371 307 Rhythms NetConnections
  3491 651 CAIS Internet
DSL providers are becoming very bad about this. Someone pointed out to me
off list that CAIS had carved up PSI's /8 into over 500 /24s.
   690 502 Merit Network
Well at least we don't have to go too far to find the guilty party. 
18994 468 Global Crossing
15870 436 Global Center Frankfurt
18993 325 Global Crossing
Those are the GlobalCenter datacenters being converted into the Exodus
network. It looks like they are leaking a sizable number of /32s /30s etc,
and since its GBLX space I'm assuming its stuff that used to be aggregated
into a single announcement.
There is no attempt to measure aggregation - that's the job of the
CIDR Report. This simply looks at the prefix announced and if it is
outside the above limits, it is counted. Makes very interesting
reading...
The one interesting pattern I noticed in the rampant /24 abuse was non-
contiguous announcements. It's likely that this kept them off the CIDR
Report and any other scans which only looked for contiguous announcements.
For example:
1.2.3.0/24
1.2.5.0/24
1.2.7/0.24
There are lots of reasons to have some diverse /22 announcements in your
network for example.
but if you are not paying me, what reasons are there for me to spend my
resources (route bloat) so you can engineer your traffic?
randy
The fact that your other customers are paying you to reach everyone on the
internet?
I agree the routing table is bloated (though I disagree that 100k should
be a serious strain on a router, the blame lies with the vendors there),
but there is no reason you need to lose connectivity to anyone in the
process of filtering.
It would be interesting if you could discard more specific routes with the
same attributes as an existing shorter prefix. The problem is if you lose
the shorter announcement you don't have any way to get the more specifics
back. Perhaps it would be possible to keep a low-memory record of the more
specifics which have been removed and the shorter which replaced it. At
this point you're probably just shifting the resources used away from
memory and into CPU, giving you slower convergance times.
Your customers are paying for Internet connectivity. If they're unable to reach the sites they desire as a result of your intention actions (filtering announcements), why should they continue to pay you?
While I fully support and expect route aggregation whenever possible, it is unreasonable to believe that everything fits in nice pretty packages. If you're unwilling to accept diverse /22 announcements without payment, why should we not expect the same for the /24's you're announcing?
jas
But in defense of Randy's "as long as you pay me" polcies, the worst I see
originated from Verio is:
  204.77.134.0/24 3967 2914
  204.77.141.0/24 3967 2914
  204.77.142.0/24 3967 2914
  204.77.145.0/24 3967 2914
  204.77.146.0/24 3967 2914
  204.77.148.0/23 3967 2914
  204.77.156.0/24 3967 2914
  204.77.159.0/24 3967 2914
  204.77.181.0/24 3967 2914
It appears that 204.77.128.0/17 belongs to Synergy Communications, who has
their own AS (3673) but isn't using it. Interestingly enough, synergy.net
appears to be selling bicycles not internet.
And the worst from one of their customers is:
  192.103.149.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.151.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.152.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.154.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.155.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.160.0/23 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.162.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.175.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.176.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.179.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.188.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.190.0/23 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.192.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.194.0/23 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.208.0/23 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.210.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.229.0/24 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.230.0/23 3967 2914 6993 6993 6993 6993 6993 6993
  192.103.236.0/23 3967 2914 6993 6993 6993 6993 6993 6993
Far from being one of the worst offenders. I guess it goes to prove the
old saying, never blame on malice what you can blame on stupidity.
There are lots of reasons to have some diverse /22 announcements in your
network for example.but if you are not paying me, what reasons are there for me to spend
my resources (route bloat) so you can engineer your traffic?The fact that your other customers are paying you to reach everyone on the
internet?
red herring alert! the point is not reachability. the aggregate is still
available. see bellovin's phoenix presentation.
randy
Assuming there is an aggregate. Unless you know for certain that there is
one, you run the risk of making some addresses unreachable.
As an extension of something I mentioned in a previous message, perhaps
someone will be so kind as to play devils advocate and tell me why this
wouldn't work. Automatically aggregate more specifics with attributes
matching a shorter prefix at your network borders, and only pass the
aggregates to the rest of your network via IBGP. The EBGP speaking router
which receives the more specifics would keep a low memory record of them,
and in the event that the aggregate route was withdrawn the more specifics
would be advertised to the IBGP peers. In the event that an aggregate
route is announced, any already announced more specifics would be
withdrawn.
red herring alert! the point is not reachability. the aggregate is
still available. see bellovin's phoenix presentation.Assuming there is an aggregate.
see bellovin's phoenix presentation
randy
The link on the NANOG web site points to the wrong presentation. Perhaps you would be so kind as to forward me a copy?
jas
The link on the NANOG web site points to the wrong presentation.
<whoops!>
try <http://www.research.att.com/~jrex/nanog/lost.html>
randy
none.
Now tell me how to promulgate my TE-triggering routing advertisements precisely to the edge of my payment boundary (i.e. my upstreams, and their upstreams, and so on recursively along the upstream relationships) and no further, using today's BGP?
but if you are not paying me, what reasons are there for me to spend my
resources (route bloat) so you can engineer your traffic?none.
well, we agree so far
Now tell me how to promulgate my TE-triggering routing advertisements
precisely to the edge of my payment boundary (i.e. my upstreams, and
their upstreams, and so on recursively along the upstream relationships)
and no further, using today's BGP?
but why should i pay the costs because the tool was not designed to do what
you want done?
i will happily work on tool design with you [0]. but, in the meantime, why
should i have to pay a penalty for your odd business choices?
( casual readers should note that 'you' and 'i' are abstract terms, and
that geoff usually claims to be more of a capitalist than i
randy
>> but if you are not paying me, what reasons are there for me to spend my
>> resources (route bloat) so you can engineer your traffic?
> none.well, we agree so far
> Now tell me how to promulgate my TE-triggering routing advertisements
> precisely to the edge of my payment boundary (i.e. my upstreams, and
> their upstreams, and so on recursively along the upstream relationships)
> and no further, using today's BGP?but why should i pay the costs because the tool was not designed to do what
you want done?
Taken together, the pair of statements above is a pretty good illustration of the issues at play in the inter-provider space today. Wanting to optimize traffic loads over multiple connections is not unreasonable as an objective, but having the entire world see your resultant advertisements is not the best of outcomes.
i will happily work on tool design with you [0]. but, in the meantime, why
should i have to pay a penalty for your odd business choices?
If you are on my upstream chain, then I am accompanying my routing requirements with money. Whatever penalty you may incur I pay for with my upstream payment. Where your statement holds is once you are not seeing money from me (i.e. you are not an upstream paid directly or indirectly by me), in which case what would help us all is a recognised [*] community attribute which says "advertise this prefix together with this attribute only to your upstreams"
[*] 'well if you don't recognise it then I am less interested in having you as my upstream than if you do.
( casual readers should note that 'you' and 'i' are abstract terms, and
that geoff usually claims to be more of a capitalist than i
indeed
If you are on my upstream chain, then I am accompanying my routing
requirements with money. Whatever penalty you may incur I pay for with my
upstream payment. Where your statement holds is once you are not seeing
money from me (i.e. you are not an upstream paid directly or
indirectly by
me), in which case what would help us all is a recognised [*] community
attribute which says "advertise this prefix together with this attribute
only to your upstreams"
  Actually, in all cases the requirements are accompanied by money. Even in
settlement-free peering, if the two sides didn't feel they were getting paid
to do whatever they are doing, they should sever the peering relationship
and charge. You are getting that route from somewhere and if you aren't paid
by someone to do so with value greater than its cost to you, you should stop
accepting the route.
  The money flows along the same paths the routes do. Every time a route goes
from router 1 to router 2, there is some agreement that allows it to do so.
If the route exchange costs you more than you're getting out of it,
renegotiate that connection.
  One thing that might help is if companies that work out peering that isn't
free start to charge based, at least partly, upon aggregation. If extra
routes really cost you, charge for them where they enter your network. Heck,
charge per route if you want. This should work well for small to mid-sized
companies that generally have trouble getting settlement free peering. I
doubt you could pressure UUNet, Sprint, or C&W in this way.
  DS
> 11371 307 Rhythms NetConnections
Email sent to gharmon@rhythms.net, cgreen@rhythms.net, doroberts@rhythms.net on Feb 8 - no response.
> 3491 651 CAIS Internet
DSL providers are becoming very bad about this. Someone pointed out to me
off list that CAIS had carved up PSI's /8 into over 500 /24s.> 690 502 Merit Network
Well at least we don't have to go too far to find the guilty party.
> 18994 468 Global Crossing
> 15870 436 Global Center Frankfurt
> 18993 325 Global CrossingThose are the GlobalCenter datacenters being converted into the Exodus
network. It looks like they are leaking a sizable number of /32s /30s etc,
and since its GBLX space I'm assuming its stuff that used to be aggregated
into a single announcement.
Email sent to: ipadmin@gblx.net, huberman@gblx.net, ip-eng@gblx.net, scarter@gblx.net, bgp@gblx.net, bp@gblx.net on June 4 - everyone responded that the problem was forwarded to Exodus and from there it disappeared into a black hole.
Basically, after having sent out dozens of emails over the past 6 months I have come to the conclusion that there are a few out there that will fix things when presented with the problem. But the vast majority either don't have a clue, don't want to have a clue or couldn't give a damn that the routing tables are increasing in size.
-Hank
Behaviour modification can probably be achieved through negative
publicity. Just need a couple of newswires to pick up a story like
"tier1 laziness causes routing table bloat", and name the top 10 worst
offenders.
-Dan
If you are on my upstream chain, then I am accompanying my routing
requirements with money. Whatever penalty you may incur I pay for with my
upstream payment. Where your statement holds is once you are not seeing
money from me (i.e. you are not an upstream paid directly or
indirectly by
me), in which case what would help us all is a recognised [*] community
attribute which says "advertise this prefix together with this attribute
only to your upstreams"
  Actually, in all cases the requirements are accompanied by money. Even in
settlement-free peering, if the two sides didn't feel they were getting paid
to do whatever they are doing, they should sever the peering relationship
and charge. You are getting that route from somewhere and if you aren't paid
by someone to do so with value greater than its cost to you, you should stop
accepting the route.
  The money flows along the same paths the routes do. Every time a route goes
from router 1 to router 2, there is some agreement that allows it to do so.
If the route exchange costs you more than you're getting out of it,
renegotiate that connection.
  One thing that might help is if companies that work out peering that isn't
free start to charge based, at least partly, upon aggregation. If extra
routes really cost you, charge for them where they enter your network. Heck,
charge per route if you want. This should work well for small to mid-sized
companies that generally have trouble getting settlement free peering. I
doubt you could pressure UUNet, Sprint, or C&W in this way.
  DS
If you are on my upstream chain, then I am accompanying my routing
requirements with money. Whatever penalty you may incur I pay for with my
upstream payment. Where your statement holds is once you are not seeing
money from me (i.e. you are not an upstream paid directly or indirectly by
me), in which case what would help us all is a recognised [*] community
attribute which says "advertise this prefix together with this attribute
only to your upstreams"
there are some subtle differences between the above and my previous:
community-minded folk might suggest that a universally agreed
DO-NOT-EXPORT-TO-PEERS community would get you a good way there.
at least it would approximately follow the money.
note, for example, that your semantic does not announce the fine-grained
routes (aka rubbish:-) Upstream has heard from you to Upstream's's bgp-
speaking customers (Downstreams?), who i presume are mult-homed.
and note that my second suggestion
also note that filtering peers' announcements on rir allocation
boundaries would seem to go a way toward meeting both your needs
and mine. and it is what smb's nanog presentation alludes to.
allows conservative/protectionist/... peers and multi-homed downstreams
to achieve a similar result while waiting for a DO-NOT-EXPORT-TO-PEERS
community to be deployed.
randy
Yes. This is part of the Exodus purchase of Global Center from Global
Crossing. It is being worked on as we speak. Customers are renumbering...
Fun!
Exodus does care and Exodus is working on this problem. Ever try to get
500 customers to renumber?
Hope that helps.
Christian