[address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling)

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 at 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.