[ppml] Increase the flexibility of IP allocations to facilitate planning

[Michael.Dillon at radianz.com]

>> Organizations are penalized for using IPv4 addresses efficiently 
because 
>> if they do so, they have no internal buffer of hidden IPv4 addresses 
that 
>> they can use in the event that an allocation request is denied or 
delayed. 
>> The net effect is to encourage organizations to keep a secret stash of 
IP 
>> addresses that they could use if necessary.

>This paragraph makes no sense.  If you are efficiently utilizing your 
space there would be no reason to be denied >or delayed in getting 
additional space.  Where as, if you were keeping a secret stash of IP 
space, that would be >the perfect example to get delayed or denied. 

Here's what I mean. If your goal was to maximize the efficiency of address 
assignment, then you would eventually reach an upper limit for every 
netblock beyond which you can't improve efficiency. I'm assuming that is 
greater than 80% utilization. That means that when you reach 80% on your 
last netblock, you have already used up all possible addresses on previous 
netblocks so that you only have the last 20% of the most recent netblock 
to allocate. In fact, you probably have less than 20% because it is not 
possible to assign IPv4 addresses to 100% efficiency. Assuming that the 
allocation is based on 3 months of usage, i.e. 13 weeks, this means that 
you have no more than 2.6 weeks supply of addresses left when you submit 
your ARIN application. The .6 weeks will be used up by ARIN's 2-3 business 
days of turnaround time so you will only have 2 weeks to get these new 
addresses into your systems. The people who do this work also do other 
planned and break-fix operational work so they can't be expected to just 
drop everything and handle these new IP addresses every time.

The solution to this problem is to keep a secret stash of IP addresses 
that ARIN doesn't know about so that you never have a crisis with address 
exhaustion due to the ARIN application process. There are lots of ways to 
do this, i.e. never assign more than 80% of a netblock or never reuse old 
addresses freed up by customer churn until after you have used 80% of your 
last ARIN netblock. The fact is that the existing ARIN policy encourages 
this sort of behaviour. Businesses need reasonable buffers and if the 
policy won't explicitly accomodate buffers then people find other ways to 
create the buffers they need.

Of course, if you run a vanilla IP network, then the 2 weeks is probably 
enough time to handle an ARIN application even if it means you need to do 
a bit of re-allocation of addresses from one PoP to another and later 
renumbering things to free up older addresses for your buffer. But not 
everyone runs a vanilla IP network anymore. Also, network operators are 
becoming larger which means increased internal process which means 
increased time to get things done. A 2 week buffer is simply not a 
reasonable business practice.

>I would also disagree that the 80% usage requirement is to stringent.  I 
think if you use your space wisely and >submit your request as you reach 
80% you should have no problem getting your request approved and your new 
block >allocated before running out. 

This is only true if your usage grows steadily without fits and starts and 
if your internal processes allow you to quickly deploy new addresses. 
While the ARIN membership may believe that it is reasonable to require an 
80% utilization rate, I do not believe that it is reasonable to require 
this as a precondition for receiving new IP addresses because of the 
timing issues. Remember, we are talking about organizations that have a 
long term relationship with ARIN; it is not necessary to police each and 
every one of their interactions with the organization. What is wrong with 
requiring that you must show that your usage trend WILL hit 80% in the 
near future and that you did indeed exceed 80% utilization in your 
penultimate netblock? We still have the same utilization but we now have a 
much smoother allocation procedure that accomodates internal business 
processes of the members.

--Michael Dillon