Sean Doran <smd@cesium.clock.org> writes:
| Now can we try to make things work rather than point fingers!
Yes, indeed; that is the ultimate goal we share.
Pooooh .... relief.
We just have some differences of philosophy -- you think that RIPE really can persuade people into having only 1024 announements (preferably far fewer) in 195/8, and I don't. That's all.
OK. I call this a challenge but you won't let me try ;-).
The compromise we could find would involve a practicable method by which we don't have to put a prefix-length-floor in place, but at the same time don't have to spend enormous amounts of (unavailable) CPU time filtering based on what's in the RIPE database.
All I am suggesting is to set it at /19 initially which should consume roughly ;-) as many CPU time as setting it to /18. Should we fail to meet the challenge later, I suggest to set it to /18 and allow some /19 exceptions caused by our allocation policy. This will be a quite limited number, the information will be machine readable in real time. We will provide the tools (3 lines perl) to generate filters from it. Frankly: If you cannot do this your motives become quite questionable.
Avoiding large amounts of (largely unavailable) staff time at Sprint and RIPE to chase down offenders and try to figure out how to stop them from ignoring their contribution to melting routers is also something I'd like to avoid.
It is not as big a deal as you want to make it. Daniel