[arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised

[Matthew Kaufman]

On 7/14/2014 6:44 PM, John Curran wrote:
> On Jul 14, 2014, at 9:06 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net 
> <mailto:jeffrey.lyon at blacklotus.net>> wrote:
>>
>> It applies to all but is of zero benefit to large orgs with 
>> contiguous space. This idea that it allows big orgs to horde space is 
>> a red herring.
>>
> Jeffrey -
>   For sake of argument, imagine a large ISP which over the course of 
> time has
>   ended up with a /8, two /16, and a /14 IPv4 blocks (with the /14 
> being the most
>   recently issued block because of nearly full utilization of all 
> prior blocks at the
>   time.)
>   Under present policy, the ISP cannot request address space until 
> they have
>   brought the utilization of the most recently issued block (the /14) 
> up to 80%.
>   Under the proposed policy, the ISP is immediately eligible to 
> request space,
>   since their aggregate utilization (even with a completely unused 
> /14) is going
>   to be very high (potentially as much as 97% due to the fully-used /8 
> block.)
>
>   The proposed policy allows organizations to request space so long as 
> their
>   aggregate utilization is higher than 80%, and this means many existing
>   organization with large IPv4 holdings will suddenly qualify to 
> receive an
>   additional allocation if they choose to request it.  Whether that is 
> desirable
>   or not is a matter for the community to decide.
>
>

Your theoretical argument assumes a certain kind of large ISP. Let me 
propose a couple of alternative scenarios:

Imagine a large ISP which over the course of time has ended up with a 
/8, two /16, and a /14 block with the /14 being the most recently issued 
block.

Under present policy, they cannot get more space until the /14 is 
documented at 80% utilization, which they've got the documentation all 
ready for.

Under the proposed policy, the ISP can't get any space, because their 
recordkeeping on the /8 is terrible. They got the /8 and the /16 
pre-ARIN, probably as two different entities than the one that got the 
/14, and now instead of submitting the detailed documentation they 
started keeping not long after they got that second /16 (so they could 
get the /14, and so they could get more when the /14 filled) they'd need 
to spend more time and effort than they have to dredge up utilization 
records for that /8 just to get another 3 months worth of space from 
ARIN (even though the scrap papers laying around and the routing tables 
strongly suggest that all that space really is in use, and isn't easily 
reclaimed to meet their pressing need). So they get nothing.

Or imagine a large ISP which over the course of time has ended up with a 
/8, two /16 and a /14 with the /14 being the most recently issued block.

Under present policy, they cannot get more space until the /14 is 
documented at 80% utilization, and they're all ready to do that.

Under the proposed policy, the ISP can't get any space because while 
they've got great records for how the /8 and the two /16s are utilized, 
the customer and internal assignments they did back then are deemed to 
be inefficient by ARIN staff when they review the utilization records 
for everything. All those point-to-point links using whole /24s, and 
dialup pools that are sized for what was needed back in the days of 
dialup but nowadays only have a handful of customers on them aren't ok 
any more. So instead of being able to just pounce on some space because 
of this policy change, they're actually blocked from getting more.

Overall, I think the answer is that for certain kinds of ISPs in certain 
kinds of growth patterns, the change in policy would make it easier for 
them to qualify. But for many others, it would make it harder.

I am not in favor of pulling the rug out from under people at the last 
minute, and given how close we are to runout it would be exactly that to 
change IPv4 policy on them. So I oppose this policy as written, and any 
other attempts to make last-minute changes. For people who've planned 
ahead, stability is the best we can give them. For people who haven't 
planned ahead, they're screwed whether we change the policy or not.

Matthew Kaufman


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140715/870c6043/attachment.htm>