[address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

On Fri, Feb 8, 2019, at 17:24, Nikolas Pediaditis wrote:
> Dear Carlos, Radu-Adrian, all,
> 
> Following your questions, I have some numbers and other information 
> that might be useful.

Hello and thanks for the rapid response.

> 1. Currently, there will be 977,408 IPv4 addresses remaining in our 
> free pool once we are no longer able to allocate contiguous /22s. This 

Wow ! that's HUGE !
Under current conditions (equivalent on a /22 allocated at once, between 80 and 100 allocations per week) that would last about 10 weeks/2 months.
With the new policy, that would be transformed to 40 weeks/9 months, not counting the almost certain decrease in the LIR creation rate.

These numbers are turning me against the proposal the way it is right now. I will find welcome any changes that may help reduce the delay. Maybe the impact analysis will bring a little light. 

> 2. Over the past three years, we have recovered the following amounts 
> of IPv4 addresses:
> 
> 2016: 83,712
> 2017: 106,368
> 2018: 53,824

OK, not really important for this matter. 1 week of allocation for a "good year" (like 2017).

> 3. We have assigned the following amounts of IPv4 addresses as 
> temporary assignments over the past three years:
> 
> 2016: 205,568
> 2017: 188,928
> 2018: 162,048
> 
> (Note that these figures represent the sum of all temporary assignments 
> made in that year.)

So for the last 3 years, a /14 would have been (more than) enough. Probably mixing pools or exchanging blocks between the pools would help avoid reduce the delay of "IPv4 availability". Is a polycy needed for that or is it just NCC internal housekeeping? 

> Temporary assignments are made from a /13 that has been reserved for 
> this purpose. When a temporary assignment is returned, it is added back 
> to this pool.
> 
> Finally, I would like to clarify that IPv4 allocations and temporary 
> assignments come from two separate pools - neither influences the other.
> 
> I hope this helps.

It certainly did.

-- 
Radu-Adrian FEURDEAN