Re: [hostmaster-staff] Re: MIR proposal / reservation revisited?
To me, this rather sounds like a case for revisiting reservation, rather than arguing for a new registry type/structure/rules. Am I missing something? Wilfried. ______________________________________________________________________ Date: Fri, 28 Sep 2001 13:58:24 +0200 From: Gert Doering <gert@space.net> To: Adrian Bool <aid@vianw.net> CC: lir-wg@ripe.net Subject: Re: [hostmaster-staff] Re: MIR proposal Hi, On Fri, Sep 28, 2001 at 12:05:41PM +0100, Adrian Bool wrote:
I feel that international networks require the ability to operate according to the same rules as RIPE - just working on a smaller scale - as another level down in the hierarchy.
Not only "international networks", but also national ones that have a hierarchical structure of re-sellers.
i.e We should should be able to apply for more IP space once we have sub-allocated 80% of our allocation to our in-country networks - natuarally in a responsible manner, according to the same rules that an RIR would allocate space to these in-country networks.
Sure. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Mon, Oct 01, 2001 at 01:21:56PM +0200, Wilfried Woeber, UniVie/ACOnet wrote:
To me, this rather sounds like a case for revisiting reservation, rather than arguing for a new registry type/structure/rules.
It's similar, but "reservation" is not what I have in mind.
Am I missing something?
Yes - multi-level structures. "Reservation" is: - I give this /24 to that company, even if they only need a /27 today, because they might need it in a couple of years. "Multi-Level Structure" is: - I give this /22 (or whatever) to that reseller of mine. He is going to distribute this /22 to his customers, filling in proper RIPE-141s for each subnet, following all the RIPE policies & procedures, and documenting each assignment in the RIPE database. This is along the lines of "ALLOCATED PA" - I have the address space, but MUST NOT use it, before it has been turned (piece by piece) into "ASSIGNED PA". Stephen's proposal (MIR) means "make a level between RIR and LIR that gets space from the RIR, can do ALLOCATED PA to (its) LIRs, and has to be a separate organization". My proposal is less formally structured, but boils down to about the same thing - permit multiple levels of "ALLOCATED PA". But in the final step, the address space must be ASSIGNED PA, according to the normal rules, which means "no reservation". I see a big difference :-) but maybe it's just me...? Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, Oct 01, 2001 at 01:21:56PM +0200, Wilfried Woeber, UniVie/ACOnet wrote:
To me, this rather sounds like a case for revisiting reservation, rather than arguing for a new registry type/structure/rules.
Am I missing something?
Multi-level allocations are a utility to handle network aggregation smaller than the full LIR allocation. E.g. you chose small assignments of networks routed to a particular PoP or reseller to fall within the same /24 (or some other possible arbitrary allocation size). The /24 is therefore 'allocated' to that PoP or reseller independent of this fact being documented in the RIPE DB or not. And yes, this does 'reserve' address space, but that's a problem of the LIR in question. RIPE won't see the 'reserved' addresses and won't hand out more addresses to the LIR and the amount of addresses reserved by this procedure tends to be very small if the allocation size is chosen reasonably. Documentation in the RIPE DB makes the procedure more transparent and also helps in organizing responsibilities, as the actual data gathering and communication is most often done by the reseller and not directly by the LIR. But this is not strictly necessary as you can document 'sub allocations' and responsibilities outside of the RIPE-DB. In fact, we stored such 'sub allocations' in the RIPE-DB for some years for exactly that purpose until RIPE NCC requested to remove these records because it conflicted with their 'overlapping assignment validation'-tool. RIPE NCC never understood the reasoning behind the multi-level allocations and I still remember the fruitless discussions with RIPE hostmasters from that time. I do not see the need to introduce new registry types or structures unless you believe that 'selling the right to assign IP addresses to entities down the hierarchy' is a valid reason. Just my EUR0.02. Michael van Elst
Wilfried. ______________________________________________________________________
Date: Fri, 28 Sep 2001 13:58:24 +0200 From: Gert Doering <gert@space.net> To: Adrian Bool <aid@vianw.net> CC: lir-wg@ripe.net Subject: Re: [hostmaster-staff] Re: MIR proposal
Hi,
On Fri, Sep 28, 2001 at 12:05:41PM +0100, Adrian Bool wrote:
I feel that international networks require the ability to operate according to the same rules as RIPE - just working on a smaller scale - as another level down in the hierarchy.
Not only "international networks", but also national ones that have a hierarchical structure of re-sellers.
i.e We should should be able to apply for more IP space once we have sub-allocated 80% of our allocation to our in-country networks - natuarally in a responsible manner, according to the same rules that an RIR would allocate space to these in-country networks.
Sure.
Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-- i.A. Michael van Elst / phone: +49 721 9652 330 Xlink - Network Information Centre \/ fax: +49 721 9652 349 Emmy-Noether-Strasse 9 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ KPNQwest Germany GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Michael Mueller-Berg ]
Hi, On Mon, Oct 01, 2001 at 05:38:53PM +0200, Michael van Elst wrote:
until RIPE NCC requested to remove these records because it conflicted with their 'overlapping assignment validation'-tool. RIPE NCC never understood the reasoning behind the multi-level allocations and I still remember the fruitless discussions with RIPE hostmasters from that time.
I do not see the need to introduce new registry types or structures unless you believe that 'selling the right to assign IP addresses to entities down the hierarchy' is a valid reason.
But you just named a reason: to be able to document where a certain network block "went to", and to document the allocation/assignment hierarchy in a transparent way without upsetting the NCC's tools. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert Doering wrote:
But you just named a reason: to be able to document where a certain network block "went to", and to document the allocation/assignment hierarchy in a transparent way without upsetting the NCC's tools.
This is the "status: LIR-PARTITIONED" (formerly my "LIR-ALLOCATED") proposal. This doesn't add any new registry types or change policy in any way but does provide (among other things) the documentation function. Regards, James P.S. Unfortunately, I won't be able to attend the RIPE meeting in Prague this week. Please accept my apologies. --James
Hi, to revive an old thread: On Mon, Oct 01, 2001 at 09:45:06PM +0200, James Aldridge wrote:
Gert Doering wrote:
But you just named a reason: to be able to document where a certain network block "went to", and to document the allocation/assignment hierarchy in a transparent way without upsetting the NCC's tools.
This is the "status: LIR-PARTITIONED" (formerly my "LIR-ALLOCATED") proposal. This doesn't add any new registry types or change policy in any way but does provide (among other things) the documentation function.
From what I understood reading Nuranis document and also discussing this at the LIR-WG session, there seems to be desire to move this further:
* documentation, as in your proposal * and also do "hierarchical allocation", which will affect the 80% usage rule (imagine a LIR with many sub-allocations that tries to achieve internal aggregation - this will nearly automatically clash with the conservation goal). So there is a policy aspect involved, which the LIR-PARTITIONED proposal doesn't cover, but which seems to be desired. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
I do not see the need to introduce new registry types or structures unless you believe that 'selling the right to assign IP addresses to entities down the hierarchy' is a valid reason.
I appreciate your concerns and arguments but i do not think you fully understand our particular problem, what you described in your reply applies to networks within one LIR sub-allocating to resellers or pops. What i descrided was a multi-national massive internal aggregation problem. A network with 200 000 internal routes and 17 LIR's each with their own fragmentation happening within their confederacies. It is 1 AS with multiple exchanges which means we pass on much more routes than we really need to. In short if we do not find a way of reducing the growth of internal routes we will hit the memory wall some time next year. It was never percieved that the Internet would every get this big with such large routing tables for just one AS so the concept of an MIR was never proposed. The NIR does not address the MIR issues, it is not there for routing reasons but purley to fulfill a countries political needs. One other that was proposed and tried was confederacies (not to confuse it with BGP term although the principles are similar) but confeds failed because they addressed the routing issues but gave an unfair advantage to to the ISP's running the confed. Although i can not attend the RIPE meeting i will try and detail the MIR proposal so it can be discussed and dismissed in my absence. Though the proposal is probably alien to most on the list the problem is very real. Adding the partitioning funtionality to the DB is a start to development of the concept (Please call it something else). I will follow this email some time today with a more detailed proposal for the MIR. PS To answer Wilfreds question, it is not reservation revisited it is aggregation revisited ;) Regards Stephen Burley UUNET EMEA Hostmaster SB855-RIPE
Just my EUR0.02.
Michael van Elst
Wilfried. ______________________________________________________________________
Date: Fri, 28 Sep 2001 13:58:24 +0200 From: Gert Doering <gert@space.net> To: Adrian Bool <aid@vianw.net> CC: lir-wg@ripe.net Subject: Re: [hostmaster-staff] Re: MIR proposal
Hi,
On Fri, Sep 28, 2001 at 12:05:41PM +0100, Adrian Bool wrote:
I feel that international networks require the ability to operate
according
to the same rules as RIPE - just working on a smaller scale - as another level down in the hierarchy.
Not only "international networks", but also national ones that have a hierarchical structure of re-sellers.
i.e We should should be able to apply for more IP space once we have sub-allocated 80% of our allocation to our in-country networks - natuarally in a responsible manner, according to the same rules that an RIR would allocate space to these in-country networks.
Sure.
Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 -- i.A. Michael van Elst / phone: +49 721 9652 330 Xlink - Network Information Centre \/ fax: +49 721 9652 349 Emmy-Noether-Strasse 9 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ KPNQwest Germany GmbH, Sitz ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Michael Mueller-Berg ]
On Tue, Oct 02, 2001 at 10:25:05AM +0100, Stephen Burley wrote:
[...]What i descrided was a multi-national massive internal aggregation problem. A network with 200 000 internal routes and 17 LIR's each with their own fragmentation happening within their confederacies. It is 1 AS with multiple exchanges which means we pass on much more routes than we really need to.
I understand this problem. I just fail to see how this relates to RIPE, multi-level allocations and a deeper registry hierarchy. If you mix assignments from 17 LIRs in a single AS then the LIRs have to cooperate so that you can aggregate routes as necessary. How would another level or registry help ? -- i.A. Michael van Elst / phone: +49 721 9652 330 Xlink - Network Information Centre \/ fax: +49 721 9652 349 Emmy-Noether-Strasse 9 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ KPNQwest Germany GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Michael Mueller-Berg ]
On Tue, 2 Oct 2001, Michael van Elst wrote:
I understand this problem. I just fail to see how this relates to RIPE, multi-level allocations and a deeper registry hierarchy.
If you mix assignments from 17 LIRs in a single AS then the LIRs have to cooperate so that you can aggregate routes as necessary. How would another level or registry help ?
Very simple. If you need 16 x /20 in order to cover your business needs in multiple countries or multiple regions/cities within a country - you have two choices: * To open one LIR and get the initial /20. * Divide the /20 into 16 x /24's and assign them to the cities. * When you spend that, ask RIPE NCC for more. Everything seems logical? NO! Let me explain why: even if such a thing would always be possible (it's not!), you will end up with small chunks of address space scattered along various locations in the network. On the other hand, if you have to configure your POP devices in certain cities/countries (say, you want to build a large cable or xDSL access network in 16 cities) - you'll need to spend the whole /20 range immediately, due to the nature of the service! On the other hand, if you can get a contiguous /16 immediately, divide (partition) it to 16 x /20, register that in the RIPE DB and authorize your national/city representatives to assign address space to the end customers you can achieve better aggregation, less number of routes to be announced, both internally (IGP) and externally (BGP). When you spend an allocation for one location, you just ask for a new allocation to be used on that particular location. The only alternative to this approach is opening separate LIRs for separate countries and cities, getting separate allocations for each other, which is an administrative nightmare, while the allocations won't be able to get aggregated! Regards, Beri --------- Berislav Todorovic, Senior NOC Specialist -------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------ ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri@kpnqwest.net <=> beri@EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----
On Wed, Oct 03, 2001 at 10:45:19AM +0200, Berislav Todorovic wrote: Hi Beri,
Very simple. If you need 16 x /20 in order to cover your business needs in multiple countries or multiple regions/cities within a country - you have two choices:
* To open one LIR and get the initial /20.
On the other hand, if you can get a contiguous /16 immediately
So that's what it boils down to. Getting a /16 immediately vs getting a /20 immediately. Is that really the problem for the big old ISPs where I hear the complaints from ? I believe that all the legacy PI assignments are much more of a problem for aggregation. If you think about new growing ISPs then its more a question of allocation policy on the side of RIPE NCC than of introducing a new hierarchy of registries. Spreading allocations to allow for future aggregation helps for all allocations, not just the "multi-regional" ones.
The only alternative to this approach is opening separate LIRs for separate countries and cities, getting separate allocations for each other, which is an administrative nightmare, while the allocations won't be able to get aggregated!
I doubt that multiple LIRs handling the multiple regions is an administrative nightmare. It's a problem when the LIRs compete somehow, but why should they within a single organization ? -- i.A. Michael van Elst / phone: +49 721 9652 330 Xlink - Network Information Centre \/ fax: +49 721 9652 349 Emmy-Noether-Strasse 9 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ KPNQwest Germany GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Michael Mueller-Berg ]
participants (6)
-
Berislav Todorovic -
Gert Doering -
James Aldridge -
Michael van Elst -
Stephen Burley -
Wilfried Woeber, UniVie/ACOnet