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

Hi Karsten,

The responses I have seen to the list in favour of the HD ratio to the 
address-policy mailinglist arefrom

    * alain.bidron at francetelecom.com
    * kelaidi at ote.gr
    * EricS at t-com.net
    * groeskens at bluewin.ch
    * debecker at etno.be (on behalf or ETNO in September 2004)


 From re-reading the entire discussion I see that there has been some 
discussion on elements that could be interpreted as beeing oppsoed to 
the proposal as you state - could I ask for clearification from all 
involved during last call on this so I do not have to interpret language 
amd make wrong judgement of statements to the list ?

As to the procedural point you are quite right that in order to stop 
this proposal - you need to state - as you did - that you do not support 
this policy an preferably why.

Best Regards,

Hans Petter Holen
Address Policy WG Chair



>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
>>>>
>>>> 
>>>>
>>>>        
>>>>
>>    
>>