[arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17
Steven Ryerse
SRyerse at eclipse-networks.com
Tue Jun 24 16:08:24 EDT 2014
This is the problem I'm trying to solve and why I've been so vocal about it.
Steven Ryerse
President
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.
--Tim
> Thanks, Jeff
>
>
> On Tue, Jun 17, 2014 at 8:55 AM, Andrew Dul <andrew.dul at quark.net> wrote:
> > As the current AC shepherd of this draft, I'm all for bringing this
> > to Baltimore if there is something substantial to discuss. However,
> > there is a lot of time between now and the next PPM time which we
> > could use on the mailing-list to get to a better understanding of
> > the issues surrounding the problem statement and crafting updated
> > policy
> language to solve the problem.
> > IMO, we shouldn't just "punt" to the next PPM. Everyone should also
> > realize that time to discuss this in person will be greatly limited
> > at the PPM by the current large docket of draft policies now before
> > the
> community.
> >
> > Andrew
> >
> >
> > On 6/16/2014 11:19 AM, Jeffrey Lyon wrote:
> >
> > Agreed re Baltimore
> >
> > Thanks, Jeff
> >
> > On Jun 16, 2014 2:13 PM, "David Huberman"
> > <David.Huberman at microsoft.com>
> > wrote:
> >>
> >>
> >>
> >> I believe we should discuss in Baltimore in front of a more
> >> substantial audience. There are by enough people participating
> >> here, in my opinion, for any "sense of the room" to make sense.
> >>
> >> David R Huberman
> >> Microsoft Corporation
> >> Senior IT/OPS Program Manager (GFS)
> >>
> >> ________________________________________
> >> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on
> >> behalf of Andrew Dul <andrew.dul at quark.net>
> >> Sent: Monday, June 16, 2014 10:53:15 AM
> >> To: arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] Policy discussion - Method of calculating
> >> utilization ARIN-2014-17
> >>
> >> Hello,
> >>
> >> I sent a longer summary of where this policy discussion is last
> >> week, I've pasted a link below to that message in the archive.
> >>
> >> http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html
> >>
> >> In general, I would say that this draft policy is stalled at this
> >> point. The 80% utilization policy underpins a large majority of
> >> the current policies and thus is a substantial change. There have
> >> been a few people who have voiced their support, but not enough
> >> that I believe would allow this policy to move forward as a
> >> recommended draft at this point.
> >>
> >> I would also point out that they current policy also constrains
> >> larger providers but in a different way as ARIN is now more closely
> >> enforcing the current policy of "efficiently utilized all previous
> allocations"
> >> (4.2.4.1) as noted during the NANOG PPC.
> >>
> >> Leif, I don't think there is an easy scaling algorithm to apply to
> >> utilization. The problem with a scaling algorithm is it likely
> >> will be perceived as "unfair" by organizations on one side of the size
> >> continuum. (We tried HD ratio for v6 and that was not easily
> >> understood, and lead to lots of confusion.)
> >>
> >> Thanks,
> >> Andrew
> >>
> >>
> >>
> >> On 6/13/2014 4:33 PM, Leif Sawyer wrote:
> >> > I was really hoping somebody would suggest, perhaps, some sort of
> >> > easy-to-apply scaling algorithm so that it makes it easier for
> >> > the smaller guys to get the space they need, but harder for the
> >> > bigger guys to game the system.
> >> >
> >> > I'm sure there's some sort of curve that fits, but my advanced
> >> > maths are limited to Pythagoras.
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: arin-ppml-bounces at arin.net
> >> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon
> >> > Sent: Friday, June 13, 2014 2:41 PM
> >> > To: Tim Gimmel
> >> > Cc: arin-ppml at arin.net List
> >> > Subject: Re: [arin-ppml] Policy discussion - Method of
> >> > calculating utilization
> >> >
> >> > Tim,
> >> >
> >> > I am also uncertain of the current status but would like to see
> >> > some progress.
> >> >
> >> > Thanks, Jeff
> >> >
> >> > On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel
> >> > <Tim.Gimmel at metronetinc.com>
> >> > wrote:
> >> >> I not really sure where this policy discussion is at the moment,
> >> >> but I want to assert the current method places a strain on small
> >> >> carriers just trying to do business. We are in the process of
> >> >> implementing IPv6, but is will be a long journey.
> >> >> Overall I am way past 80% utilization, but because my last
> >> >> allocation (and this is based on actual usage, not just what has
> >> >> been 'swiped') has not yet reached 80% we are practically stymied.
> >> >>
> >> >> Tim's 2 cents!
> >> >>
> >> >> Tim
> >> >>
> >> >> Tim Gimmel
> >> >> Metronet | Senior Network Engineer
> >> >> 3701 Communications Way | Evansville, IN 47715
> >> >> Office: 812.456.4750
> >> >> www.MetronetInc.com
> >> >>
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: arin-ppml-bounces at arin.net
> >> >>> [mailto:arin-ppml-bounces at arin.net]
> >> >>> On Behalf Of Owen DeLong
> >> >>> Sent: Friday, May 02, 2014 8:14 PM
> >> >>> To: Jeffrey Lyon
> >> >>> Cc: arin-ppml at arin.net List
> >> >>> Subject: Re: [arin-ppml] Policy discussion - Method of
> >> >>> calculating utilization
> >> >>>
> >> >>> 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.
> >> >>> _______________________________________________
> >> >>> 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.
> >> >>
> >> >> _______________________________________________
> >> >> 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.
> >> >
> >> >
> >> > --
> >> > 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.
> >> >
> >> > _______________________________________________
> >> > 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.
> >>
> >> _______________________________________________
> >> 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.
> >> _______________________________________________
> >> 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.
> >
> >
>
>
>
> --
> 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.
_______________________________________________
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.
More information about the ARIN-PPML
mailing list