too many routes

What triggered the filter was the observation that in
the blocks freshly allocated by all three registries were
very poorly aggregated. More annoyingly, those allocated
to Sprint's principal peers (most notably Internet MCI)
demonstrated the worst aggregation; in one case a /14 was
announced almost exclusively as prefixes no shorter than
19 bits.

What's interesting is Sprint's filters have encouraged InternetMCI's
customers to clean things up more than Sprintlink's customers. As
an experiment, I removed my filters last night. In general my filters
are more generous than any Mr. Doran used, mostly blocking 'mistakes'
like /32 prefixes. What I found was the four top providers appearing
in the previous filtered paths in order were, total of 1074 filtered

  227 Sprint
  225 UUNET
  92 MCI

Sprint has taken over the number 1 spot, and MCI dropped to
number 4, from the point of view of my BGP routers. Although
MCI still seems to be well represented amoung the very, very
long (>/30) prefixes. But this may simply be due to someone
else filtering out extremely long prefixes before they reach my
BGP routers. So you should view these as lower bounds. Things
may be worse.

What was even more interesting was number of routes accounted
for by >/24's in 192-210 space and >/16's in 128-191 space was
more than any of the CIDRizing suggestions in Tony Bates weekly
CIDR report. Some people seem to view CIDR as an opportunity to
subdivide their traditional 'Class B' networks. I would classify
most of these announcements as 'mistakes' because they usually also
announce the supernet, and have the same path.

Here were some of the extreme examples. 3561 i 3561 i 3561 i 3561 1221 ? 3561 1221 ? 3561 i