Hi All, Following on from my comments at the LIR wg, I'd like to describe the issues we have and some possible solutions for these problems for the longer term. Our primary problem is that we wish to have administrative boundaries within our network separating the Backbone, LL Customers and Dial pools. It is usual to aggregate routing announcements at these administrative boundaries which is essential for the network's scalability and stability. Unfortunately, the current policy decided by the LIR working group states that the maximum amount of total free address space held by any single LIR is a /16. This can be really problematic due to the differing rates at which addresses for customers, backbone addressing and dial space are used up. It is possible to have a serious shortage of addresses for one aspect of your network while there is quite a lot of space remaining for the other areas. The restriction of a /16 means that it may not be possible to acquire more addresses for the area which has the need. It has also been generally noted that the RIPE NCC have not taken internal aggregation of routes into account when making allocations. While it may have been OK to ignore this aspect of network address allocation in the past, this is no longer the case and the decision must now be based also on realistic internal aggregation model. Below are some possible solutions to this problem. 1) Increase the maximum free space available for all LIRs to a shorter prefix. This has the disadvantage that it is contrary to RIPE's aim of conservation of address space. It sets a general precedent that any large or rapidly growing LIR can cite when requesting larger allocations. However, the advantage is that it doesn't make any specific differentiation between those LIRs who make use of the larger allocations and is, therefore, easier for the RIPE NCC to administer. 2) Devise some scheme to differentiate the maximum simultaneous available addresses for large registries from that for the small and medium registries. This has the disadvantage that it adds to the administrative load on the RIPE NCC. It is more difficult to manage exceptions. However, it means that the scope of the availability of more addresses is limited which more closely matches RIPE's aims of conservation of address space. 3) Make a specific exception for those organisations who can show evidence of a need for more than a /16 of address space simultaneously available. This adds even more administrative load on the RIPE NCC because it is based on single exceptions each of which could have a different agreement with the RIPE NCC. However, it matches more closely still the aims of conservation. 4) Setup a registry for each function which needs to be separately administered. This adds more administrative load (and cost) to the LIR and to RIPE NCC because there are more independent registries. The primary benefit is that this solution doesn't require any new policies to be made (unless it's contrary to policy for a single entity to have multiple registries for administrative convenience ;-) I'd like this to be the catalyst for some discussion of this subject on the lir-wg list. If anyone has similar concerns or issues, I'd be particularly keen to hear that. Regards, Guy --- Guy Davies UUNET, an MCI WorldCom company European Network Specialist 332 Science Park, Cambridge, CB4 4BZ, UK e: Guy.Davies@uk.uu.net t: +44 (0)1223 250457 f: +44 (0)1223 250412