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

[Alexander, Daniel]

On 10/18/12 10:56 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
wrote:

>On Thu, Oct 18, 2012 at 9:14 PM, Alexander, Daniel
><Daniel_Alexander at cable.comcast.com> wrote:
>> Please correct my history if I'm off.
>>
>> When CI was originally discussed more than a decade ago, there were two
>> main issues. One was a special circumstance was needed to allocate /24's
>> since the minimum allocations were much higher at the time. The second
>> issue was that a special range was to be identified so the small blocks
>> wouldn't get filtered. Ten years ago the minimum routable aggregate on
>>the
>> Internet was around a /20.
>>
>
>I think it's also a case that in some (over half it seems) cases the
>tld operator has essentially .3% utilization of the /24 in question...
>so ideally we (ARIN) would never assign them another /24. Rather,
>they'd have to pack more things into the /24 before justifying
>another.
>
>> The later issue is long gone. /24 blocks are widely routed. The first
>> requirement still remains for the micro allocation and provides for the
>> justification needed for a block on the transfer market after the free
>> pool is depleted.
>>
>> So are we going to reserve a large block of the ARIN free pool so
>> for-profit gTLD operators have space waiting, while a non-profit org who
>> needs a community network is forced to the transfer market? Of coarse
>>this
>> is not the only case to compare, but it is one worth discussing.
>
>right, there are reasons to make the block larger (how large frankly
>is hard to say), there are also reasons (good ones) to say:
>  1) you paid 185k
>  2) you paid for consultants (round numbers 50k)
>  3) you paid for network people to help (30k round-numbers)
>  4) you paid for network links (MRC 6k... maybe)
>  5) you CAN pay on the xfer-market for the blocks you need.
>
>however... utilization-wise, they'ld never qualify for a /24 in
>specified xfer, right? though they could get a /24 from their
>provider(s)... but then they are tied to those providers (or a payment
>to keep the /24 and exit their link contract).
>
>Some folk say: "push them to the xfer market"
>Some folk fall on the: "but this is what the CI space is for..."
>
>Again, if you believe the CI space is for this, a /15 is not enough.
>
>-chris

[DA] The point I was trying to make was not about pushing anyone to the
transfer market. I am trying to understand what kind of allocation
justifies holding address blocks in reserve because their importance is
above everyone else's need?

The reasons a CI classification was created ten years ago, do not exist
today. What is being considered CI today is very different from CI ten
years ago. Whatever might be considered CI ten years from now will be
nothing like it is today. What is it (CI) that needs special consideration
above everyone else in todays Internet?

If we cannot explain why something requires special consideration, how are
we going to quantify it?

-Dan

>
>> -Dan
>>
>> On 10/18/12 8:13 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:
>>
>>>What about encouraging TLD operators to acquire /24s on the transfer
>>>market? Is there a reason we should be subsidizing them relative to
>>>other
>>>legitimate uses of IPv4 space?
>>>
>>>Not necessarily opposed to the proposal, but not sure this aspect has
>>>been discussed enough.
>>>
>>>Scott
>>>
>>>On Oct 18, 2012, at 6:37 PM, David Farmer <farmer at umn.edu> wrote:
>>>
>>>> On 10/18/12 13:25 , Christopher Morrow wrote:
>>>>> 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
>>>>
>>>> When I looked at this anecdotally, I though I saw way more of them
>>>>with
>>>>multiple servers per /24.  So thanks for making the counts, given this
>>>>then we should be thinking about a bigger block for sure.
>>>>
>>>>> 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.
>>>>
>>>> I'm ok with a goal of 10 to 20 years, but then I think we need to be
>>>>talking even a bigger block.
>>>>
>>>> I think Marty is right, that a /14 or more is necessary to deal with
>>>>what ICANN is talking about, and that coincides with the 2-5 years I
>>>>was
>>>>talking about.  If we want 10 to 20 years worth I think we need to be
>>>>talking about something more like /13 then.
>>>>
>>>> Either that, or push CI to make higher density use of the blocks.
>>>>
>>>>> thanks for the conversation so far!
>>>>> -chris
>>>>
>>>> Yes, a good conversation.
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>_______________________________________________
>>>PPML
>>>You are receiving this message because you are subscribed to
>>>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>Unsubscribe or manage your mailing list subscription at:
>>>http://lists.arin.net/mailman/listinfo/arin-ppml
>>>Please contact info at arin.net if you experience any issues.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.