Daniel, Interesting message (limit of 1024 aggregated routes per /8); I seemed to have missed this approach in past email. It still has the side effect of encouraging downstream providers to remain with their current provider, _if_ their prefix happens to be from a block of the address space which has become fragmented and is being filtering by allocation. The only real problem I see with this approach is that there is a no peer group based on allocations, and therefore no mechanism which lets folks in the same block coerce each other into good aggregation... (Imagine email saying "Please, my fellow 206'ers, let's squeeze out another 600 routes before XXXnet's filtering deadline!", "207/8 -- Love it or leave it", and my personal favorite, the eventual 192/8 T-shirt which says "192/8 - Beyond Hope and Filters" ) /John ===

Sean,

If you insist on prefix-length filtering I have proposed a soloution for future address space allocated via the RIPE NCC several times:

- set your inbound prefix length filter to /19.

- The RIPE NCC will *guarantee* that we will not make more than 1024 non-aggregateable allocations from each /8.

- The RIPE NCC will continue to work with the providers to maximise aggregation. Our goal is a maximum of 1024 routes per /8 visible at major exchange points. Incidentally this is the same goal that you seem to have.

- Should we fall to short of the goal in your opinion, you can start to filter on the list of allocations which is available from our whois database (whois -h whois.ripe.net -m 19x/8). Note that we guarantee that these will be no more than 1024.

Now given the current performance of everyone I personally believe that we deserve a little relief from the 1024 goal but I am willing to discuss on the basis above.

Can we please enter into a discussion why this is a bad idea and/or why it is not acceptable to you personally or your employer.

Daniel ...