On 05/23/2011 12:01 PM, Remco Van Mook wrote:
If you allow me to summarize: it is your opinion that the community is better off with the RIPE NCC not handing out address space it has available? I would have to politely disagree. RIPE NCC can handle returned address space in similar way, as it does today, I mentioned that. Why not to assign /21, /20 to someone, if RIPE NCC can (=has other space than last /8)? Normal allocations with standard policy can be processed, instead of carving last /8. There're still other limitations in place - like 6/3month address plans etc. Reserve in last /8 is - in my oppinion - large enough. There's no reason to apply last /8 policy to other address space - this will really only hold available addresses in RIPE NCC without being really used (as last /8 policy is very restrictive).
I agree that aggregation is a concern as well as filtering, but given that we're appending this address space to the end of the final /8 in allocation terms, this space would only be (re)allocated after we've run out of the final /8; that is, after some 16,000 /22s have been handed out. What the default free zone will look like is anybody's guess, but I've got a pint saying that handing out /22s from other /8s is unlikely to make it a lot worse, even more so for the assorted snippets of address space that come after that. Based on current numbers of current/new members of RIPE NCC, this will hapen sometimes after 12-18 years? If this will hapen really. In last /8, there's only one /22 per LIR, so it's quite easy calculation. Also I assume, that some LIRs will not apply for their last /22.
If people run filters based on RIPE documents (or any other source for that matter), they're well advised to have a procedure in place to keep those filters up to date. That's not argument for making these these things harder compared to current convetions.
With regards, Daniel