[arin-ppml] Policy discussion - Method of calculating utilization

[Owen DeLong]

While I support Jeffry’s proposal for changing the calculation method, in terms of changing the threshold, I’d like to say that I really think it is time to stop trying to re-arrange the IPv4 deck chairs and get on board the IPv6 luxury liners that have come to rescue us from the sinking IPv4 ship.

Owen

On May 2, 2014, at 6:04 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:

> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess <mysidia at gmail.com> wrote:
>> On Fri, May 2, 2014 at 7:33 PM, John Santos <JOHN at egh.com> wrote:
>>> On Fri, 2 May 2014, Jimmy Hess wrote:
>> 
>>> I think 95% is too high, if the previous example of 3 /24's at 100% and
>>> 1 /24 at 75% is realistic.  That works out to 93.75% aggregate utilization,
>>> not quite reaching the bar, so 90% might be a better threshold.
>> 
>> For 3 /24s   yes.      The difficulty here, is trying to pick a single
>> utilization proportion that works regardless   of the aggregate
>> allocation size, to allow for the loss of the oddball /26 or /27 that
>> can neither be returned nor reused,    perhaps another method is in
>> order  than presuming a single   aggregate utilization criterion  is
>> the most proper.
>> 
>> 
>> The more resources you are allocated,  the more opportunity to make
>> your resource allocation efficient.    By the time you get down to a
>> /26,   an entire  /24 is less than 0.4%.
>> 
>> Aggregate Resources Allocated                     Required Aggregate
>> Utilization criterion
>> more than a /25                                                75%
>> more than a /22,                                               80%
>> more than a /20                                                85%
>> more than a /19                                                90%
>> more than a /18                                                95%
>> more than a /17                                                97%
>> more than a /16                                                98%
>> more than a /15                                                99%
>> 
>> 
>> 
>>> 
>>> OTOH, /24's are pretty small and maybe that example was just for
>>> illustration.  If people really in this situation have much larger
>>> allocations, they would be easier to slice and dice and thus use (relatively)
>>> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused, which
>>> even if contiguous are hard to redeploy for some other use.  75% of a /16
>>> would leave 16384 unused addresses, which could be utilized much more easily.
>>> 
>>> 
>>> Personally, I don't much care since my company has its /24, and that's
>>> probably all the IPv4 we'll ever need :-)
>>> 
>>> 
>>> --
>>> John Santos
>>> Evans Griffiths & Hart, Inc.
>>> 781-861-0670 ext 539
>>> 
>> 
>> 
>> 
>> --
>> -JH
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 
> Jimmy,
> 
> I would not support scaling this beyond 80% except at the larger
> allocation levels (eg. perhaps /17 and shorter, aggregate).
> 
> As a practical matter I believe these measures should be handled as
> separate policy proposals. The current proposal should be limited to
> the calculation method and perhaps you could write a new proposal if
> you wanted to change the utilization threshold?
> 
> Thanks,
> -- 
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.