...

there has to be a limit.

A limit is needed, but the filtering method in question to me essentially says this:

if you have 64.x.x.x/15, slice it into as many /20's as you can and bloat as much as you want.. we feel this is an acceptable practice.

i strongly doubt that the policy was formulated on that basis. it may or may not be equivilent to what you said, but you have not described anyone's (whom i'm aware of) actual motivations with the above formulation.

Yet, if you're a legitimately multihomed customer wants to push out a single /24 (1 AS, 1 prefix) that is not considered acceptable.

actually there's a loophole. nobody filters swamp /24's that i know of, since so much of the oldest salty crusty layers of the internet are built on those.

The only kind of prefix filtering I would want to implement is something that can accomplish:

1. Define threshold, say /20 or /18 or hell even /8. 3. all prefixes longer than threshold get held until entire tables are loaded 3. start looking at the longer prefixes across the entire ipv4 space starting with the longest and finishing at threshold+1 4. if prefixes longer than threshold appear as part of a larger aggregate block that *originate* from the same AS, drop. 5. if prefixes longer than threshold originate from a different AS than the aggregate, accept.

i wish you luck in implementing this proposal. i think that folks with multivendor global networks will find it completely impractical, but you can probably pull it off in a regional zebra-based network with no problem.

This way I could get rid of redundant information yet at the same time not cause any trouble to smaller multihomed customers. I'm not saying that we should allow /32's to be pushed everywhere either. As you said there has to be a limit, and /24 seems to be a pretty good one if something along the lines of the above mentioned filtering algorithm could be used.

let's do some math on this. swamp space is more or less 192/8 and 193/8 (though parts of other /8's were also cut up with a pretty fine bladed knife). if every 192.*.*/24 and 193.*.*/24 were advertised, that would be more prefixes than the entire current table shown in tony bates' reports (~100K vs 128K). that is of course just the existing swamp. and it would be hard to handle but even harder to prevent since there's no real way using today's routers to say "accept the current /24's in 192/8 and 193/8 but don't allow new ones". this is the bogey man that gives people like smd nightmares. then there's everything else. if 20 /8's were cut up into /24's then tony bates' report would have 1.3M more things in it than are there today. if the whole IPv4 space were cut up that way then we'd see 16M routes globally. those numbers may seem unreasonable, either because current routers can't hold them, or because current routing protocols would never be able to converge, or because you just can't imagine humanity generating even 1.3M /24's let alone 16M of them. multihoming is a necessary property of a scalable IP economy. actually, provider independence is necessary, multihoming is just a means to that end. if you don't think there are more than 1.3M entities worldwide who would pay a little extra for provider independence, then you don't understand what's happened to *.COM over the last 10 years. in that case i'll simply ask you to take my word for it -- you make 1.3M slots available, they'll fill up. i do not know the actual limit -- that is, where it ends. i know it's going to be higher than 1.3M though. i also know that the limit of humanity's desire for "provider independence without renumbering" (or "multihoming") is currently higher than what the internet's capital plant, including budgetted expansions, can support. and i strongly suspect that this will remain true for the next 5..10 years.

I'm sure in reality there's many reasons this would not be able to be implemented (CPU load perhaps) but it would atleast do something more than a "gross hack" that nails some offenders, not all by any means, and impacts multihomed customers who are only a portion of the problem that the current prefix filtering solution does not solve.

people are out there building networks using available technology. forget about CPU load and look at delta volume and convergence. the "internet backbone" is not fat enough to carry the amount of BGP traffic that it would take to represent the comings and goings of 16M prefixes. 1.3M is probably achievable by the time it comes due for natural causes. do any of our local theorists have an estimate of how much BGP traffic two adjacent core nodes will be exchanging with 1.3M prefixes? is it a full DS3 worth? more? less? every time you change out the capital plant on a single global AS core in order to support some sea change like 10Gb/s sonet or 200K routes, it costs that AS's owner between US$200M and US$1B depending on the density and capacity. bean counters for old line telcos used to want a 20 year payback (depreciation schedule) on investments of that order of magnitude. today a provider is lucky to get five years between core transplants. bringing the period down to two to three years would cause "the internet" to cost more to produce than its "customers" are willing to pay. so in the meanwhile, verio (and others who aren't mentioned in this thread) are using the technology they have in order to maximize the period before their capital plant becomes obsolete. as i said in a previous note, they are certainly balancing their filters so that filtering more would result in too many customer complaints due to unreachability, but filtering less would result in too many customer complaints due to instability. anyone who wants the point of equilibrium to move in the direction of "more routes" should be attacking the economies which give rise to the problem rather than attacking the engineering solutions which are the best current known answer to the problem. in other words go tell cisco/juniper/whomever your cool idea for a new routing protocol / route processing engine / cheap OC768-capable backplane and maybe they'll hire you to build it for them.