This is the problem I'm trying to solve and why I've been so vocal about it.
Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA 30338
770.656.1460 - Cell
770.399.9099- Office
℠ Eclipse Networks, Inc.
Conquering Complex Networks℠
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Tim Gimmel
Sent: Tuesday, June 24, 2014 4:04 PM
To: [email protected] List
Subject: Re: [arin-ppml] Policy discussion - Method of calculatingutilization
ARIN-2014-17
> The problem is that the current process has disenfranchised smaller
> companies who are somewhat frequently requesting space under the 3
> month need projection and are ending up with many /22's, /21's etc
> instead of the /20 or /19 that would have been possible prior to austerity
> measures.
> To make matters worse, it does not seem that such companies are
> substantially represented on PPML so it is creating an illusion that
> the policy is not necessary or would not be supported by the community
> at large (outside of PPML).
>
This is exactly what is happening, for example I have 4 /20's and a /19 from
earlier days, but now I have 7 /21's and that is the most I will ever be able
to request. We are using every possible way to keep IPv4 usage down.
--Tim
> Thanks, Jeff
>
>
> On Tue, Jun 17, 2014 at 8:55 AM, Andrew Dul <[email protected]> wrote:
> > As the current AC shepherd of this draft, I'm all for bringing this
> > to Baltimore if there is something substantial to discuss. However,
> > there is a lot of time between now and the next PPM time which we
> > could use on the mailing-list to get to a better understanding of
> > the issues surrounding the problem statement and crafting updated
> > policy
> language to solve the problem.
> > IMO, we shouldn't just "punt" to the next PPM. Everyone should also
> > realize that time to discuss this in person will be greatly limited
> > at the PPM by the current large docket of draft policies now before
> > the
> community.
> >
> > Andrew
> >
> >
> > On 6/16/2014 11:19 AM, Jeffrey Lyon wrote:
> >
> > Agreed re Baltimore
> >
> > Thanks, Jeff
> >
> > On Jun 16, 2014 2:13 PM, "David Huberman"
> > <[email protected]>
> > wrote:
> >>
> >>
> >>
> >> I believe we should discuss in Baltimore in front of a more
> >> substantial audience. There are by enough people participating
> >> here, in my opinion, for any "sense of the room" to make sense.
> >>
> >> David R Huberman
> >> Microsoft Corporation
> >> Senior IT/OPS Program Manager (GFS)
> >>
> >> ________________________________________
> >> From: [email protected] <[email protected]> on
> >> behalf of Andrew Dul <[email protected]>
> >> Sent: Monday, June 16, 2014 10:53:15 AM
> >> To: [email protected]
> >> Subject: Re: [arin-ppml] Policy discussion - Method of calculating
> >> utilization ARIN-2014-17
> >>
> >> Hello,
> >>
> >> I sent a longer summary of where this policy discussion is last
> >> week, I've pasted a link below to that message in the archive.
> >>
> >> http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html
> >>
> >> In general, I would say that this draft policy is stalled at this
> >> point. The 80% utilization policy underpins a large majority of
> >> the current policies and thus is a substantial change. There have
> >> been a few people who have voiced their support, but not enough
> >> that I believe would allow this policy to move forward as a
> >> recommended draft at this point.
> >>
> >> I would also point out that they current policy also constrains
> >> larger providers but in a different way as ARIN is now more closely
> >> enforcing the current policy of "efficiently utilized all previous
> allocations"
> >> (4.2.4.1) as noted during the NANOG PPC.
> >>
> >> Leif, I don't think there is an easy scaling algorithm to apply to
> >> utilization. The problem with a scaling algorithm is it likely
> >> will be perceived as "unfair" by organizations on one side of the size
> >> continuum. (We tried HD ratio for v6 and that was not easily
> >> understood, and lead to lots of confusion.)
> >>
> >> Thanks,
> >> Andrew
> >>
> >>
> >>
> >> On 6/13/2014 4:33 PM, Leif Sawyer wrote:
> >> > 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.
> >>
> >> _______________________________________________
> >> 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.
_______________________________________________
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.
