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

[Martin Hannigan]

Jeffrey,

Let's be clear without political statements. I suggest we stamp all new v4 proposals "post exhaustion implementation" from here. Aside from the MAU reduction, I can't imagine anything else worthy of the effort. 

Agree or not? 

Best, 

-M< 





> On May 2, 2014, at 21:25, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
> 
>> On Sat, May 3, 2014 at 10:20 AM, Martin Hannigan <hannigan at gmail.com> wrote:
>> 
>> Yes it is. Are you expecting such a change to happen before or after? The
>> recent fury of v4 policy seems geared towards sooner. I think a moratorium
>> is in order except for transfer related policy at this juncture.
>> 
>> Best,
>> 
>> -M<
>> 
>> 
>> 
>>> On Friday, May 2, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
>>> 
>>> On Sat, May 3, 2014 at 10:12 AM, Martin  Hannigan <hannigan at gmail.com>
>>> wrote:
>>>> 
>>>> All,
>>>> 
>>>> Why should entities get a break on a standard in existence and applied
>>>> to all for years?
>>>> 
>>>> And why is tbe aggregate, in examples given, broken? ARIN already
>>>> applies that to some applicants.
>>>> 
>>>> No support.
>>>> 
>>>> Support post exhaustion.
>>>> 
>>>> Best,
>>>> 
>>>> Martin
>>>> 
>>>>>> On May 2, 2014, at 20:52, 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
>>>>> t... but IPv4 is already exhausted?
>>> 
>>> 
>>> --
>>> Jeffrey A. Lyon, CISSP-ISSMP
>>> Fellow, Black Lotus Communications
>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>> blacklotus.net
> 
> Martin,
> 
> My point is that we're already exhausted. We're in Phase 4, it doesn't
> get much more exhausted than this. Are you suggesting that we wait
> until there is a massive backlog of requests before supporting the
> proposal?
> 
> -- 
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net