[arin-ppml] Policy discussion - Method of calculating utilization ARIN-2014-17

Jeffrey Lyon jeffrey.lyon at blacklotus.net
Mon Jun 16 14:19:51 EDT 2014


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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140616/3eb0c28e/attachment.html>


More information about the ARIN-PPML mailing list