[ppml] Increase the flexibility of IP allocations to facilitate planning
Michael.Dillon at radianz.com
Michael.Dillon at radianz.com
Tue Jul 22 10:28:48 EDT 2003
>> Organizations are penalized for using IPv4 addresses efficiently
>> if they do so, they have no internal buffer of hidden IPv4 addresses
>> they can use in the event that an allocation request is denied or
>> The net effect is to encourage organizations to keep a secret stash of
>> 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.
More information about the ARIN-PPML