Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Draft Policy ARIN-2012-6: Revising Section 4.4 C/I
Reserved Pool Size (Christopher Morrow)
2. Re: Draft Policy ARIN-2012-6: Revising Section 4.4 C/I
Reserved Pool Size (David Farmer)
3. Re: Draft Policy ARIN-2012-6: Revising Section 4.4 C/I
Reserved Pool Size (Christopher Morrow)
4. Re: Draft Policy ARIN-2012-6: Revising Section 4.4 C/I
Reserved Pool Size (David Farmer)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Oct 2012 16:18:56 -0400
From: Christopher Morrow <[email protected]>
To: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2012-6: Revising Section
4.4 C/I Reserved Pool Size
Message-ID:
<cal9jlaa7c4z-edqqeyjkgefljpcppm-tgcmfj2ss8btv7+f...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
ok, sorry for the extra noise, but these ought to be a bit more
readable: (axis labels)
CI space allocations /24 equivalents: <http://goo.gl/KEvsW>
all allocations /24 equivalents: <http://goo.gl/aZjgr>
a combined picture: <http://goo.gl/f8e7Y> (yes, autoscaling isn't my
friend today)
and another silent contributor asked about 'can I see all allocations
as a total over time?':
<http://goo.gl/3QdKM>
-chris
------------------------------
Message: 2
Date: Wed, 17 Oct 2012 21:27:46 -0500
From: David Farmer <[email protected]>
To: Christopher Morrow <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2012-6: Revising Section
4.4 C/I Reserved Pool Size
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/17/12 15:18 , Christopher Morrow wrote:
> ok, sorry for the extra noise, but these ought to be a bit more
> readable: (axis labels)
>
> CI space allocations /24 equivalents: <http://goo.gl/KEvsW>
>
> all allocations /24 equivalents: <http://goo.gl/aZjgr>
>
> a combined picture: <http://goo.gl/f8e7Y> (yes, autoscaling isn't my
> friend today)
>
> and another silent contributor asked about 'can I see all allocations
> as a total over time?':
> <http://goo.gl/3QdKM>
>
> -chris
So Chris, those are the allocations from the two /8s in question, and as
you say below they are not necessarily all CI allocations.
> o a polite caller notes I am counting all allocations in the 2 /8's
> where CI allocations are currently being made, these are not actually
> all CI allocations. (every square is a rectangle, not every rectangle
> is a square)
I did analysis on the allocations documented at;
<https://www.arin.net/knowledge/micro_allocations.html>
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
------------------------------
Message: 3
Date: Wed, 17 Oct 2012 23:07:33 -0400
From: Christopher Morrow <[email protected]>
To: David Farmer <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2012-6: Revising Section
4.4 C/I Reserved Pool Size
Message-ID:
<CAL9jLaYiKhqEnQzstY2H2K2bmQze6hCuAagR=BoO+xpNouR=n...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Oct 17, 2012 at 10:27 PM, David Farmer <[email protected]> wrote:
> On 10/17/12 15:18 , Christopher Morrow wrote:
>>
>> ok, sorry for the extra noise, but these ought to be a bit more
>> readable: (axis labels)
>>
>> CI space allocations /24 equivalents: <http://goo.gl/KEvsW>
>>
>> all allocations /24 equivalents: <http://goo.gl/aZjgr>
>>
>> a combined picture: <http://goo.gl/f8e7Y> (yes, autoscaling isn't my
>> friend today)
>>
>> and another silent contributor asked about 'can I see all allocations
>> as a total over time?':
>> <http://goo.gl/3QdKM>
>>
>> -chris
>
>
> So Chris, those are the allocations from the two /8s in question, and as you
> say below they are not necessarily all CI allocations.
yup
>
>> o a polite caller notes I am counting all allocations in the 2 /8's
>> where CI allocations are currently being made, these are not actually
>> all CI allocations. (every square is a rectangle, not every rectangle
>> is a square)
>
>
> I did analysis on the allocations documented at;
>
> <https://www.arin.net/knowledge/micro_allocations.html>
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>
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 :(
I still think the largest easy driver is gTLD growth, and that's not
going to be very predictable either. 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.
-chris
------------------------------
Message: 4
Date: Wed, 17 Oct 2012 23:46:14 -0500
From: David Farmer <[email protected]>
To: Christopher Morrow <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2012-6: Revising Section
4.4 C/I Reserved Pool Size
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/17/12 22:07 , Christopher Morrow wrote:
> On Wed, Oct 17, 2012 at 10:27 PM, David Farmer <[email protected]> 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.
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 88, Issue 14
*****************************************
