[arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17
lar at mwtcorp.net
lar at mwtcorp.net
Wed Jun 25 12:26:32 EDT 2014
On Thu, 26 Jun 2014 00:49:27 +0900
Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
> I think you intended this for ARIN-2014-14? On that proposal I would agree
> to /20 as a compromise.
Opps, sorry you are right, but in general the problem occurs here also.
My instinct has been to support 2014-17 but I can see that if your large enough
and with smaller allocations, aggregating all previous allocations might have
you at 80% before you assign the first address from the last allocation.
Instead of aggregating all previous allocations, could we set some aggregate package size.
Maybe aggregating your newest previous allocations up to a /18 (pick a number), or
your newest allocation whichever is larger. Feels a little clunky but it
might ease the problem.
> Thanks, Jeff
> On Jun 25, 2014 11:43 AM, <lar at mwtcorp.net> wrote:
>> On Tue, 24 Jun 2014 15:04:17 -0700
>> Andrew Dul <andrew.dul at quark.net> wrote:
>>> The problem described below appears to be more related to the current
>>> 3-month window for additional allocations, not necessarily the
>>> utilization metric. The 3-month window has had a number of
>>> side-effects, some of which were not anticipated when that policy was
>>> put in place. With run-out in the region approaching rapidly we need to
>>> turn our attention to the longer term policies which will support the
>>> desires of the community (as best possible) through the transfer market
>>> or other mechanisms. Changing the utilization formula (for those
>>> requests which do require a formal needs assessment) may be part of the
>>> policy changes which are needed.
>>> Some of the problem of the formula are long standing. If your last
>> was a /22 and you have a larger customer come to you with a legitimate and
>> clear need for a /22 or /21 you have no way of getting it no matter what %
>> is in the policy. It has always seemed to me, that "need" should have a
>> lot more to
>> do with what you are going to do with the requested allocation, and what
>> is available
>> in your current allocations, than some arbitrary utilization percentage.
>> problem is that ARIN would then have to get into network design arguments.
>> The argument that just removing the needs test for smaller allocations
>> has some merit. The problem seems to be in defining what is small. A
>> compromise of /20 has
>> been suggested and I think it's reasonable. Even though I support needs
>> testing I can support removing it at a /20 and smaller.
>> Larry Ash
>>> On 6/24/2014 1:08 PM, Steven Ryerse wrote:
>>>> This is the problem I'm trying to solve and why I've been so vocal about
>>>> Steven Ryerse
>>>> 100 Ashford Center North, Suite 110, Atlanta, GA 30338
>>>> 770.656.1460 - Cell
>>>> 770.399.9099- Office
>>>> ℠ Eclipse Networks, Inc.
>>>> Conquering Complex Networks℠
>>>> -----Original Message-----
>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>>>> Behalf Of Tim Gimmel
>>>> Sent: Tuesday, June 24, 2014 4:04 PM
>>>> To: arin-ppml at arin.net List
>>>> Subject: Re: [arin-ppml] Policy discussion - Method of
>>>> calculatingutilization ARIN-2014-17
>>>> The problem is that the current process has disenfranchised smaller
>>>>> companies who are somewhat frequently requesting space under the 3 month
>>>>> need projection and are ending up with many /22's, /21's etc instead of the
>>>>> /20 or /19 that would have been possible prior to austerity measures.
>>>>> To make matters worse, it does not seem that such companies are
>>>>> substantially represented on PPML so it is creating an illusion that the
>>>>> policy is not necessary or would not be supported by the community at large
>>>>> (outside of PPML).
>>>>> This is exactly what is happening, for example I have 4 /20's and a
>>>> /19 from earlier days, but now I have 7 /21's and that is the most I will
>>>> ever be able to request. We are using every possible way to keep IPv4
>>>> usage down.
>>> 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:
>>> Please contact info at arin.net if you experience any issues.
>> Larry Ash
>> Network Administrator
>> Mountain West Telephone
>> 123 W 1st St.
>> Casper, WY 82601
>> Office 307 233-8387
>> 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:
>> Please contact info at arin.net if you experience any issues.
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387
More information about the ARIN-PPML