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
