[address-policy-wg] last Call: Policy proposal #beta HD rati o policy proposal

Thu Jul 7 12:33:33 CEST 2005

Hello Hans Petter and al,

I am AGAINST the proposal.

I would like Alain to better explain his need for better IP
address management. He is the only voice I have seen *for* 
the proposal. Nobody is supporting Alain, instead Iljitsch
has brought profound comments *against*, and there were some
cynic comments - also *against*.

>From my point of view, I would like to see the current policy
remain in place, because with IPv4 we much more have a conservation
than an aggregation goal (or an internal aggregation need)
Large LIRs already receive /10s and I cannot see the proposal
will have "some limited impact" on address consumption. If 
giant LIRs will only be mandated to occupy 52% instead of 80% of 
their v4-IPs (I have done this calculation for DTAG and FT), this
is in my view going to cut our resources significantly. 

So, does the new PDP request a counter proposal to maintain 
current policy, I guess no, just enough people have to say
no. Also, people in support of the proposal please raise your
hands.

regards Karsten
eu.lambdanet

> -----Original Message-----
> From: Hans Petter Holen [mailto:hpholen at tiscali.no]
> Sent: Friday, July 01, 2005 12:37 AM
> Cc: address-policy-wg at ripe.net
> Subject: [address-policy-wg] last Call: Policy proposal #beta HD ratio
> policy proposal
> 
> 
> Hans Petter Holen wrote:
> Following the discussion on the mailinglist prior to and 
> after posting 
> the formal proposal I have seen no proposals to modify the 
> proposal and 
> would like to move the proposal into the conclustion phase in 
> the policy 
> development process http://www.ripe.net/ripe/draft-documents/pdp.html
> 
> Last cal will end at July 15th.
> 
> Best Regards
> 
> Hans Petter Holen
> WG Chair
> 
> > Thanks Alain,
> > I'll as the new PDP is not in operation yet, I'll add this 
> to my list 
> > as #beta v1
> >
> > I propose that we enter into the Discussion phase for 4 weeks from 
> > date until April 4.
> >
> > -hph
> >
> > BIDRON Alain ROSI/DAS wrote:
> >
> >> Dear Colleagues
> >> Referring to the minutes of the last RIPE Policy Working Group 
> >> meeting and to the action list as updated during that 
> meeting, I have 
> >> to make a formal proposal on use of HD ratio for IPV4.
> >> Here is this policy proposal.
> >> In order to be consistent with the PDP Draft proposal 
> coming from Rob 
> >> Blokzijl I have used the template provided in the new PDP proposal.
> >> Best regards.
> >> Alain
> >>
> >>
> >> _________________________________________________________
> >> 1. Policy Proposal Name: IPv4-HD-Ratio
> >> 2. Author
> >> a. name: Alain Bidron
> >> b. e-mail: alain.bidron at francetelecom.com
> >> c. telephone: +33 1 44 44 27 75
> >> d. organisation: France Telecom
> >> 3. Proposal Version: V0
> >> 4. Submission Date: 02/02/2005
> >> 5. Suggested WG for discussion and publication: Address Policy WG
> >> 6. Proposal type: modify
> >> 7. Policy term: permanent
> >> 8. Summary of proposal: Internet address space is managed 
> >> hierarchically:
> >> - IANA allocates space to Regional Internet Registries (RIRs).
> >> - RIRs allocate space to Local Internet Registries (LIRs).
> >> - LIRs assign space to End Users.
> >>
> >> At each level, some address space may be reserved for future 
> >> expansion and/or efficient aggregation. As more 
> hierarchical levels 
> >> are introduced, the overall efficiency of the address space usage 
> >> decreases.
> >>
> >> The HD ratio (Host-Density ratio) is a way to measure 
> address space 
> >> usage [RFC 3194]. The HD ratio value can relate to a percentage of 
> >> usage, which decreases as the amount of address space grows. This 
> >> allows for the decreasing efficiency that occurs with more 
> >> hierarchical levels.
> >>
> >> The HD ratio is currently used to measure IPv6 address space usage 
> >> [ipv6-address-policy]. The IPv6 Address Allocation and Assignment 
> >> Policy considers a block of IPv6 address space to be 
> ‘used’ when its 
> >> HD ratio reaches 0.80. This is a manageable figure 
> ("values of 80% or 
> >> less correspond to comfortable trade-offs between pain and 
> >> efficiency" [RFC 3194]).
> >>
> >> This document proposes using the HD ratio to measure IPv4 
> usage. The 
> >> proposed value of the HD ratio for IPv4 is 0.96.
> >>
> >> 9. Policy text:
> >> a. Current: "An LIR may receive an additional allocation 
> when about 
> >> eighty percent (80%) of all the address space currently 
> allocated to 
> >> it is used in valid assignments or sub-allocations."
> >> b. New: "An LIR may receive an additional allocation when 
> its total 
> >> allocated address space usage meets the HD-Ratio value of 0.96."
> >>
> >> 10. Rationale:
> >>
> >> a.    Background
> >> The current document, “IPv4 Address Allocation and Assignment 
> >> Policies for the RIPE NCC Service Region” [ipv4-address-policy], 
> >> considers a block of IPv4 addresses to be ‘used’ when 80% of the 
> >> addresses within the block have been sub-allocated or 
> assigned. This 
> >> is applied to all address blocks, regardless of size. 
> >> Current policies assume a hierarchical system of address space 
> >> delegation. However, they do not make any  allowance for 
> hierarchical 
> >> management within allocated address space. For LIRs in 
> particular, a 
> >> hierarchical approach is often required for assignment of address 
> >> space to service elements such as customer networks, individual 
> >> Points of Presence (PoPs), regionalised topologies, and 
> even distinct 
> >> ISP products. Small network infrastructures may require simple 
> >> hierarchies, but large infrastructures can require several 
> levels of 
> >> address space subdivision. These levels of hierarchy are not 
> >> recognised by the current policy framework and are highly 
> restricted 
> >> by the "80% rule". As a result, managing large blocks is often 
> >> difficult, requiring large internal routing tables and/or frequent 
> >> renumbering of internal address blocks.
> >>
> >> One of the goals of the RIR system is to avoid unnecessary 
> depletion 
> >> of IPv4 address space. However, address management 
> policies must also 
> >> be practical in terms of how much management overhead they cause. 
> >> When large amounts of address space are involved, the "80% 
> rule" can 
> >> result in more work for an LIR.
> >>
> >> Basing usage on the HD ratio should lead to equal levels of 
> >> management overhead across the board, rather than penalising the 
> >> holders of large address blocks.
> >>
> >> b.Impact   
> >> To see a rough estimation of the immediate impact of this 
> proposal, 
> >> an HD Ratio value of 0.96 was applied to the average amount of 
> >> address space held by an LIR in the RIPE NCC Service Region. This 
> >> showed that on average, LIRs would qualify for an additional 
> >> allocation block when they have assigned or sub-allocated 
> about 59% 
> >> of their allocated address space.
> >>
> >> c.Arguments supporting the proposal.
> >> This proposal fairly takes into account addressing 
> hierarchies used 
> >> in large and extra-large registries and introduces a 
> useful level of 
> >> flexibility for those registries
> >> The local Internet registries using the 80% criteria may 
> continue to 
> >> do so and will not be impacted by the new policy.
> >> The RIPE NCC will provide support to minimise complicated 
> >> calculations or administrative burden to LIRs.
> >>
> >> d.    Arguments opposing the proposal.
> >> This proposal will have some limited impact on IPV4 
> address consumption.
> >>
> >>
> >>
> >>
> >> Appendix A.  The HD ratio
> >>
> >>     The HD ratio is calculated as follows [RFC 3194]:
> >>
> >>        HD = log(U)/log(S)
> >>
> >>     Where:
> >>
> >>        S is the size of the address block concerned, and   
>      U is 
> >> the number of addresses used.
> >>
> >> Note: The current IPv4 policy considers addresses to be 
> ‘used’ once 
> >> they are assigned or sub-allocated by the LIR.
> >> Appendix B.  Selection of HD ratio value
> >>
> >> We should decide an appropriate HD ratio value on a 
> rational basis. 
> >> To do this, we make certain assumptions about the number 
> of "hidden" 
> >> hierarchical levels involved in managing address blocks of various 
> >> sizes. If we assume there is 80% usage at each level, we 
> can easily 
> >> calculate the overall usage.
> >>
> >> The following table proposes a set of hierarchical levels which we 
> >> can reasonably expect within different amounts of address 
> space. If a 
> >> usage of 80% is achieved at each hierarchical level, then 
> the overall 
> >> usage will be (0.80 to the power of "n"). It is then possible to 
> >> calculate HD ratio values from this value.
> >>
> >>        Size range        Level     Utilisation    HD ratio
> >>        (prefix)            (n)          (0.80**n)     (calculated)
> >>            /24 to /20        1             80%             
>  .960 to .973
> >>        /20 to /16        1.5           72%              
> .961 to .970
> >>        /16 to /12        2             64%              
> .960 to .968
> >>        /12 to /8         2.5           57.2%            
> .960 to .966
> >>        /8 to /4          3             51.20%           
> .960 to .966
> >>     The levels of hierarchy listed above are based on assumptions 
> >> about the likely size and structure of LIRs holding 
> address blocks of 
> >> these sizes. A reasonable HD ratio value may be 0.96 (a 
> round figure 
> >> which occurs within most of these ranges) from the table 
> above. The 
> >> following table gives the usage requirements for IPv4 
> address blocks 
> >> from /24 to /8 for this value.
> >>
> >>        IPv4              Addresses               Addresses 
>      Util%
> >>        prefix            total                   used
> >>                   24                 256                  
> 205         
> >> 80.11%
> >>            23                 512                  399     
>     77.92%
> >>            22                1024                  776     
>     75.79%
> >>            21                2048                 1510     
>     73.71%
> >>            20                4096                 2937     
>     71.70%
> >>            19                8192                 5713     
>     69.74%
> >>            18               16384                11113     
>     67.83%
> >>            17               32768                21619     
>     65.98%
> >>            16               65536                42055     
>     64.17%
> >>            15              131072                81811     
>     62.42%
> >>            14              262144               159147     
>     60.71%
> >>            13              524288               309590     
>     59.05%
> >>            12             1048576               602249     
>     57.43%
> >>            11             2097152              1171560     
>     55.86%
> >>            10             4194304              2279048     
>     54.34%
> >>             9             8388608              4433455     
>     52.85%
> >>             8            16777216              8624444     
>     51.41%
> >>
> >> Note: This table provides values for CIDR blocks, but the same 
> >> calculations can be made for non-CIDR blocks.
> >>
> >> As an example, an LIR holding a total amount of address 
> space equal 
> >> to a /16 would be able to receive more address space when they had 
> >> sub-allocated or assigned 64.17% of that space; while an 
> LIR holding 
> >> a /9 would be able to receive more space when they had 
> sub-allocated 
> >> or assigned 52.85% of their address space.
> >>
> >> Appendix C.  References
> >> [RFC 3194] "The Host-Density ratio for address assignment 
> efficiency: An
> >>     update on the H ratio", A. Durand, C.Huitema, November 2001.
> >> [ipv6-address-policy] RIPE NCC document: "IPv6 Address 
> Allocation and 
> >>     Assignment Policy" 
> http://www.ripe.net/ripe/docs/ipv6policy.html
> >> [ipv4-address-policy] RIPE NCC document: "IPv4 Address 
> Allocation and 
> >>     Assignment Policies for the RIPE NCC Service Region"     
> >> http://www.ripe.net/ripe/docs/ipv4-policies.html
> >>
> >>  
> >>
> 
> 