[ppml] Proposed policy - Use of HD-Ratio for IPv4 Allocations

[Charles Scott]

PPML:
  I would prefer to see this proposal apply exclusively to end-user
assignments. Having read the rationale for HD ratio, I am unable to see
how HD applies to an address block that is consumed by assignment of
blocks to end-users. 
  The rationale for HD is based on the complexities and practicalities of
deploying resources in a numerically hierarchical manner, although I
believe that those issues are at least somewhat mitigated by the ability
to route subnets that are not numerically subordinate to the network in
which they exist. Those complexities and practicalities, however, have not
been shown to relate to the allocation of address space in blocks to end
users.
  If an ISP both consumes and assigns address space, it would seem that
those two functions should be separated to enable the ISP to opt into HD
for the address space it assigns to itself for it's own consumption, while
still using the existing policy to dictate the manner in which they
receive block assignments from ARIN. I believe that some, if not most,
ISP's effectively do this now.
  I believe that by limiting the following policy to end-user policy only
it could offer (possibly) needed relief for the implementation of large
networks by end-users without risking significant affects on the overall 
address pool.

Chuck Scott


> 
> Policy Proposal Name: Use of HD-Ratio for IPv4 Allocations
> 
> Author: Michael Dillon
> 
> Author's Organization: Radianz, Inc.
> 
> Policy term: permanent
> 
> Policy statement: 
> 
> 1. Anyone who has already been allocated 4096 IPv4 addresses or
>    more may choose to have additional requests for IPv4 addresses
>    evaluated using an HD (Host Density) Ratio calculation to determine 
>    sufficient utilization instead of a fixed percentage threshold.
> 
> 2. All requests for additional IPv4 address space subject to the HD 
>    Ratio shall require the efficient utilization of the sum total of 
>    all existing allocations. The HD Ratio on the sum total of all 
>    existing allocations must be greater than or equal to .966.
> 
> 3. In addition, the HD ratio of the most recent allocation must be 
>    greater than or equal to .930.
> 
> 4. The HD ratio is calculated as log(utilized IPv4 addresses) divided
>    by log(total addresses in all previous allocations). In this formula, 
>    log refers to the natural logarithm.
> 
> Rationale: 
> 
> The HD ratio was proposed as a way to determine allocation usage 
> thresholds for IPv6 address allocations. For more details on this,
> please refer to RFC 3194 <http://www.faqs.org/rfcs/rfc3194.html>. There
> is some detailed background discussion about applying the HD ratio to
> IPv4 allocations in a proposal by Paul Wilson posted to the APNIC mailing
> list on Aug 7, 2003 
> http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html
> and he presented the it to the annual APNIC policy meeting using these 
> slides
> http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-pres-wilson-hd-ratio.pdf
> I am not suggesting that ARIN should adopt the APNIC proposal and
> although Paul invents a new name for the HD ratio, I prefer to keep the
> original term.
> 
> The basic thrust of this proposal is to replace the rigid 80% usage 
> criterion by the more flexible HD ratio and to shift the emphasis away
> from the last allocated block to include the total allocated address
> space. To that end, the .930 criterion for the last block is a lot
> looser than the existing requirements for the last block. This is
> because the utilization threshold establishes a time buffer between
> the beginning of an ARIN application for additional addresses and the
> final deployment of new addresses in the operational network. By using
> a looser criterion as network size grows, we are also expanding this
> time buffer. This recognizes that the economy is more dependent than
> ever on the smooth running of our networks and we should not artificially
> force larger members to operate with virtually no safety buffers for
> implementing new addresses. This safety buffer size is important because
> larger networks have more involved processes for changes to their network
> and these processes take time.
> 
> Paul Wilson's paper contains ample discussions of the technical 
> justification for using the HD ratio. I have proposed that we use
> the .966 number that he suggests, I believe there may be valid arguments
> for reducing this slightly, perhaps to .960.
> 
> It would be good for ARIN to have more detailed discussion of the HD
> ratio on file however I don't believe that needs to be in the policy
> itself. However, I would suggest that the ARIN website should contain a
> copy of RFC 3194, a copy of Paul Wilson's paper, and a summary of any
> ARIN member discussions regarding application of the HD ratio to IPv4
> addresses. I will also be preparing some slides with graphs and tables
> that can be displayed on the ARIN website prior to the policy meeting.
> 
> Please note the following points.
> 
> a) This policy only applies to organizations that already have IP space
>    equivalent to a /20 block or larger.
> 
> b) The policy does not specify the source of the 4096 or more addresses
>    therefore it could apply to an ISP who comes to ARIN for the very
>    first time and exchanges an upstream allocation for their own 
>    PI space.
> 
> c) The policy does not use the term "ISP" therefore it can also
>    apply to any other organization with a large network which
>    is growing larger and therefore needs another allocation.
> 
> d) The policy only applies to organizations who opt-in. This means
>    that if your IP address management tools can't handle the HD ratio
>    you can ignore it. If you find the HD ratio confusing or complex
>    then you can ignore it. If you are crafty and fund a study which
>    finds that your organization would benefit in some way from the
>    old rules about an 80% threshhold then you can ignore this new 
>    policy. The new policy provides a benefit to those organizations
>    which need it without penalizing those which do not.
> 
> e) This policy proposal cannot be understood in isolation. You do need
>    to read the RFC and Paul Wilson's discussion paper.
> 
> f) The .966 calculation in point 2 covers the entire aggregate of
>    address space including the block covered by the .930 calculation
>    in point 3. You have to meet both targets to pass this policy's test.
> 
> Timetable for implementation: 30 days after ratification
>