On Sat, May 3, 2014 at 10:12 AM, Martin Hannigan <[email protected]> wrote: > > All, > > Why should entities get a break on a standard in existence and applied to all > for years? > > And why is tbe aggregate, in examples given, broken? ARIN already applies > that to some applicants. > > No support. > > Support post exhaustion. > > Best, > > Martin > >> On May 2, 2014, at 20:52, 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. > _______________________________________________ > 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.
... but IPv4 is already exhausted? -- 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.
