On Tue, Sep 30, 2014 at 7:12 PM, Bill Woodcock wrote:
>> - increase the reserve pool to a /15
>> - increase the minimum allocation for an IXP to a /22
>
> Quadrupling the allocation while doubling the pool halves the number of IXPs
> served, and I think it would be unfortunate and short-sighted t
A more rational threshold for that measurement would be 248 or even 240
participants.
Consider most IXPs have at least a couple of route servers (2 IPs) and likely
need some numbers for the physical infrastructure of the IXP. Additionally,
there are only 254 usable IP addresses in a /24, and ha
I would support option 3.
Owen
On Sep 30, 2014, at 11:06 , Leif Sawyer wrote:
> Delaying implementation until further down the run-out line doesn't help orgs
> with current needs.
>
>
> I think that as the "spirit" of this is to help out the smaller organizations,
> the argument could easily
On 9/30/14, 18:12 , Bill Woodcock wrote:
- increase the reserve pool to a /15
- increase the minimum allocation for an IXP to a /22
Quadrupling the allocation while doubling the pool halves the number of IXPs
served, and I think it would be unfortunate and short-sighted to let that
happen.
.
On Tue, Sep 30, 2014 at 3:45 PM, Martin Hannigan wrote:
> Thanks.
>
> The discussion in the Open-IX community seems to support a CI change
> related to IXPs in the following manners:
>
> - use sparse allocations for CI space
>
> Helps to avoid renumbering of growing CI. We will use the suggestion
> - increase the reserve pool to a /15
> - increase the minimum allocation for an IXP to a /22
Quadrupling the allocation while doubling the pool halves the number of IXPs
served, and I think it would be unfortunate and short-sighted to let that
happen.
To inject some facts into the debate:
ht
Thanks.
The discussion in the Open-IX community seems to support a CI change
related to IXPs in the following manners:
- use sparse allocations for CI space
Helps to avoid renumbering of growing CI. We will use the suggestions
process for this.
- increase the reserve pool to a /15
Appears to b
Delaying implementation until further down the run-out line doesn't help orgs
with current needs.
I think that as the "spirit" of this is to help out the smaller organizations,
the argument could easily be made that limiting this to orgs with < 18 isn't
needlessly hurtful toward larger orgs.
The team review provides for serialization of requests which makes
this possible, and hence it should continue even if one requestor
has unmet need. Even after completion depletion, parties will want
to know that they are being approved and placed on the list in the
appropriate order.
FYI,
On Sep 30, 2014, at 12:48 PM, Mike Burns wrote:
> Hi John,
>
>>> Reading between the lines, I think this is about ARIN's max carrying rate
>>> without schedule slippage.
>
>> We actually have been fairly creative (e.g. moving IPv6 and ASN
> requests to additional resources to free up more time
Hello,
The staff and legal assessment below noted some concerns regarding this
policy. To alleviate some of these concerns we have thought about the
following three changes to the draft policy.
1. Delay implementation of the policy, such that the free pool was small
enough that a large organizat
Hi John,
Reading between the lines, I think this is about ARIN's max carrying rate
without schedule slippage.
We actually have been fairly creative (e.g. moving IPv6 and ASN
requests to additional resources to free up more time for IPv4
requests); there are other similar options if needed, s
If folks are (still) really interested in playing around with the Run-Out
forecasting,
I developed a set of scripts to automate this:
https://github.com/akhepcat/ARIN-Runout
You can play around with the polynomial functions to see what works best on the
timescales that you're interested in.
I
On Sep 30, 2014, at 11:56 AM, Bill Owens wrote:
> On Tue, Sep 30, 2014 at 11:46:24AM -0400, Mike Burns wrote:
>> Also we know that most allocation requests are for much larger
>> blocks, thus we know that applicants will go away for at least three
>> months between their meager allocations.
>
>
On Sep 30, 2014, at 11:46 AM, Mike Burns wrote:
> Hi John,
>
> Thanks for the info.
> I don't think Geoff is properly adjusting for ARIN's team review rate, which
> is around 200 per month.
Geoff's numbers are based allocation rate.
> Reading between the lines, I think this is about ARIN's ma
On Tue, Sep 30, 2014 at 11:46:24AM -0400, Mike Burns wrote:
> Also we know that most allocation requests are for much larger
> blocks, thus we know that applicants will go away for at least three
> months between their meager allocations.
Does the 4.1.8 policy of assigning only a single block for
Hi John,
Thanks for the info.
I don't think Geoff is properly adjusting for ARIN's team review rate, which
is around 200 per month.
Reading between the lines, I think this is about ARIN's max carrying rate
without schedule slippage.
Considering the nature of the remaining pool dregs, ARIN will
On Sep 30, 2014, at 10:45 AM, Matthew Kaufman wrote:
> I've been watching Geoff's ARIN runout prediction slip out into the future,
> and reading here about increased review leading to slower processing... Is
> runout being delayed just because legitimate applications for space are
> queuing up
I've been watching Geoff's ARIN runout prediction slip out into the future, and
reading here about increased review leading to slower processing... Is runout
being delayed just because legitimate applications for space are queuing up?
Can we get a report on historical and current application que
19 matches
Mail list logo
