Proposal to raise the maximum allocation to a single LIR
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
Hi We have lots of registries, as we've needed different CIDR blocks to put in different ASNs (most others seem to just break PA space if they want to do this) We own AS5378 - original INS backbone AS6660 - INS USA network AS6765 - Wisper network (recently aquired) AS6889 - Wisper USA network (recently aquired) What we have as a result is 3 RIPE registries, and 1 ARIN one. AS6889 doesnt originate anything, but uses space announced in AS6765 - which of course causes problems for them - we will either get another ARIN registry or migrate 6889 out totally. The 3rd RIPE one is for a subsidiary, that we know will one day talk BGP and thus needed to keep address space seperate from AS5378 - the growth rate of that business is substantially different to AS5378's address growth requirements So, summary, theres a case where multipe CIDR blocks are needed where one registry has multiple ASNs for routing policy reasons - aswell as the cases that Guy has described. So much of a case that we're willing to pay for 3 medium registries and 1 ARIN one ... Regards Richard
Hi
We have lots of registries, as we've needed different CIDR blocks to put in different ASNs (most others seem to just break PA space if they want to do this)
We own AS5378 - original INS backbone AS6660 - INS USA network AS6765 - Wisper network (recently aquired) AS6889 - Wisper USA network (recently aquired)
What we have as a result is 3 RIPE registries, and 1 ARIN one. AS6889 doesnt originate anything, but uses space announced in AS6765 - which of course causes problems for them - we will either get another ARIN registry or migrate 6889 out totally.
Hi Richard! We run into the same scenario: We own AS5409 - primary AS IPF.NET AS8543 - IPF.NET Spain AS8578 - IPF.NET UK Currently we use AS5409 for our borders. But the question arises, who will be responsible if we got customers in other countries (e.g. USA). Shall we assign then RIPE allocated address space (as we currently do for Spain and UK) or request ARIN Space with a different AS for USA ? Also, as we run under de.ipf, which is not sufficient, as our company grows, shall we switch to eu.ipf or use for each country a different lir ? The Ripe Documents didn't cover this scenario AFAIK... Greetings Jan Senior Network Engineer IPF.NET
On Tue, 2 Feb 1999 12:54:49 +0100 Jan Czmok <czmok@ipf.net> wrote:
Hi Richard!
We run into the same scenario:
We own AS5409 - primary AS IPF.NET AS8543 - IPF.NET Spain AS8578 - IPF.NET UK
You only need a different AS if your managment of that part of the network is under different control policies. You can announce what ever you like to anyone without having to get different AS numbers.
Currently we use AS5409 for our borders. But the question arises, who wil= l be responsible if we got customers in other countries (e.g. USA). Shall we assign then RIPE= allocated address space (as we currently do for Spain and UK) or request ARIN Space with a differ= ent AS for USA ? =20 Also, as we run under de.ipf, which is not sufficient, as our company gro= ws, shall we switch to eu.ipf or use for each country a different lir ?
The Ripe Documents didn't cover this scenario AFAIK...
I think a different block for each country makes sense, you don't _have_ to put this into a different AS. [fx: the next big shortage, as numbers!] -- 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>
Richard Almeida wrote:
We have lots of registries, as we've needed different CIDR blocks to put in different ASNs (most others seem to just break PA space if they want to do this)
We own AS5378 - original INS backbone AS6660 - INS USA network AS6765 - Wisper network (recently aquired) AS6889 - Wisper USA network (recently aquired)
What we have as a result is 3 RIPE registries, and 1 ARIN one. AS6889 doesnt originate anything, but uses space announced in AS6765 - which of course causes problems for them - we will either get another ARIN registry or migrate 6889 out totally.
The 3rd RIPE one is for a subsidiary, that we know will one day talk BGP and thus needed to keep address space seperate from AS5378 - the growth rate of that business is substantially different to AS5378's address growth requirements
So, summary, theres a case where multipe CIDR blocks are needed where one registry has multiple ASNs for routing policy reasons - aswell as the cases that Guy has described. So much of a case that we're willing to pay for 3 medium registries and 1 ARIN one ...
Similarly, EUnet Communications Services pays the RIPE NCC for 6 large registries (as an "n=6" supernational registry) and (as n >= 5) we get a maximum allocation of 9 /16's which we distribute between EUnet's various national operations (In Austria, Belgium, Bulgaria, Switzerland, Egypt, Spain, Finland, France, Ireland, Lithuania, Luxembourg, Latvia, Malta, Norway, Poland, Portugal, Romania, Sweden, Slovenia, Slovakia, Syria and Tunisia. Other national EUnet's maintain their own small, medium or large registries) subject to normal RIPE rules. Richard, I don't understand the necessity of opening registries with both ARIN and the RIPE NCC. What advantage does this give you (unless, perhaps, you're trying to get more than your fair share of IP addresses... ;-) ? James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 - ----- 24hr emergency number: +31 20 421 0865
Richard, I don't understand the necessity of opening registries with both ARIN and the RIPE NCC. What advantage does this give you (unless, perhaps, you're trying to get more than your fair share of IP addresses... ;-) ?
It was actually a pre-arin USA address block for connecting our US customers in a different ASN (207.181.0.0/19) - we decided using a US "block" for US customers was nicer for some reason Cheers Richard
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>
participants (5)
-
Guy Davies -
James Aldridge -
Jan Czmok -
Neil J. McRae -
Richard Almeida