allocation sizes

Hello all,

A few weeks ago a mail was send to the lirl-wg mailing list to start a 
discussion about increasing the maximum assignment size to something 
larger than a /16. I have included the original message from Guy Davies 
below.

There didn't seem to be much consensus on the issue and some further 
issues were raised that the RIPE NCC needs to consider. The main reason 
for the proposal was that some larger registries feel that the /16 
allocation size is too small and that for internal routing reasons they 
would sometimes need more than one allocation. The issue was raised 
that Registries also sometimes need additional allocations for external 
routing reasons and in the past they've always needed to open separate 
registries for this. The RIPE NCC needs to think about this issue some 
more, but in general we feel that opening a new registry for external 
routing reasons is usually a good idea because often the other network 
has different needs and is maintained by a different group of people, 
so it's best so keep them separate. When a registry needs additional 
address space for internal routing reasons however, we feel that the 
best solution for now is to consider each case individually and try to 
come to an agreement that gives the Registry extra flexibility with 
their internal routes, but still considers the goal of conservation. 
We'll be talking to the other Regional Registries about comming up with 
a better policy in the future. We'll keep you informed on this.

Kind regards,

Paula Caslav
RIPE NCC



------- Forwarded Message

To: lir-wg at ripe.net 
Subject: Proposal to raise the maximum allocation to a single LIR 
From: Guy Davies <guyd at uk.uu.net> 
Date: Tue, 2 Feb 1999 10:06:48 +0000 (BST) 
Sender: owner-lir-wg at ripe.net 



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 at uk.uu.net t: +44 (0)1223 250457   f: +44 (0)1223 250412

 ------- End of Forwarded Message