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.

Reply via email to