[arin-ppml] Policy discussion - Method of calculating utilization
Tim.Gimmel at metronetinc.com
Fri Jun 13 16:50:08 EDT 2014
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!
Metronet | Senior Network Engineer
3701 Communications Way | Evansville, IN 47715
> -----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
> 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
> On May 2, 2014, at 6:04 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
> > 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
> >> 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.
> 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.
More information about the ARIN-PPML