On Thu, 26 Jun 2014 00:49:27 +0900
Jeffrey Lyon <[email protected]> wrote:
Larry,
I think you intended this for ARIN-2014-14? On that proposal I would agree
to /20 as a compromise.
Opps, sorry you are right, but in general the problem occurs here also.
My instinct has been to support 2014-17 but I can see that if your large enough
and with smaller allocations, aggregating all previous allocations might have
you at 80% before you assign the first address from the last allocation.
Instead of aggregating all previous allocations, could we set some aggregate
package size.
Maybe aggregating your newest previous allocations up to a /18 (pick a number),
or
your newest allocation whichever is larger. Feels a little clunky but it
might ease the problem.
Larry
Thanks, Jeff
On Jun 25, 2014 11:43 AM, <[email protected]> wrote:
On Tue, 24 Jun 2014 15:04:17 -0700
Andrew Dul <[email protected]> wrote:
The problem described below appears to be more related to the current
3-month window for additional allocations, not necessarily the
utilization metric. The 3-month window has had a number of
side-effects, some of which were not anticipated when that policy was
put in place. With run-out in the region approaching rapidly we need to
turn our attention to the longer term policies which will support the
desires of the community (as best possible) through the transfer market
or other mechanisms. Changing the utilization formula (for those
requests which do require a formal needs assessment) may be part of the
policy changes which are needed.
Some of the problem of the formula are long standing. If your last
allocation
was a /22 and you have a larger customer come to you with a legitimate and
clear need for a /22 or /21 you have no way of getting it no matter what %
utilization
is in the policy. It has always seemed to me, that "need" should have a
lot more to
do with what you are going to do with the requested allocation, and what
is available
in your current allocations, than some arbitrary utilization percentage.
The
problem is that ARIN would then have to get into network design arguments.
The argument that just removing the needs test for smaller allocations
entirely
has some merit. The problem seems to be in defining what is small. A
compromise of /20 has
been suggested and I think it's reasonable. Even though I support needs
testing I can support removing it at a /20 and smaller.
Larry Ash
Andrew
On 6/24/2014 1:08 PM, Steven Ryerse wrote:
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
_______________________________________________
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.
Larry Ash
Network Administrator
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387
_______________________________________________
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.
Larry Ash
Network Administrator
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387
_______________________________________________
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.
