[arin-ppml] Policy discussion - Method of calculating utilization

[Martin Hannigan]

Yes it is. Are you expecting such a change to happen before or after? The
recent fury of v4 policy seems geared towards sooner. I think a moratorium
is in order except for transfer related policy at this juncture.

Best,

-M<



On Friday, May 2, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:

> On Sat, May 3, 2014 at 10:12 AM, Martin  Hannigan <hannigan at gmail.com>
> 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 <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
> >> t... but IPv4 is already exhausted?
>
> --
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com <javascript:;> |
> skype: blacklotus.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140502/4b637f8d/attachment.htm>