[arin-ppml] Draft Policy ARIN-2012-6: Revising Section 4.4 C/I Reserved Pool Size

[David Farmer]

On 10/17/12 22:07 , Christopher Morrow wrote:
> On Wed, Oct 17, 2012 at 10:27 PM, David Farmer <farmer at umn.edu> wrote:
...
> yup, it'd be nice if that were easier to parse automatedly :(
> I wonder if adding the policy under which the block was allocated
> could be easily added to the allocation data at:
>    <ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest>

Yea, if possible that would be a good thing to add to that set of data.

> that'd make this sort of thing simpler over all.
>
>> CI allocations:
>> 2000: 14 prefixes, 14 /24s
>> 2001: 0 prefixes, 0 /24s
>> 2002: 0 prefixes, 0 /24s
>> 2003: 14 prefixes, 35 /24s
>> 2004: 12 prefixes, 40 /24s
>> 2005: 6 prefixes, 10 /24s
>> 2006: 4 prefixes, 12 /24s
>> 2007: 8 prefixes, 20 /24s
>> 2008: 10 prefixes, 46 /24s
>> 2009: 2 prefixes, 3 /24s
>> 2010: 11 prefixes, 68 /24s
>> 2011: 8 prefixes, 23 /24s
>> 2012TD: 1 prefixes, 4 /24s
>> Total: 90 prefixes, 275 /24s
>>
>> IX allocations:
>> 1998: 1 prefixes, 1 /24s
>> 1999: 1 prefixes, 1 /24s
>> 2000: 2 prefixes, 2 /24s
>> 2001: 3 prefixes, 6 /24s
>> 2002: 3 prefixes, 3 /24s
>> 2003: 2 prefixes, 2 /24s
>> 2004: 6 prefixes, 6 /24s
>> 2005: 2 prefixes, 2 /24s
>> 2006: 2 prefixes, 2 /24s
>> 2007: 5 prefixes, 15 /24s
>> 2008: 2 prefixes, 3 /24s
>> 2009: 7 prefixes, 12 /24s
>> 2010: 3 prefixes, 4 /24s
>> 2011: 7 prefixes, 8 /24s
>> 2012TD: 5 prefixes, 5 /24s
>> Total: 51 prefixes, 72 /24s
>> (There were 5 IX allocation that did show up in ARIN Whois, there are 56
>> allocation on the web page above)
>>
>> Grand Total (CI+IX): 141 prefixes, 347 /24s
>
> there doesn't appear to be much pattern directly in the allocation rates :(

Yea, I didn't see much of one either.

> I still think the largest easy driver is gTLD growth, and that's not
> going to be very predictable either.

Thinking about it, more gTLDs will drive the growth in CI.  However, I 
think more important than absolute growth in gTLDs will be the growth in 
the number of gTLD operators, which I think will be a better predictor 
of the number of /24s needed.

Even if you only serve one gTLD per address, you could serve as many as 
200+ gTLDs per /24 prefix, replicated across some number of prefixes, 
per operator.  So, I think the number of gTLD operators a is more 
relevant predictor for the growth in CI allocations ARIN will need to 
make.

Even very large growth in the number of gTLDs could be accommodated by 
only moderate growth in CI allocations made by ARIN, if the number of 
gTLD operators remains relatively small, and each operator services a 
large number of gTLD.  However conversely, only a small growth in gTLDs 
that results in many more gTLD operators, each servicing only a 
relatively small number of gTLDs, could result in a large growth in CI 
allocations made by ARIN.

Therefore, the absolute number of gTLDs is probably not a good predictor 
for growth in CI allocations made by ARIN, and how the gTLD operator 
market develops over time will be more important for predicting the 
growth in CI allocations made by ARIN.

> Enlarging the hold-out for CI to
> a /15 means we can grow 1.5x today's current allocations before we
> have to dip back into the larger 'free' pool. I'm not sure that a /15
> is enough, I also don't see an easy way to predict what would be big
> enough.

Given ICANN's discussions to significantly expand the number of gTLDs, I 
think expanding the CI reservation from /16 to /15 is a reasonable 
precaution.  However, my prediction is that a /15 should be sufficient 
for several years of gTLD and other CI growth, I'm think 2 to 5 years. 
If that turns out to be incorrect, then I would support expanding the 
reservation with future returned space as necessary.  But, I think we 
can take wait and see approach in dealing with that contingency.

David.