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

[Tim Gimmel]

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.