For reference, in the ARIN region we just got rid of our aggregation policy because it was almost never used, and staff had identified a loophole where a large address holder could have requested a large aggregation block, exhausted the free pool, and then taken their time about returning the smaller blocks. If you want to implement an aggregation policy in RIPE, it's probably worth taking the ARIN experience into account and drafting the policy to deal with those issues. -Scott <div class="gmail_quote">On Thu, Mar 19, 2015 at 4:07 AM Carsten Schiefner <<a href="mailto:ripe-wgs.cs@schiefner.de">ripe-wgs.cs@schiefner.de</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Antonis - On 19.03.2015 09:54, Antonis Lioumis wrote: > Recently my company got a /22 allocation through the well known transfer > procedure between LIR's. > In the past we also got the /22 we qualify from RIPE NCC's last /8. This > /22 was put aside for future use. > For aggregation purposes we asked RIPE NCC to return both /22 and get > back a /21 but according to current policies this is forbidden. > Since global routing table has exceeded 500000 prefixes and expected to > grow more maybe RIPE community should rethink permitting the exchange of > smaller IPv4 blocks with contiguous one. how about sending text for a policy (change) in this respect? :-) Cheers, Carsten </blockquote></div>