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

[Jeffrey Lyon]

On Sat, May 3, 2014 at 10:31 AM, Martin  Hannigan <hannigan at gmail.com> wrote:
>
> 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

Martin,

Please forgive me if I am just confused or ignorant, but I agree we
are now exhausted and whether a proposal is stamped post-exhaustion or
otherwise, its implementation would have an immediate effect.

What am I missing?

Thanks,
-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net