Hi Daniel, The beginning of article 5.6 in the current policy reads as follows (emphasis mine): "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space WILL ONLY BE DONE as follows:" This means the current allocation policy is out of the window at that point, and might as well not even exist. There is no point in time where the two separate pieces of allocation policy are both being executed. So, only a single /22 per LIR, no exceptions. This is the currently accepted final /8 policy. If you feel strongly about changing that, I would suggest you write a policy proposal. This proposal only means to clarify what happens to address space that is returned to the RIPE NCC after that point, and makes sure we have allocation policy in place for all the address space that the RIPE NCC holds. Having a policy in place that provides the ability to hand out all currently held address space, along with an upper limit that is lower than the most common minimum allocation size, will have an impact on the minimum allocation size for those blocks. If the chairs feel otherwise, and think this policy proposal means to re-evaluate the text of the current final /8 policy, I will withdraw it immediately, as is my discretion as the author. Best regards, Remco On 23-05-11 12:25, "Daniel Suchy" <danny@danysek.cz> wrote:
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
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.