[arin-ppml] Draft Policy ARIN-2019-21: Reserved Pool Replenishment
Martin Hannigan
hannigan at gmail.com
Fri Jan 3 14:24:16 EST 2020
Let's fix the math I broke. Mea culpa. Inline. I think I got it right this
time. :)
On Fri, Jan 3, 2020 at 11:46 AM Martin Hannigan <hannigan at gmail.com> wrote:
>
>
> On Mon, Dec 30, 2019 at 4:25 PM David Farmer <farmer at umn.edu> wrote:
>
>>
>> On Mon, Dec 30, 2019 at 2:08 PM Martin Hannigan <hannigan at gmail.com>
>> wrote:
>>
>>>
>>> On Mon, Dec 30, 2019 at 09:15 Joe Provo <ppml at rsuc.gweep.net> wrote:
>>>
>>>> On Fri, Dec 27, 2019 at 01:00:15PM -0600, David Farmer wrote:
>>>> > On Fri, Dec 27, 2019 at 12:01 PM John Curran <jcurran at arin.net>
>>>> wrote:
>>>> [snip]
>>>>
>>> [ clip ]
>
>
[ clip ]
I'll agree that the intended longevity of the 4.4 pool was discussed at the
>> time of its creation or at least when it was expanded and it was intended
>> as a relatively short-term crutch for the IXP, TLDs and other critical
>> infrastructure IPv4 micro allocation growth. Personally, I wouldn't be
>> opposed to right-sizing the 4.4 pool, with priority on other returned
>> resources over the waiting list for replenishing this pool.
>>
>> Maybe right-size it down to a 5 or 6 year supply, based on the last 5 or
>> 6 years of allocations, with the excess going to the waiting list
>>
>>
> Let's assume the pool size is a /15 and use an average rate of allocation
> IXP+CI of 18 /24 per year.
>
> YEAR 0 - YEAR 5 = 105 /24's (generous as I measured beginning of period
> to end of period)
>
Corrected, year 0 to 5 and BOP to EOP = 105 /24's. However, apples to
apples occurs when comparing /24's to /24's. :)
[ clip broken math, insert good math]
A /16 would probably be forgiving and return a /16. Noise. But worthy in
the current context.
BOP / 24 EOP /24
YR 0
*512* *494*
*YR 1* *494* *477*
*YR 2* *477* *459*
*YR 3* *459* *442*
*YR 4* *442* *424*
*YR 5 <---* *424*
*407 *
YR 6 407 389
YR 7 389 371
YR 8 371 354
YR 9 354 336
YR 10 336 319
YR 11 319 301
YR 12 301 284
YR 13 284 266
YR 14 266 248
The 4.10 pool needs more run rate IMHO. However, a thumb in the air would
suggest that it could be cut in half. Food for thought.
YMMV,
-M<
>> ARIN staff, could we get a history of the number of IPv4 micro
>> allocations for each year, by type, going back to the implementation of
>> ARIN-2012-6?
>>
>> However, I don't recall any such discussion regarding the 4.10 pool.
>> Quite the contrary it was my impression the 4.10 pool was intended to be
>> around for at least an extended period of time, if not indefinitely. In
>> short, it was intended to ensure the availability of small amounts of IPv4
>> needed for IPv6 deployment for a very long time. Therefore, I would be
>> opposed to any kind of reduction to the 4.10 pool, other than by
>> allocations as the policy intends, and if or when the pool starts to run
>> low I would like to see it replenished.
>>
>> A little history; ARIN-2008-5 is what became NRPM Section 4.10.
>> https://www.arin.net/vault/policy/proposals/2008_5.html
>>
>> While I think the waiting list is an important tool to ensure resources
>> are not stuck at ARIN, I think continued micro allocations (4.4) and
>> allocations of IPv4 needed to Facilitate IPv6 Deployment (4.10) should have
>> priority for returned resources over the waiting list.
>>
>> Thanks.
>>
>> --
>> ===============================================
>> David Farmer Email:farmer at umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE Phone: 612-626-0815
>> Minneapolis, MN 55414-3029 Cell: 612-812-9952
>> ===============================================
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200103/c46f3e6a/attachment.htm>
More information about the ARIN-PPML
mailing list