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

[Christopher Morrow]

On Thu, Oct 18, 2012 at 12:46 AM, David Farmer <farmer at umn.edu> wrote:
> 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.

I suspect that the normal operating procedure is to put one NS on each
/24(or48?), and likely a set of these per TLD.
You don't want some problem with atld to affect btld just because you
put them both on the same /24||/48 :(

Looking at the rootzone (http://www.internic.net/zones/root.zone):
Zone count: 272
NSHost count: 1182
NSAddr count: 1620

of the addresses there I see some re-use of the actual /32 || /128, 59
occurances of the same /32 or /128.
488 v6 addresses
274 unique /48s in that set

1132 v4 addresses
713 unique /24s

> 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

it seems that a lot of the usage here today is 1 /32 per /24. This
permits the operator to isolate routing globally for the each NS host.
For instance, bad things happening to ns1.atld (1.2.3.4) don't have to
affect ns2.atld (1.2.4.4) and they don't have to affect ns1.btld
(1.2.5.4) nor ns2.btld (1.2.6.4).

it's clearly not the only solution, but it looks as if over half are
being done this way?

> 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.

I'm not convinced... there's an alternate view that: "If you pony up
185k for a tld + some money for lawyers and consultants and gear and
network links... you can pony up money for a /24 from 'the v4 market'
people."

so maybe this is all not important? (for ci space)

> 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

your own logic above doesn't get to this conclusion, but does kind of
say: "we have no way to predict this" (which I agreed with previously,
too).

> 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

I don't disagree that 'enlarging it..' seems good. I don't get a good
feeling at all about how large is 'enough'.

> 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.

I think the timeframe is not 2-5 yrs, but 'how long is it that v4 is
still relevant/required at the TLD level?" and I'd expect that to last
much further out than 2-5yrs... I was thinking at least 10 if not 20
yrs.

thanks for the conversation so far!
-chris