Hi Daniel, 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. 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. 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. Best, Remco On 23-05-11 11:41, "Daniel Suchy" <danny@danysek.cz> wrote:
Hello, one thing should be considered here - this proposal in section 3b states, that minimum allocation sizes for the relevant /8 blocks will be updated if necessary.
There're a lot of ranges with /21 longest prefix now. Some people have filters in accordance to (currently) RIPE-510 document. This may be source of some operational troubles, if longest prefixes will be changed frequently - as filters will have to be updated in some networks. There's no such requirement these days (only new prefixes need to be added).
I'll rather see no changes in terms of "allowing" longer prefixes in other subnets. Changes here will more likely help some people deaggregate their prefixes in global table and only few prefixes will be announced rightly. Aggregation should be one of major goals, and even RIPE cannot enforce it, it at least should help here (and RIPE-510 is helpfull). This proposal goes against this goal sometimes, I think.
Last /8 provides quite huge number of /22 to cover future requests long-term. I think, that returned space should be reserved/used for covering potential request for more than 1024 IP addresses in one block - as we cannot imagine future these days, and someone can have good reasons to obtain larger address space... and if will be some addresses available, I don't see any reason to reject the request.
Due similar reasons - I don't support section 4 of new proposal (multiple allocations up to an equivalent of a /22). This will also cause changes in RIPE-510 and this will simplify address space deaggregation for many "bad guys".
So, instead of applying "last /8 policy" to returned space, reserving returned space as we have reserved /16 from last /8 seems to be better option for me (and potentially serve assignments like /21). Current policies used for reusing returned space are sufficient and these can be applied anytime.
Last /8 should be applied ONLY to last /8. And aggregation should be always keeped in mind, when some change in address policy is proposed.
I don't support this proposal and I suggest changes in it mentioned above.
With regards, Daniel
On 05/20/2011 12:11 PM, Emilio Madaio wrote:
Dear Colleagues,
A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region", is now available for discussion.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2011-03/
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 17 June 2011.
Regards
Emilio Madaio Policy Development Officer RIPE NCC
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.