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

Dear Karsten, 
When you manage an X-large registry you have several levels of management.
In such a situation, meeting the 80% criteria is much more difficult (if possible) than with a small registry with only one level.
The proposal is clearly not to advantage or to disadvantage some registries but simply to take into account in fair way different situations in order to have enough flexibility for a better management.

Regarding the support from the community, I have to mention that this proposal was considered by ETNO, whose members representing are  a large part of X large registries in the RIPE region, and unanimously supported.

You can find this expression for support at 
www.etno.be  Document EC064.

Leo Debecker posted this contribution from ETNO to the mailing list.
Be aware that this support comes from the following ETNO members.
This is not one voice but 41.
·	Auna Telecomunicaciones 
·	Belgacom 
·	BH Telecom (Bosnia and Herzegovina) 
·	BT (British Telecom) 
·	BTC (Bulgarian Telecommunications Company) 
·	Cesky Telecom 
·	Community of Yugoslav PTT 
·	Croatian Telecom 
·	Cyprus Telecommunications Authority 
·	Deutsche Telekom 
·	Eircom 
·	Elion Enterprises Ltd 
·	Elisa Communications Corporation 
·	Entreprise des Postes et Télécommunications Luxembourg 
·	Finnet Group 
·	France Telecom 
·	Invitel 
·	Koninklijke KPN 
·	Lattelekom 
·	Makedonski telekomunikacii 
·	Maltacom 
·	Matáv Hungarian Telecommunications Company 
·	Netia S.A. 
·	OTE 
·	Portugal Telecom 
·	Rom Telecom 
·	Síminn (Iceland Telecom Ltd.) 
·	Slovak Telecom 
·	Societatea Nationala de Radiocomunicatii (SNR) 
·	Swisscom 
·	TDC 
·	Tele 2 
·	Telecom Italia 
·	Telefonica 
·	Telekom Austria 
·	Telekom Slovenije 
·	Telekomunikacja Polska 
·	Telenor 
·	TeliaSonera 
·	Türk Telekomünikasyon 
·	VIPnet 
Regards

-----Message d'origine-----
De : address-policy-wg-admin at ripe.net
[mailto:address-policy-wg-admin at ripe.net]De la part de Koepp, Karsten
Envoyé : jeudi 7 juillet 2005 12:34
À : 'Hans Petter Holen'
Cc : address-policy-wg at ripe.net
Objet : RE: [address-policy-wg] last Call: Policy proposal #beta HD
ratio policy proposal


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