On Tue, 2 Feb 1999 10:06:48 +0000 (BST) Guy Davies <guyd@uk.uu.net> wrote:
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.
This is an interesting problem that I've ran into also.
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.
Unfortunately, large organisations have in the past used amount of network address space as a criteria for network interconnection, even though one IP address can generate more traffic than some /16 [even /8s] in the routeing table currently.
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 ;-)
This is something like what we have done at COLT. We have a registry for our backbone and we have registries for our local operating companies, we aren't as big as UUNET but this works for us, and I imagine you might even be talking about more LIR's for say, AS1849 as the backbone rather than AS702 as the backbone which I assume already have seperate LIRs. Under the current policies, I can't see any other way of achieving this other than setting up new LIRs. I can see the day where a registry for network areas might make sense, and to take your point about more admin load [cost is acceptable compared to margins and revenues when you are at this stage, and they can be justified in any business plan or budget], this really is only at the start of the process, its a few emails and documents to arrange to be signed and some internal documentation and training. In some ways creating a new LIR demostrates one part or another of all the suggestions you made. Some are good some are bad. Regards, Neil. -- Neil J. McRae - Alive and Kicking. C O L T I N T E R N E T neil@COLT.NET NetBSD-1.3.3 released! ftp://ftp.uk.netbsd.org/pub/NetBSD Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>