Proposal to raise the maximum allocation to a single LIR

On Tue, 2 Feb 1999 10:06:48 +0000 (BST) 
 Guy Davies <guyd at 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 at 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>