Greetings. I was following the Verio thread and just wanted to throw out another idea. It is not well thought out, but that is what mail groups are for. It appears that some of the reasons for blocking on prefix length are to encourage aggregation/summarization of routes and to protect against route explosion disaster due to human error or insane code. However, there are organizations that have been allocated blocks that are required to be carried as components. One reason is they are duel homed and another is the orgainzation's internet access spans multiple ISP's Why not have bgp do the work for us? What if the operator had the capability to accept routes based on the ratio of good prefixes to bad prefixes received where a bad prefix is defined as a more specific of a classful network or a classful prefix in swamp space. The idea would be that if ISP A was sensitive to prefix length, ISP B that announces routes to A could only expect ISP A to accept N bad routes providing M good routes are also advertised. A good route could be defined as a range of a certain prefix length that does adequate aggregation. Using some numbers, ISP B announces 10000 routes to ISP A. 2000 routes are of an adequate prefix length for ISP A to define as good. ISP A will allow one bad route for every 100 good routes that are advertised. ISP B wishes to announce 25 bad routes to ISP A. Only 20 routes are accepted by ISP A. The last 5 routes are not accepted until ISP B can convert some of the 8000 neutral routes into 500 good routes. Alternatively some good routes might be weighted as better, allowing for more announcements of bad routes. For example an ISP that could announce a 14 bit prefix out of swamp space would be rewarded more then one that announced a 16 bit prefix out of swamp space. If a customer of ISP B observes that their bad route is no longer routable over ISP A because B is announcing more bad routes, it will ISP B's responsibility to behave better by either aggregting better or removing the new bad components. Else ISP B will have to deal with the wrath of their customer. These ratios could be part of peering contracts. Each side would understand how many bad routes the neighbor will accept. It could also be stipulated contractually that a session would be torn down if an excessive number of bad routes were observed. I see no reason why excessive components cannot be treated the same way as a bad attribute. In this case I am defining excessive as hearing thousands of extra components, not a handful over the quota. This could be an alternative to having to carry every discrete route in a filter to protect oneself or filter on prefix length. Obviously, there are a lot of implementation/practical issues that I have not thought of. stevep