[address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

On Fri, 22 Sep 2017, Arash Naderpour wrote:

> Hi Carlos,
>

Hi,


>                   This proposal is not aimed at preventing the complete runout. That will happen. This proposal aims to preserve some tiny resources for
>             new entrants in
>                   this community, by trying to extend the time period until the runout occurs. We cannot "measure" its benefits until the runout occurs,
>             and we can then
>                   count how many new entrants did get a tiny portion of (new, never used before) IPv4 address space.
> 
>
>             The current policy without this change is doing the same, preserving tiny resources (/22) for new entrants. 
>             You are saying that there are some benefit and we cannot measure them now, but lets do it, am I right?
> 
>
>       I'm saying there is an obvious benefit: accomodate more new entrants.
>
>       Because an org is able to have/open multiple LIRs, the real new entrants number is not really easy to calculate :-)
> 
> 
> My understanding from this proposal is that it just change the allocation size but an org is still able to have/open multi LIRs,

Yes, the ability of having multiple LIRs is out of scope, regarding this 
proposal.

According to the PDP, afaik, anyone can submit a new proposal about that.


> If this proposal reach consensus, someone still can open four LIRs and 
> get the same amount of IP address as now.

That's my understanding too. or five, or six, or seven, and so on...


> The difference (from technical 
> point of view) is that we may have less entry in routing tables with an 
> /22 allocation

This is not really true, because routing-wise a /22 allocation can 
originate 4x /24 announcements anyway.


> but with this proposal we will have for sure 4x /24 entry 
> without gaining that much.

Or not, if the same org manages to open two (or four) new LIRs and the two 
(or four) /24s are aggregatable.

But the main goal here is not to preserve aggregability nor preventing the 
dfz from growing. Something that i expect from this proposal is buying out 
a bit more of time for those organizations which are not a LIR today.


Regards,
Carlos Friaças


> 
> Regards,
> 
> Arash
> 
>  
> 
> 
> 
> 
>
>             Regards,
>
>             Arash
> 
> 
> 
> 
> 
>
>              
>                         Arash
> 
> 
>
>                         On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown <tjc at ecs.soton.ac.uk> wrote:
>                               > On 21 Sep 2017, at 13:33, Aled Morris <aled.w.morris at googlemail.com> wrote:
>                               >
>                               > On 21 September 2017 at 12:43, Marco Schmidt <mschmidt at ripe.net> wrote:
>                               > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC
>                               > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation
>                               > directly from the RIPE NCC before.
>                               >
>                               > At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands?
>
>                               There?s http://www.potaroo.net/tools/ipv4/.
>
>                               Tim
> 
> 
> 
> 
> 
> 
> 
>