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.
