I don't think filtering on RIR allocations has anything to do with keeping the small people down. It is not a political problem, it is a technology problem.

Indirectly it certainly does. It is the small people who cannot justify the host requirements to acquire an allocation from the RIRs. Because the small provider cannot acquire PI space, they must resort to route leaking of PA space to the non-assigning upstream, who in turn must then announce this PA-microallocation to its peers. And, because, like it or not, the facts show that large (forgive the coinage) tier-1s are doing very passive filtering at the peering points, we see this explosion. It is quite enlightening to see what the big-8 exchange between each other. This is where the unobstructed growth is most dangerously occuring. And please don't tell me that we should force the smaller ASN to co-lo or multihome to the same provider of whatever. Any business that allows their suppliers to drive their business requirements when better alternative solutions exist shouldn't be in business. Coming from someone who has on occasion, introduced superfluous information into the GRS, there are limitations to BGP that force such leakage. And it is not a multihoming issue, but a traffic engineering one. Geoff has addressed this problem in his work on multihoming, but this thread is addressing only the multihoming-for-redundancy issue. This is half the problem, and as suggested, is dependent on the RIR allocation policy. What is also occuring (again, in a more dangerous sense) is the intentional leakage of more specific routing information by the mid-size regional ISP for the purposes of multi-provider TE. downstream A has met the requirements for an RIR allocation. It purchases one OC-12 at rock-bottom pricing from NSPA. It then purchases and OC-3 for backup to NSPB, but at a higher cost. If NSPA and NSPB are mutually well-connected at the same level in the AS hierarchy, then there will be an inbound load-distribution problem. So, the ISP breaks the /19 into 32 /24s, and announces them to both providers, depreferencing 6 of them toward the OC-12 carrier using communities. This forces all traffic to flow exactly toward the NSP with the best preference for the route if 1) the /24s are leaked between NSPA and B, and 2) the providers prefer customer routes over peer routes over customer backup routes (which nearly all providers do.). Furthermore, all peer ASNs of NSPA and B and their customers follow a non-deterministic path, that can only be affected if the above requirements are again met. However, there is no method at the ISPs disposal to scope these announcements to only these two NSPs (as the superfluous information does not need to flow beyond them, only the aggregate.) The idr-wg has been working on a mechanism to scope this longer-prefix leakage to the NSPs involved in this type of multihoming. It is actually derived from the dist-list-exclude and dist-list-include path attributes in IDRP (see sections 7.12.5-6 of ISO 10747 for more info). What this would allow a downstream to do is responsibly leak information only to those providers that are being paid to accept it. Isn't that novel? Instead of oppressing our smaller brethren, lets empower them to contribute to the solution. Attempting to squash them hasn't resolved anything, as we all seem to be well aware. Talk to your vendors - encourage them to implement draft-bonaventure-bgp-redistribution-01.txt as it matures. Now if we can only get the providers to upgrade their software... Regards, chris

It will ultimately be solved when core routers can handle an Internet worth of /32's and an EGP is developed to efficiently propogate changes (perhaps an open central registry with policy applied locally). One has to wonder why vendors don't satisfy the first requirement today.

Until that time, you can either satisfy the (fairly reasonable) minimum allocation requirements, Implement any number of alternate kludges that have been proposed, or go home.

KL