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.l...@blacklotus.net> wrote: > On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess <mysi...@gmail.com> wrote: >> On Fri, May 2, 2014 at 7:33 PM, John Santos <j...@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@arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact i...@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.l...@gmail.com | skype: blacklotus.net > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.