> 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 <[email protected]> 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" > > <[email protected]> > > 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: [email protected] <[email protected]> on > >> behalf of Andrew Dul <[email protected]> > >> Sent: Monday, June 16, 2014 10:53:15 AM > >> To: [email protected] > >> 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: [email protected] > >> > [mailto:[email protected]] On Behalf Of Jeffrey Lyon > >> > Sent: Friday, June 13, 2014 2:41 PM > >> > To: Tim Gimmel > >> > Cc: [email protected] 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 > >> > <[email protected]> > >> > 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: [email protected] > >> >>> [mailto:[email protected]] > >> >>> On Behalf Of Owen DeLong > >> >>> Sent: Friday, May 02, 2014 8:14 PM > >> >>> To: Jeffrey Lyon > >> >>> Cc: [email protected] 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 > >> >>> <[email protected]> > >> >>> wrote: > >> >>> > >> >>>> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess <[email protected]> > wrote: > >> >>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos <[email protected]> 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 ([email protected]). > >> >>>>> Unsubscribe or manage your mailing list subscription at: > >> >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml > >> >>>>> Please contact [email protected] 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: [email protected] | skype: > >> >>>> blacklotus.net _______________________________________________ > >> >>>> PPML > >> >>>> You are receiving this message because you are subscribed to the > >> >>>> ARIN Public Policy Mailing List ([email protected]). > >> >>>> Unsubscribe or manage your mailing list subscription at: > >> >>>> http://lists.arin.net/mailman/listinfo/arin-ppml > >> >>>> Please contact [email protected] if you experience any issues. > >> >>> _______________________________________________ > >> >>> PPML > >> >>> You are receiving this message because you are subscribed to the > >> >>> ARIN Public Policy Mailing List ([email protected]). > >> >>> Unsubscribe or manage your mailing list subscription at: > >> >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >> >>> Please contact [email protected] if you experience any issues. > >> >> > >> >> _______________________________________________ > >> >> PPML > >> >> You are receiving this message because you are subscribed to the > >> >> ARIN Public Policy Mailing List ([email protected]). > >> >> Unsubscribe or manage your mailing list subscription at: > >> >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> >> Please contact [email protected] if you experience any issues. > >> > > >> > > >> > -- > >> > Jeffrey A. Lyon, CISSP-ISSMP > >> > Fellow, Black Lotus Communications > >> > mobile: (757) 304-0668 | gtalk: [email protected] | skype: > >> > blacklotus.net _______________________________________________ > >> > PPML > >> > You are receiving this message because you are subscribed to the > >> > ARIN Public Policy Mailing List ([email protected]). > >> > Unsubscribe or manage your mailing list subscription at: > >> > http://lists.arin.net/mailman/listinfo/arin-ppml > >> > Please contact [email protected] if you experience any issues. > >> > > >> > _______________________________________________ > >> > PPML > >> > You are receiving this message because you are subscribed to the > >> > ARIN Public Policy Mailing List ([email protected]). > >> > Unsubscribe or manage your mailing list subscription at: > >> > http://lists.arin.net/mailman/listinfo/arin-ppml > >> > Please contact [email protected] if you experience any issues. > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to the ARIN > >> Public Policy Mailing List ([email protected]). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact [email protected] if you experience any issues. > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to the ARIN > >> Public Policy Mailing List ([email protected]). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact [email protected] if you experience any issues. > > > > > > > > -- > Jeffrey A. Lyon, CISSP-ISSMP > Fellow, Black Lotus Communications > mobile: (757) 304-0668 | gtalk: [email protected] | skype: > blacklotus.net _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
