From jhma at KPNQwest.net Mon Oct 1 11:06:16 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Mon, 01 Oct 2001 11:06:16 +0200 Subject: LIR-PARTITIONED proposal (originally LIR-ALLOCATED) In-Reply-To: Your message of "Fri, 28 Sep 2001 19:48:41 +0200." Message-ID: Nurani Nimpuno wrote: > Proposed Name > ------------- > RIPE NCC proposes to use the term: "LIR-PARTITIONED" ("LIR-PARTITIONED PA" > and "LIR-PARTITIONED PI") rather than "LIR-ALLOCATED", to clarify the use > of this added database feature. As "LIR-ALLOCATED" could be misinterpreted > as a policy feature, we believe that "LIR-PARTITIONED" is a more suitable > term, not involving policy terminology, but merely describing a partition > of the LIR's allocation. I don't mind too much what it's called as long as the functionality is there. > Functionality > ------------- > When creating or modifying the inetnum object the database will check the > value of the "status:" attribute according to the following rules: > > - The value of "ALLOCATED PA" or "ALLOCATED PI" is allowed if the object > is maintained by the RIPE-NCC-HM-MNT mntner (this name is specified in > ALLOCMNT variable of the configuration file) > > - The value of "LIR-PARTIONED PA" is allowed if one level less specific ^^^^^^^^^ "PARTIONED"? > inetnum object contains a "status:" attribute with the value of > "ALLOCATED PA". > > - The value of "LIR-PARTITIONED PI" is allowed if one level less specific > inetnum object contains a "status:" attribute with the value of > "ALLOCATED PI". If I read this correctly, this means that only one level of partitioning is allowed - i.e. an inetnum block with "status: LIR-PARTITIONED" cannot have more specific blocks with the same status as then the "one level less specific inetnum object" wouln't have "status: ALLOCATED". I'm not sure that this would be a problem (although it would rule out some of the more general uses of this new value which have been mentioned by others on this list) and in any case if the more specific inetnum objects were created before the less specific then the checks would pass anyway. If the reason for these checks is to ensure consistency with the PI/PA value of the corresponding "ALLOCATED" object then maybe it is this top level object which should be checked against rather than the "one level less specific inetnum object". > If the general feeling in the community is that the "LIR-PARTITIONED" > proposal does not cover the LIRs' need, but a more significant change to > current IP allocation policy is necessary, then I propose that this be > discussed in detail in the LIR-WG. Whatever policy changes take place (and I believe that a review may be in order), I think that this proposal from the NCC is a good step forward in providing added functionality to the RIPE database and I would like to thank Nurani and the NCC staff for the work they have put into it. Regards, James -- James Aldridge, Senior Network Engineer (IP Architecture) KPNQwest, Singel 540, 1017 AZ Amsterdam, NL Tel: +31 70 379 37 03; GSM: +31 65 370 87 07 From woeber at cc.univie.ac.at Mon Oct 1 13:21:56 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 01 Oct 2001 13:21:56 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? Message-ID: <00A02E04.81F3A922.5@cc.univie.ac.at> 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 To: Adrian Bool CC: lir-wg at 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From woeber at cc.univie.ac.at Mon Oct 1 13:37:21 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 01 Oct 2001 13:37:21 +0200 Subject: [hostmaster-staff] Re: MIR proposal Message-ID: <00A02E06.A935F1D2.7@cc.univie.ac.at> >Although both RIRs such as RIPE and LIRs such as myself are subject to 80% >rules for the acquisition of more IP space, it seems we are subject to >different 80% rules. > >For an RIR, it is 80% of their allocations, and for the LIRs it is 80% of >assigned space. Where is the big difference - both registries have given away the blocks of addresses to their down-stream entity/ies? And given the current rules forbidding reservations, any sort of "post-factum" aggregation can only be achieved by a renumbering mechanism. Btw, a more liberal way of interpreting the 80 percent rule might be looking at all the address space that is managed(*) by a particular LIR, and not only the currently "open" allocation(s). Wilfried. *) "managed" to be discussed/defined... _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From gert at space.net Mon Oct 1 16:00:36 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 16:00:36 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <00A02E04.81F3A922.5@cc.univie.ac.at>; from woeber@cc.univie.ac.at on Mon, Oct 01, 2001 at 01:21:56PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> Message-ID: <20011001160036.F16960@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mlelstv at xlink.net Mon Oct 1 17:38:53 2001 From: mlelstv at xlink.net (Michael van Elst) Date: Mon, 1 Oct 2001 17:38:53 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <00A02E04.81F3A922.5@cc.univie.ac.at>; from Wilfried Woeber, UniVie/ACOnet on Mon, Oct 01, 2001 at 01:21:56PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> Message-ID: <20011001173853.A15142@xlink.net> 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 > To: Adrian Bool > CC: lir-wg at 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 at 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 at xlink.net [ KPNQwest Germany GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Michael Mueller-Berg ] From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mally at ripe.net Mon Oct 1 19:45:28 2001 From: mally at ripe.net (Mally Mclane) Date: Mon, 1 Oct 2001 19:45:28 +0200 (CEST) Subject: Mail Loop Message-ID: Colleagues, We are aware of the mail loop on lir-wg and currently working to fix it. Apologies for the inconvenience and disruption, normal service will be resumed shortly. Regards, Mally Mclane RIPE NCC Operations From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mally at ripe.net Mon Oct 1 19:45:28 2001 From: mally at ripe.net (Mally Mclane) Date: Mon, 1 Oct 2001 19:45:28 +0200 (CEST) Subject: Mail Loop Message-ID: To: lists-lir-wg-out at lists.ripe.net Cc: Reply-To: Colleagues, We are aware of the mail loop on lir-wg and currently working to fix it. Apologies for the inconvenience and disruption, normal service will be resumed shortly. Regards, Mally Mclane RIPE NCC Operations From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: Michael van Elst 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mally at ripe.net Mon Oct 1 19:45:28 2001 From: mally at ripe.net (Mally Mclane) Date: Mon, 1 Oct 2001 19:45:28 +0200 (CEST) Subject: Mail Loop Message-ID: To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net Cc: Reply-To: Colleagues, We are aware of the mail loop on lir-wg and currently working to fix it. Apologies for the inconvenience and disruption, normal service will be resumed shortly. Regards, Mally Mclane RIPE NCC Operations From mally at ripe.net Mon Oct 1 19:45:28 2001 From: mally at ripe.net (Mally Mclane) Date: Mon, 1 Oct 2001 19:45:28 +0200 (CEST) Subject: Mail Loop Message-ID: To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net Cc: Reply-To: Colleagues, We are aware of the mail loop on lir-wg and currently working to fix it. Apologies for the inconvenience and disruption, normal service will be resumed shortly. Regards, Mally Mclane RIPE NCC Operations From mally at ripe.net Mon Oct 1 19:45:28 2001 From: mally at ripe.net (Mally Mclane) Date: Mon, 1 Oct 2001 19:45:28 +0200 (CEST) Subject: Mail Loop Message-ID: From gert at space.net Mon Oct 1 18:55:35 2001 From: gert at space.net (Gert Doering) Date: Mon, 1 Oct 2001 18:55:35 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011001173853.A15142@xlink.net>; from mlelstv@xlink.net on Mon, Oct 01, 2001 at 05:38:53PM +0200 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <20011001185535.K16960@Space.Net> From jhma at KPNQwest.net Mon Oct 1 21:45:06 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Mon, 01 Oct 2001 21:45:06 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: Your message of "Mon, 01 Oct 2001 18:55:35 +0200." <20011001185535.K16960@Space.Net> Message-ID: 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 From stephenb at uk.uu.net Tue Oct 2 11:25:05 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Tue, 2 Oct 2001 10:25:05 +0100 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> Message-ID: <003901c14b24$1f01c4c0$2e04bf3e@eu.frd.uu.net> > 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 > > To: Adrian Bool > > CC: lir-wg at 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 at 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 at xlink.net > [ KPNQwest Germany GmbH, Sitz ] > [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Michael Mueller-Berg ] > From woeber at cc.univie.ac.at Tue Oct 2 12:37:52 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 02 Oct 2001 12:37:52 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? Message-ID: <00A02EC7.84860932.5@cc.univie.ac.at> >PS To answer Wilfreds question, it is not reservation revisited it is >aggregation revisited ;) Stephen, in my opinion (from a technical persepctive only), there are two ways of attacking the problem: - 1) to clean up the legacy routes, you have to re-number (which I guess can be done within your address pool(s) - 2) to prevent it from happening again, someone, soemwhere, has to reserve a "big" block of addresses which would support a) additional demand by existing customers, and b) aggregation according to your network's internal structure Item 2) is where my notion of "reservation" is coming from. Do I still get it (completely) wrong? Btw, doing only one of those two is probably not going to work... Wilfried. From stephenb at uk.uu.net Tue Oct 2 15:29:09 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Tue, 2 Oct 2001 14:29:09 +0100 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? References: <00A02EC7.84860932.5@cc.univie.ac.at> Message-ID: <00af01c14b46$37e39460$2e04bf3e@eu.frd.uu.net> I have to say purley from a thechnical perspective this has merit. > >PS To answer Wilfreds question, it is not reservation revisited it is > >aggregation revisited ;) > > Stephen, > > in my opinion (from a technical persepctive only), there are two ways of > attacking the problem: > > - 1) to clean up the legacy routes, you have to re-number (which I guess > can be done within your address pool(s) Ok this is the legacy IP stuff that has been there for upto 10 years and the mess is partly from the ammalgamation of 17 registries (uunet) Worldcom networks, MCI networks, AOL networks (legacy) and a number of other smaller networks such as Pipex, NLnet and others. Renumbering this would be a nightmare but not impossible, the biggest problem is getting customers to renumber, as i am sure you are well aware. We could look at trying to renumber by customer churn into the new space and hand it back once free. The main reason is not to fix the current mess but to avoid more mess in the future, that said we are trying to reaggregate teh current routing tables to bew more efficient. > > - 2) to prevent it from happening again, someone, soemwhere, has to > reserve a "big" block of addresses which would support > a) additional demand by existing customers, and > b) aggregation according to your network's internal structure > Ok so what you are describing is in simplistic terms the MIR concept. The MIR would have a big block of addresses not reserved but allocated to it. This would be based on networks size LIR number and other constraints. Aggregation would be accross the 1 AS (AS702) and new assignments would be made out of the new space. Though the allocation (sub-allocation/partitioning) would be made by the MIR to the LIR the LIR would talk to RIPE for assignment approval. When the LIR reached 80% and only when then more space could be applied for to the MIR and get a block of addresses from the same CIDR preferably applying the NCC method of use last so natural holes are created next to the initial allocation. > Item 2) is where my notion of "reservation" is coming from. > Do I still get it (completely) wrong? No i think you understand the issues just not the solution, reservation is a bad word and bad practice in the current climate. > > Btw, doing only one of those two is probably not going to work... > > Wilfried. From ncc at ripe.net Tue Oct 2 16:46:46 2001 From: ncc at ripe.net (RIPE NCC Document Announcement Service) Date: Tue, 02 Oct 2001 16:46:46 +0200 Subject: New Document available: RIPE-227 Message-ID: <200110021446.f92Ekk230043@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-227 Title: RIPE NCC Autonomous System Number Request Form Author: Nurani Nimpuno, Sabrina Waschke Date: 2 October 2001 Format: PS=13173 TXT=3140 Obsoletes: ripe-147 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document contains the set of templates to be used by Local Internet Registries when requesting an Autonomous System (AS) Number from the RIPE NCC. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-227.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-227.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-227 is available from the WWW at the following URL: http://www.ripe.net/docs/asnrequestform.html From ncc at ripe.net Tue Oct 2 16:49:31 2001 From: ncc at ripe.net (RIPE NCC Document Announcement Service) Date: Tue, 02 Oct 2001 16:49:31 +0200 Subject: New Document available: RIPE-228 Message-ID: <200110021449.f92EnV231421@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-228 Title: Supporting Notes for the RIPE NCC Autonomous System Number Request Form Author: Nurani Nimpuno, Sabrina Waschke Date: 2 October 2001 Format: PS=34002 TXT=15144 Obsoletes: ripe-147 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document provides supporting notes to the Autonomous System Number Request Form. It contains instructions on how to complete the request form for AS Numbers, in the RIPE document: "RIPE NCC Autonomous System Number Request Form" Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-228.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-228.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-228 available from the WWW at the following URL: http://www.ripe.net/docs/asnsupport.html From david at iprg.nokia.com Tue Oct 2 18:55:59 2001 From: david at iprg.nokia.com (David Kessens) Date: Tue, 2 Oct 2001 09:55:59 -0700 Subject: Updated agendas and times of the joint policy sessions Message-ID: <20011002095559.A6553@iprg.nokia.com> Hi, The meeting schedule indicates that the joint lir/ipv6 wg session is starting at 14:00, wednesday, October 3rd. However, as mentioned earlier in the agenda itself, the joint lir/ipv6 session will start at 16:00 and the lir wg will use the the time from 14:00 - 15:30. Also, the agenda has been modified slightly. The new ipv6 draft policy document is published now and Mirjam will give an outline presentation regarding the new draft. I hope this helps, David K. --- Agenda for the IPv6/lir joint session RIPE40, Prague Wednesday October 3rd, 2001, 16:00 - 17:30 Topic: Revision of the general ipv6 allocation guidelines Materials to read: - ripe-196: http://www.ripe.net/ripe/docs/ipv6policy.html - http://www.djp.net/ipv6/proposal.html - http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/RIPE39-IPv6-policy/index.html A. Administrative stuff - appointment of scribe - agenda bashing B. How to proceed for the next iteration of the policy. C. Proposal for the next version of the policy http://www.djp.net/ipv6/proposal.html (Dave Pratt) D. RIR IPv6 Address Policy Proposal - Outline (Mirjam) - Results of the proposal discussion at the last APNIC meeting Takashi Arano (JPNIC/Asia Global Crossing) Gerard Ross (APNIC) E. Discussion Z. AOB ------------------------- Agenda for the IPv6/lir/eix joint session RIPE40, Prague Thursday October 4th, 2001, 11:00 - 12:30 Topic: Interim policy for allocation of ipv6 addresses for Internet Exchange Points A. Administrative stuff - appointment of scribe - agenda bashing B. How to proceed for the next iteration of the policy. C. Selection of most important issues that we want to discuss during this session: - how to proceed from the interim policy ?!? - default /64 or /48 allocation size - do we want to have this space allocated from a special block, may be even block that is used by all RIRs for this purpose - what documentation is needed to get an allocation - is there any need to document allocations in the RIPE database, and if so, how ?!? - general wording of the policy (Mirjam will present these issues) D. Discussion of the issues Z. AOB --- From mlelstv at xlink.net Tue Oct 2 20:23:29 2001 From: mlelstv at xlink.net (Michael van Elst) Date: Tue, 2 Oct 2001 20:23:29 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <003901c14b24$1f01c4c0$2e04bf3e@eu.frd.uu.net>; from Stephen Burley on Tue, Oct 02, 2001 at 10:25:05AM +0100 References: <00A02E04.81F3A922.5@cc.univie.ac.at> <20011001173853.A15142@xlink.net> <003901c14b24$1f01c4c0$2e04bf3e@eu.frd.uu.net> Message-ID: <20011002202329.A3705@xlink.net> 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 at xlink.net [ KPNQwest Germany GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Michael Mueller-Berg ] From ripe-ml at cyberstrider.net Wed Oct 3 00:09:22 2001 From: ripe-ml at cyberstrider.net (Denesh Bhabuta) Date: Tue, 2 Oct 2001 23:09:22 +0100 Subject: Chairing LIR-WG Wednesday 3 October Message-ID: <20011002230922.A14418@cyberstrider.net> Dear members I have been informed by Mirjam that Hans Petter is unlikely to make it to the RIPE meeting this time due to things out of his control (Swiss Air, etc) In addition, James Aldridge is not here. It is thus very likely that I will be helping by chairing the meeting tomorrow. If you have any issues you wish me to be aware of, or wish to discuss anything, please do not hesitate to approach me - and in case you do not know what I look like: http://photos.jml.net/photo.php?id=37633 Regards Denesh -- Denesh Bhabuta From beri at kpnqwest.net Wed Oct 3 10:45:19 2001 From: beri at kpnqwest.net (Berislav Todorovic) Date: Wed, 3 Oct 2001 10:45:19 +0200 (CEST) Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: <20011002202329.A3705@xlink.net> Message-ID: 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 at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From mlelstv at xlink.net Wed Oct 3 12:31:40 2001 From: mlelstv at xlink.net (Michael van Elst) Date: Wed, 3 Oct 2001 12:31:40 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: ; from Berislav Todorovic on Wed, Oct 03, 2001 at 10:45:19AM +0200 References: <20011002202329.A3705@xlink.net> Message-ID: <20011003123140.A11534@xlink.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 at xlink.net [ KPNQwest Germany GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Michael Mueller-Berg ] From nurani at ripe.net Wed Oct 3 17:40:27 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Wed, 03 Oct 2001 17:40:27 +0200 Subject: Revision of IPv4 policy draft document Message-ID: <5.1.0.14.2.20011003164003.02f64d60@localhost> Dear all, To facilitate the revision of the IPv4 policy draft document, the following mailing list has been set up: is a mailing list set up for the participants of the editorial committee of this document, but is also a publicly open mailing list, archived at: http://www.ripe.net/ripe/mail-archives/ripe-185bis/index.html (Available from the LIR-WG website: http://www.ripe.net/ripe/wg/lir/index.html) If you wish to subscribe to this mailing list, please send a mail to with "subscribe ripe-185 at ripe.net" (without quotation marks) in the body of the message. Additionally, a physical meeting will made possible this evening in Prague for any parties interested in participating in the editorial committee. It will take place after (during? :) the RIPE Meeting social event at the Marriott hotel in Prague. A meeting room "Bohemia" is reserved for discussing this document and to agree on the coming steps in the revision process. - All interested parties are welcome to bring their drinks from the social with them. :-) Kind regards, Nurani Nimpuno RIPE NCC From djp-ripe-lists at djp.net Wed Oct 3 17:59:07 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Wed, 3 Oct 2001 17:59:07 +0200 (CEST) Subject: My slides available on the WWW Message-ID: Hiya Folks, The slides for the presentation I gave this afternoon are available at: http://www.djp.net/ipv6/pr/ Cheers Dave From hph at online.no Fri Oct 5 11:29:53 2001 From: hph at online.no (Hans Petter Holen) Date: Fri, 5 Oct 2001 11:29:53 +0200 Subject: Action list after RIPE 40 Message-ID: <005501c14f35$2389d0e0$2b0900c1@hholkvza> 35.4 NCC PGP Key exchange procedure Low prio 35.5 NCC Implement PGP for hm Low prio 36.5 Chair Assignment window applied on infrastructure New Policy 36.7 NCC Keep lir-wg updated on pre RIR address space changes Plenary presentation 38.2 NCC Implement changes to the form while taking into account the comments from the WG Pending 185 revision 38.3 WG Reopen policy discussion - do we need a major revision of RIPE 185 Ongoing 38.4 AC Consider how to coordinate Address prediction work Work launced 38.5 NCC Implement 34.6 LIR-ALLOCATED 38.6 HPH (NCC) Propose PI policy to the WG Ongoing 39.2 NCC Suggest procedure and possible policy changes DONE 39.4 Chairs Define & divide work 39.5 Chairs Beta test 6 weeks deadline for proposals Move to 2nd beta 40.1 NCC/ET RIPE 185 2nd draft 40.2 WG Further discuss MIR/SUB-LIR 40.2 NCC Implement new AW policy 40.3 WG Further discuss possible policy change for PI 40.4 RB AC Election Done 40.5 WG Join RFC2050 mailinglist to give input to revision 40.6 RIRs Produce drafts to replace 2050 for discussion by wg 40.7 RIRs Produce interim policy draft with the help of Arano-san & Mr Bush within 2 weeks 40.8 WG Further discuss final IPv6 policy 40.9 RIRs Set up global IPv6 policy list From kieber at gatel.net Mon Oct 8 20:02:38 2001 From: kieber at gatel.net (Ulf Kieber) Date: Mon, 8 Oct 2001 20:02:38 +0200 (CEST) Subject: automatic DB cleanup proposal Message-ID: <200110081802.UAA15680@rocky.gatel.net> Re everybody, following up to some personal talks during the RIPE meeting I propose an automatic cleanup of orphaned person and role objects in the RIPE DB. Motivation ---------- In the light of data privacy issues raised by governmental organizations and in RIPE Database Working Group sessions during RIPE-39 and RIPE-40, as well as following the Great Dangling Person Objects Deletion after de.* ccTLD move-out I propose an automized garbage collection procedure to remove personal data that is unreferenced for a certain amount of time. Proposed Change --------------- An additional attibute ``expire:'' with two values should be added to all person and role objects. The values to this attribute would be a reference counter and a modification timestamp. The reference counter would contain the number of objects still refering to this object, and thus be analog to the link counter of an inode in a UNIX file system. The modification timestamp would be updated whenever the object is updated or the link counter changes. The analogy in the UNIX file system would be sort of a mix of ctime and mtime. Both values could be combined into a single value, but each value of it's own may be of interest to some people. Combining both values would leave the resulting value useless to human interpretation. A garbage collection process running on a periodic basis should then delete all objects with a reference counter of ``0'' and a modification timestamp of more than e.g. 8000000 seconds (approx. 3 month) ago. The expiration period is to be discussed and agreed upon in the community. An additional switch to the whois client should be added to make the otherwise invisible attribute visible, the DB should consequently not accept ``expire:'' attributes in updates. (The DB could certainly be made more forgiving about this, but since the move to v.3 tightened the syntax we should probably not weaken it again.) Database Objects affected ------------------------- An additional attribute would be added to all person and role objects. role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] trouble: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] expire: [generated] [single] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] expire: [generated] [single] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Example ------- inetnum: 10.0.0.0 - 10.0.255.255 netname: XMAS descr: Santa's Workshop Inc. Christmas Toys Manufacturing Facility Northern Nowhere country: NN admin-c: SC12-RIPE tech-c: SWT95-RIPE status: ASSIGNED PA mnt-by: SANTA-SECURITY-MNT changed: jbgood at antarctic.nn 19960412 source: RIPE role: Santa Workshop Team address: Santa's Workshop Inc. Jingle Bell Lane 12 1224CH Christmastown Northern Nowhere phone: +12 12 122 3333 fax-no: +12 12 221 4444 e-mail: team at antarctic.nn admin-c: SC12-RIPE tech-c: SC12-RIPE tech-c: RD212-RIPE nic-hdl: SWT95-RIPE mnt-by: SANTA-SECURITY-MNT expire: 1 849700000 changed: jbgood at antarctic.nn 19960412 source: RIPE person: Santa A. Claus address: Santa's Workshop Inc. Jingle Bell Lane 12 1224CH Christmastown Northern Nowhere phone: +12 12 122 2121 +12 12 122 2211 ext. 1221 fax-no: +12 12 221 1212 e-mail: santa at antarctic.nn nic-hdl: SC12-RIPE mnt-by: SANTA-SECURITY-MNT expire: 3 849700000 changed: jbgood at antarctic.nn 19960412 source: RIPE person: Rudolf R N Reindeer address: Santa's Workshop Inc. Jingle Bell Lane 21 1224CH Christmastown Northern Nowhere phone: +12 12 122 1111 fax-no: +12 12 122 2222 nic-hdl: RD212-RIPE e-mail: rudolf at xmas.nn mnt-by: SANTA-SECURITY-MNT expire: 1 849700000 changed: jbgood at antarctic.nn 19960412 source: RIPE -- Ulf Kieber email: kieber at gatel.net Senior Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-40 internet solutions for business www : www.gatel.net The Database Toothbrush Proposal From gert at space.net Tue Oct 9 12:15:57 2001 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2001 12:15:57 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009131049.A60790@lucky.net>; from vovik@lucky.net on Tue, Oct 09, 2001 at 01:10:49PM +0300 References: <20011009131049.A60790@lucky.net> Message-ID: <20011009121557.C16960@Space.Net> Hi, On Tue, Oct 09, 2001 at 01:10:49PM +0300, Vladimir A. Jakovenko wrote: > According to my observations at least since this summer the RIPE NCC staff > promotes usage of more specific PA routes (originated by more than one AS) > for multihomed customers opposite to the "classic" scheme with PI addresses > (or new enterpise LIR ;-). > > In this situation we are going to expect increase of ammount of: > > 1. Routes with more than one origin. No - the more specifics are announced by the customer AS *only* (and the upstream AS that this blocks belongs to will permit them "through"). > 2. Less specific routes within existing more specific. Yes. > Actual (ripe-185) document of "IPv4 and ASN Policies in the RIPE NCC Service > Region" and working draft (on http://www.ripe.net/rs/ipv4policy.html) > refer to rfc1930 which contains section 7 - "One prefix, one origin AS": Yes, but this is a non-issue here. [..] > According to measurements on RIPE DB dump on Oct 4 there were about 17% of > prefixes with more than on origin AS. It isn't just RIPE specific - > measurements from other IRRs are close. This is well possible, but not a necessity for this type of multihoming - to the contrary, in most cases it's a mistake or a transitional thing. > Announcement of less specific routes within existent more specific route > (lets assume that there is no bgp routing process misconfiguration - both, > less and more specific, routes have route objects) clashes with an aggregation > issues promoted in many RIPE documents. Yes, but looking at the overall table, it's beneficial. - you have the same amount of routes as with "small PI", so it's not worse - if one is filtering "no /24's", the end site is *still* be reachable, which would not work with PI space. [..] > Unfortunately it is difficult to dispute such policy unactuality without > appropriate documents. Is it possible at least "to legalize" applicability > of more specific routes with more than one origin for multihoming purposes > in ripe-185 successor? RIPE has no power about *routing*. But there has been talk on the last meeting about writing a BCP concerning routing issues and recommendations (I have no idea what the state of this is or whether anybody is working on it). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From vovik at lucky.net Tue Oct 9 12:10:49 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Oct 2001 13:10:49 +0300 Subject: more specific routes in today reality Message-ID: <20011009131049.A60790@lucky.net> Hello. My apologies if mentioned below issues have already been discussed. If they were - pls just point me to the location where I can find more on that subject. According to my observations at least since this summer the RIPE NCC staff promotes usage of more specific PA routes (originated by more than one AS) for multihomed customers opposite to the "classic" scheme with PI addresses (or new enterpise LIR ;-). In this situation we are going to expect increase of ammount of: 1. Routes with more than one origin. 2. Less specific routes within existing more specific. Actual (ripe-185) document of "IPv4 and ASN Policies in the RIPE NCC Service Region" and working draft (on http://www.ripe.net/rs/ipv4policy.html) refer to rfc1930 which contains section 7 - "One prefix, one origin AS": Generally, a prefix can should belong to only one AS. This is a direct consequence of the fact that at each point in the Internet there can be exactly one routing policy for traffic destined to each prefix. In the case of an prefix which is used in neighbor peering between two ASes, a conscious decision should be made as to which AS this prefix actually resides in. With the introduction of aggregation it should be noted that a prefix may be represented as residing in more than one AS, however, this is very much the exception rather than the rule. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ According to measurements on RIPE DB dump on Oct 4 there were about 17% of prefixes with more than on origin AS. It isn't just RIPE specific - measurements from other IRRs are close. Announcement of less specific routes within existent more specific route (lets assume that there is no bgp routing process misconfiguration - both, less and more specific, routes have route objects) clashes with an aggregation issues promoted in many RIPE documents. In 1990th such announces would be treated as typical "bad practice" but now they are more and more close to "regular practice". Just in fact there is still some network operators, whose routing policy (in the part of BGP peers filtering) had been formed by influence of rfc1930 and other aggregation issues, states something like that: "if peer announces more specific routes within existent less specific route, all more specific routes will be rejected unless peer explicity asks to accept it". Unfortunately it is difficult to dispute such policy unactuality without appropriate documents. Is it possible at least "to legalize" applicability of more specific routes with more than one origin for multihoming purposes in ripe-185 successor? On my opinnion it would be also good to: 1. Create new RIPE document which would describe usage of more specific routes with multiple origins for multihoming, including all pros and cons of such technique. 2. Extend ripe-127 successor with references to new document mentioned above or (why not?) integrate both of them in one document. 3. Extend ripe-211 successor with something like that: "Due to tendency of increasing number of small blocks (smaller than the default allocation size) of PI or PA (more specific multihoming, load balancing, etc) addresses network operators taking routing decisions based on prefix length are recommended to accept and route longer (up to /24) prefixes with valid route objects." -- Regards, Vladimir. From ggm at apnic.net Tue Oct 9 12:28:00 2001 From: ggm at apnic.net (George Michaelson) Date: Tue, 09 Oct 2001 20:28:00 +1000 Subject: automatic DB cleanup proposal In-Reply-To: Your message of "Mon, 08 Oct 2001 20:02:38 +0200." <200110081802.UAA15680@rocky.gatel.net> Message-ID: <9050.1002623280@apnic.net> I think the base principles behind cleanups are great, and I intend proposing APNIC explore a similar course of action to the manual sweep. I am worried that there may be *external* referencees to objects, and while we have no 'contractual' obligation it might not be nice to do this to people without some engagement but I expect most people would welcome losing a path to spam. As to automatic sweeping, I think there are problems with link counting which are similar to those we've faced in discussing cross-database linkage and references. Too many risks of the link count getting out of whack. I think you could use it as a guide to a sweep, but not as a determinant without some review and other checks. Eg to trigger more exhaustive checks to see if there are are references in twisty ways. cheers -George From sp at iphh.net Tue Oct 9 12:32:47 2001 From: sp at iphh.net (Sascha E. Pollok) Date: Tue, 09 Oct 2001 12:32:47 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009121557.C16960@Space.Net> References: <20011009131049.A60790@lucky.net> <20011009131049.A60790@lucky.net> Message-ID: Gert, Vladimir, >> In this situation we are going to expect increase of ammount of: >> >> 1. Routes with more than one origin. > >No - the more specifics are announced by the customer AS *only* (and the >upstream AS that this blocks belongs to will permit them "through"). This looks like a little bit different idea of doing it (like Vladimir said): "- If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route (with the PA block holder adding a more specific route too)." This was suggested from a RIPE NCC Hostmaster when sending a PI-space req. This looks a little contrary to your opinion doesn't it? Sascha From gert at space.net Tue Oct 9 13:19:58 2001 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2001 13:19:58 +0200 Subject: more specific routes in today reality In-Reply-To: ; from sp@iphh.net on Tue, Oct 09, 2001 at 12:32:47PM +0200 References: <20011009131049.A60790@lucky.net> <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> Message-ID: <20011009131958.E16960@Space.Net> Hi, On Tue, Oct 09, 2001 at 12:32:47PM +0200, Sascha E. Pollok wrote: > >> In this situation we are going to expect increase of ammount of: > >> > >> 1. Routes with more than one origin. > > > >No - the more specifics are announced by the customer AS *only* (and the > >upstream AS that this blocks belongs to will permit them "through"). > > This looks like a little bit different idea of doing it (like Vladimir > said): > > "- If PI is requested for multi-homing please explain why the second > provider cannot route PA space as a more specific route (with the > PA block holder adding a more specific route too)." This doesn't specify who is originating the BGP prefix. Both providers have to *route* it, of course. Of course, even if it is not explicitely mentioned, the first provider will also have to let the more-specific "through" (otherwise only the second provider will get the traffic). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From sp at iphh.net Tue Oct 9 13:22:43 2001 From: sp at iphh.net (Sascha E. Pollok) Date: Tue, 09 Oct 2001 13:22:43 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009131958.E16960@Space.Net> References: <20011009131049.A60790@lucky.net> <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> Message-ID: >> "- If PI is requested for multi-homing please explain why the second >> provider cannot route PA space as a more specific route (with the >> PA block holder adding a more specific route too)." > >This doesn't specify who is originating the BGP prefix. Both providers >have to *route* it, of course. We got this reply to a PI-space request for a customer that does not have his own ASN therefore ISPs would need to originate the route. Don't you think that this implies originating the prefix from two different ASes? (would appear when doing "sh ip bgp incons"). Sascha From randy at psg.com Tue Oct 9 13:34:05 2001 From: randy at psg.com (Randy Bush) Date: Tue, 09 Oct 2001 04:34:05 -0700 Subject: more specific routes in today reality References: <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> Message-ID: >>> "- If PI is requested for multi-homing please explain why the second >>> provider cannot route PA space as a more specific route (with the >>> PA block holder adding a more specific route too)." >> This doesn't specify who is originating the BGP prefix. Both providers >> have to *route* it, of course. > We got this reply to a PI-space request for a customer that does > not have his own ASN if the customer follows this path, they should get their own asn randy From gert at space.net Tue Oct 9 13:44:12 2001 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2001 13:44:12 +0200 Subject: more specific routes in today reality In-Reply-To: ; from sp@iphh.net on Tue, Oct 09, 2001 at 01:22:43PM +0200 References: <20011009131049.A60790@lucky.net> <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> <20011009131958.E16960@Space.Net> Message-ID: <20011009134412.G16960@Space.Net> Hi, On Tue, Oct 09, 2001 at 01:22:43PM +0200, Sascha E. Pollok wrote: > >> "- If PI is requested for multi-homing please explain why the second > >> provider cannot route PA space as a more specific route (with the > >> PA block holder adding a more specific route too)." > > > >This doesn't specify who is originating the BGP prefix. Both providers > >have to *route* it, of course. > > We got this reply to a PI-space request for a customer that does > not have his own ASN therefore ISPs would need to originate the > route. Don't you think that this implies originating the prefix > from two different ASes? (would appear when doing "sh ip bgp incons"). Yes. But this would not be any different from getting a PI space and announcing it inconsistently, that is, originating it from both ISPs. Which is not a good practice in any case - I agree on that. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From woeber at cc.univie.ac.at Tue Oct 9 13:55:57 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 09 Oct 2001 13:55:57 +0200 Subject: automatic DB cleanup proposal Message-ID: <00A03452.95DB3EE2.9@cc.univie.ac.at> Dear George, >I am worried that there may be *external* referencees to objects, and while >we have no 'contractual' obligation it might not be nice to do this >to people without some engagement but I expect most people would welcome >losing a path to spam. without going into any detail of the proposal itself, I perceive the fact that there are external references (allowed) _without "consent" and without documentation_ a major flaw in the architecture. In fact, there are mechanisms available already (at least in the RIPE DB-SW V2.x and V3.x) that allow us to deal with that requirement: maintainer objects. >As to automatic sweeping, I think there are problems with link counting >which are similar to those we've faced in discussing cross-database linkage >and references. Too many risks of the link count getting out of whack. Fair enough, a very valid concern! But I think the proposal is trying to describe the "user view" and the "abstract behaviour". >I think you could use it as a guide to a sweep, but not as a determinant >without some review and other checks. Eg to trigger more exhaustive checks >to see if there are are references in twisty ways. I agree. >cheers > -George Cheers, and thanks for partcipating in this discussion! Wilfried. From kieber at gatel.net Tue Oct 9 13:48:20 2001 From: kieber at gatel.net (Ulf Kieber) Date: Tue, 9 Oct 2001 13:48:20 +0200 (CEST) Subject: automatic DB cleanup proposal In-Reply-To: <9050.1002623280@apnic.net> from George Michaelson at "Oct 9, 2001 8:28: 0 pm" Message-ID: <200110091148.NAA19360@rocky.gatel.net> George Michaelson writes: > I am worried that there may be *external* referencees to objects, and while > we have no 'contractual' obligation it might not be nice to do this > to people without some engagement but I expect most people would welcome > losing a path to spam. external references to DB objects are never going to work reliably. I don't see why we should try ever so hard in making something work when we can't succeed. Also, we would have to argue with data privacy agencies all over Europe as to why we need to leave an object in the DB that's referenced only from an external source. ``They should create their own object in their own DB'' would be an almost certain response from the data privacy guys. > As to automatic sweeping, I think there are problems with link counting > which are similar to those we've faced in discussing cross-database linkage > and references. Too many risks of the link count getting out of whack. Nope. The RIPE DB already has a mechanism that prevents objects from being deleted if there are still references to it. So, a double check is already in place. :) The generation of the reference counter should be done by counting references in the DB anyway, instead of mere incrementing or decrementing the existent counter. This way the DB resyncs every time a person or role object is touched. > I think you could use it as a guide to a sweep, but not as a determinant > without some review and other checks. Eg to trigger more exhaustive checks > to see if there are are references in twisty ways. The only other precaution that should be taken IMHO is to honor any applicable mnt-nfy and notify attribute. -- Ulf Kieber email: kieber at gatel.net Senior Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-40 internet solutions for business www : www.gatel.net From kieber at gatel.net Tue Oct 9 14:07:58 2001 From: kieber at gatel.net (Ulf Kieber) Date: Tue, 9 Oct 2001 14:07:58 +0200 (CEST) Subject: automatic DB cleanup proposal Message-ID: <200110091207.OAA19457@rocky.gatel.net> Somebody @ RIPE NCC, speaking for himself, not for RIPE NCC, writes: > On 2001-10-08 20:02:38 +0200, Ulf Kieber wrote: > > > > The modification timestamp would be updated whenever the object is > > updated or the link counter changes. The analogy in the UNIX file > > system would be sort of a mix of ctime and mtime. > > > > > expire: 1 849700000 > > I suggest that this look more like the timestamp in the changed > attribute: > > expire: 1 20011008 > > Human-readable == good. :) Seconded. Daily granularity is good enough, but way more readable. Make is so. > Perhaps this attribute should also be present on maintainer and irt > objects, since they contain contact information as well? Not > necessarily as important, but possible. Then we could put it onto key-cert as well. I'm sort of reluctent to have it placed onto maintainer objects which can not be recreated without interaction with the NCC. I'd at least ask for an extended expiration period. -- Ulf Kieber email: kieber at gatel.net Senior Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-40 internet solutions for business www : www.gatel.net From gert at space.net Tue Oct 9 15:23:30 2001 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2001 15:23:30 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009160208.D2763@lucky.net>; from vovik@lucky.net on Tue, Oct 09, 2001 at 04:02:08PM +0300 References: <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> <20011009160208.D2763@lucky.net> Message-ID: <20011009152329.M16960@Space.Net> Hi, On Tue, Oct 09, 2001 at 04:02:08PM +0300, Vladimir A. Jakovenko wrote: > >> 1. Routes with more than one origin. > > > >No - the more specifics are announced by the customer AS *only* (and the > >upstream AS that this blocks belongs to will permit them "through"). > > We are talking about different types of multihoming. I mean simple multihoming > situation when all multihomed customer's needs in routing are covered by they > upstream providers routing policies. In this situation more specific PA route > can be originated by upstreams without allocation to customer new AS-num. > Moreover, according to ripe-185: > > In order to help decrease global routing complexity, a new AS Number > should be created only if a new routing policy is required. I didn't realize this, but I agree with Randy on this: without their own AS number (and with them doing the BGP origination stuff and so on), this isn't going to work anyway - if they do not want to do BGP, then they should multi-home to the *same* ISP. [..] > > - if one is filtering "no /24's", the end site is *still* be reachable, > > which would not work with PI space. > > Disagree. During last time a number of routing curioses at least in our country > have been caused by incorect announcements or filtering more specific routes > within already announced less specific routes. If you want, I can describe some > of the most common problems. PI addresses have its own set of problems, more > specific PA addresses also have own set problems. This sets partly overlaps, > but not same. And PA more specific isn't safer than PI. They just unsafe a bit > more different. They will be much safer when people start filtering out "long prefixes". Which will happen *soon*. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Tue Oct 9 15:24:41 2001 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2001 15:24:41 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009161439.E2763@lucky.net>; from vovik@lucky.net on Tue, Oct 09, 2001 at 04:14:39PM +0300 References: <20011009131049.A60790@lucky.net> <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> <20011009131958.E16960@Space.Net> <20011009134412.G16960@Space.Net> <20011009161439.E2763@lucky.net> Message-ID: <20011009152441.N16960@Space.Net> hi, On Tue, Oct 09, 2001 at 04:14:39PM +0300, Vladimir A. Jakovenko wrote: > >Which is not a good practice in any case - I agree on that. > > What is a good practice for small company who needs: > > 1. Small ammount of ip addresses (about /24) > 2. Multihoming The best practive is "to question the need for multihoming". Multihoming as a solution for *what*? Yes, there are good reasons for wanting to be multihomed, but things like "network stability" and "lower costs" are not the ones. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From vovik at lucky.net Tue Oct 9 15:02:08 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Oct 2001 16:02:08 +0300 Subject: more specific routes in today reality In-Reply-To: <20011009121557.C16960@Space.Net>; from gert@Space.Net on Tue, Oct 09, 2001 at 12:15:57PM +0200 References: <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> Message-ID: <20011009160208.D2763@lucky.net> On Tue, Oct 09, 2001 at 12:15:57PM +0200, Gert Doering wrote: >Hi, > >On Tue, Oct 09, 2001 at 01:10:49PM +0300, Vladimir A. Jakovenko wrote: >> According to my observations at least since this summer the RIPE NCC staff >> promotes usage of more specific PA routes (originated by more than one AS) >> for multihomed customers opposite to the "classic" scheme with PI addresses >> (or new enterpise LIR ;-). >> >> In this situation we are going to expect increase of ammount of: >> >> 1. Routes with more than one origin. > >No - the more specifics are announced by the customer AS *only* (and the >upstream AS that this blocks belongs to will permit them "through"). We are talking about different types of multihoming. I mean simple multihoming situation when all multihomed customer's needs in routing are covered by they upstream providers routing policies. In this situation more specific PA route can be originated by upstreams without allocation to customer new AS-num. Moreover, according to ripe-185: In order to help decrease global routing complexity, a new AS Number should be created only if a new routing policy is required. >> 2. Less specific routes within existing more specific. > >Yes. > >> Actual (ripe-185) document of "IPv4 and ASN Policies in the RIPE NCC Service >> Region" and working draft (on http://www.ripe.net/rs/ipv4policy.html) >> refer to rfc1930 which contains section 7 - "One prefix, one origin AS": > >Yes, but this is a non-issue here. Why? >[..] >> According to measurements on RIPE DB dump on Oct 4 there were about 17% of >> prefixes with more than on origin AS. It isn't just RIPE specific - >> measurements from other IRRs are close. > >This is well possible, but not a necessity for this type of multihoming - >to the contrary, in most cases it's a mistake or a transitional thing. I do not believe that the most of them are errors. Yes, not all of them was created for multihoming purposes (don't forget about incoming-channel load balancing :), but amount of multihoming part (on my opinnion) are increasing. >> Announcement of less specific routes within existent more specific route >> (lets assume that there is no bgp routing process misconfiguration - both, >> less and more specific, routes have route objects) clashes with an aggregation >> issues promoted in many RIPE documents. > >Yes, but looking at the overall table, it's beneficial. > > - you have the same amount of routes as with "small PI", so it's not worse Agree. > - if one is filtering "no /24's", the end site is *still* be reachable, > which would not work with PI space. Disagree. During last time a number of routing curioses at least in our country have been caused by incorect announcements or filtering more specific routes within already announced less specific routes. If you want, I can describe some of the most common problems. PI addresses have its own set of problems, more specific PA addresses also have own set problems. This sets partly overlaps, but not same. And PA more specific isn't safer than PI. They just unsafe a bit more different. >[..] >> Unfortunately it is difficult to dispute such policy unactuality without >> appropriate documents. Is it possible at least "to legalize" applicability >> of more specific routes with more than one origin for multihoming purposes >> in ripe-185 successor? > >RIPE has no power about *routing*. But there has been talk on the last >meeting about writing a BCP concerning routing issues and recommendations >(I have no idea what the state of this is or whether anybody is working >on it). RIPE has the power to make recomendations and publish documents. RIPE NCC has the power in ip address space allocation. Good practice for people who make decisions in this region is to take into consideration RIPE recomendations. If RIPE NCC are going to propose usage of more specific routes for multihoming why not to cover that technique with all pros and cons in appropriate documents? -- Regards, Vladimir. From vovik at lucky.net Tue Oct 9 15:14:39 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Oct 2001 16:14:39 +0300 Subject: more specific routes in today reality In-Reply-To: <20011009134412.G16960@Space.Net>; from gert@Space.Net on Tue, Oct 09, 2001 at 01:44:12PM +0200 References: <20011009131049.A60790@lucky.net> <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> <20011009131958.E16960@Space.Net> <20011009134412.G16960@Space.Net> Message-ID: <20011009161439.E2763@lucky.net> On Tue, Oct 09, 2001 at 01:44:12PM +0200, Gert Doering wrote: >Hi, > >On Tue, Oct 09, 2001 at 01:22:43PM +0200, Sascha E. Pollok wrote: >> >> "- If PI is requested for multi-homing please explain why the second >> >> provider cannot route PA space as a more specific route (with the >> >> PA block holder adding a more specific route too)." >> > >> >This doesn't specify who is originating the BGP prefix. Both providers >> >have to *route* it, of course. >> >> We got this reply to a PI-space request for a customer that does >> not have his own ASN therefore ISPs would need to originate the >> route. Don't you think that this implies originating the prefix >> from two different ASes? (would appear when doing "sh ip bgp incons"). > >Yes. But this would not be any different from getting a PI space and >announcing it inconsistently, that is, originating it from both ISPs. > >Which is not a good practice in any case - I agree on that. What is a good practice for small company who needs: 1. Small ammount of ip addresses (about /24) 2. Multihoming ? -- Regards, Vladimir. From lars at marowsky-bree.de Tue Oct 9 15:18:45 2001 From: lars at marowsky-bree.de (lmb) Date: Tue, 9 Oct 2001 15:18:45 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009161439.E2763@lucky.net>; from "Vladimir A. Jakovenko" on 2001-10-09T16:14:39 References: <20011009131049.A60790@lucky.net> <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> <20011009131958.E16960@Space.Net> <20011009134412.G16960@Space.Net> <20011009161439.E2763@lucky.net> Message-ID: <20011009151845.M518@marowsky-bree.de> On 2001-10-09T16:14:39, "Vladimir A. Jakovenko" said: > What is a good practice for small company who needs: > > 1. Small ammount of ip addresses (about /24) > 2. Multihoming IMHO: Select a sensible provider with internal redundancy and multi home to that one via redudant links. -- "I'm extraordinarily patient provided I get my own way in the end." -- Margeret Thatcher From randy at psg.com Tue Oct 9 16:19:35 2001 From: randy at psg.com (Randy Bush) Date: Tue, 09 Oct 2001 07:19:35 -0700 Subject: more specific routes in today reality References: <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> <20011009160208.D2763@lucky.net> Message-ID: > We are talking about different types of multihoming. I mean simple > multihoming situation when all multihomed customer's needs in routing are > covered by they upstream providers routing policies. ^ note the use of plural above. now read rfc 1930. randy From mirta.matic at hinet.hr Tue Oct 9 15:55:06 2001 From: mirta.matic at hinet.hr (Mirta Matic) Date: Tue, 9 Oct 2001 15:55:06 +0200 Subject: more specific routes in today reality References: <20011009131049.A60790@lucky.net> <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> <20011009131958.E16960@Space.Net> <20011009134412.G16960@Space.Net> Message-ID: <020901c150ca$00557160$10fba8c0@net.hinet.hr> Hello, have you ever heard for RADWARE solution for that problem? Some RADWARE box can check distance to destination via both ISP's and makes decision from what IP address range have to get address for NAT (of course, customer have to have two ranges of addresses). If connection via one ISP failed, all traffic will be rerouted via another using IP address from IP address range of that ISP. Mirta Matic mirta.matic at hinet.hr tel: +385 1 4914 207 fax: +385 1 4914 222 ----- Original Message ----- From: "Gert Doering" To: "Sascha E. Pollok" Cc: "Gert Doering" ; "Vladimir A. Jakovenko" ; ; Sent: Tuesday, October 09, 2001 1:44 PM Subject: Re: more specific routes in today reality > Hi, > > On Tue, Oct 09, 2001 at 01:22:43PM +0200, Sascha E. Pollok wrote: > > >> "- If PI is requested for multi-homing please explain why the second > > >> provider cannot route PA space as a more specific route (with the > > >> PA block holder adding a more specific route too)." > > > > > >This doesn't specify who is originating the BGP prefix. Both providers > > >have to *route* it, of course. > > > > We got this reply to a PI-space request for a customer that does > > not have his own ASN therefore ISPs would need to originate the > > route. Don't you think that this implies originating the prefix > > from two different ASes? (would appear when doing "sh ip bgp incons"). > > Yes. But this would not be any different from getting a PI space and > announcing it inconsistently, that is, originating it from both ISPs. > > Which is not a good practice in any case - I agree on that. > > Gert Doering > -- NetMaster > -- > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > From cfriacas at fccn.pt Tue Oct 9 16:16:46 2001 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 9 Oct 2001 15:16:46 +0100 (WEST) Subject: more specific routes in today reality In-Reply-To: <20011009152441.N16960@Space.Net> Message-ID: Hi, Gert et al. On Tue, 9 Oct 2001, Gert Doering wrote: > hi, > > On Tue, Oct 09, 2001 at 04:14:39PM +0300, Vladimir A. Jakovenko wrote: > > >Which is not a good practice in any case - I agree on that. > > > > What is a good practice for small company who needs: > > > > 1. Small ammount of ip addresses (about /24) > > 2. Multihoming > > The best practive is "to question the need for multihoming". that ISP will be very happy to provide it... more cash... Viewing it from the angle of a *second* ISP which doesnt have a company as its client, probably they will be happy on getting a new client, independently if they are the main ISP of that client or not... its just a question of more money... If you have a client which is *only* connected to you and he asks you about multihoming, and you say its a bad ideia, you'll be probably seen as wanting to protect your revenue/business. If you go on talking about the global routing table (which is a correct aproach!), the client will not be that much interested, i guess... I mean, im on your side but i can recognize that this is a technical problem, an issue that clients want to see solved without getting even a clue on it. > Multihoming as a solution for *what*? Yes, there are good reasons for > wanting to be multihomed, but things like "network stability" and > "lower costs" are not the ones. Especially lower costs... if people want redundancy on line availability they have to pay more for it... About stability, its not impossible, but keeping it simple with only one ISP will cause anybody a whole lot less of headaches. > Gert Doering > -- NetMaster > -- > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > Regards, ps: Gert, when you get the next shipment of "no-/24's" badges, save me one, ok ? ;-) ./Carlos "Networking is fun!" ------------------- , CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 From vovik at lucky.net Tue Oct 9 16:30:34 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Oct 2001 17:30:34 +0300 Subject: more specific routes in today reality In-Reply-To: <20011009152329.M16960@Space.Net>; from gert@Space.Net on Tue, Oct 09, 2001 at 03:23:30PM +0200 References: <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> <20011009160208.D2763@lucky.net> <20011009152329.M16960@Space.Net> Message-ID: <20011009173034.G2763@lucky.net> On Tue, Oct 09, 2001 at 03:23:30PM +0200, Gert Doering wrote: >Hi, > >On Tue, Oct 09, 2001 at 04:02:08PM +0300, Vladimir A. Jakovenko wrote: >> >> 1. Routes with more than one origin. >> > >> >No - the more specifics are announced by the customer AS *only* (and the >> >upstream AS that this blocks belongs to will permit them "through"). >> >> We are talking about different types of multihoming. I mean simple multihoming >> situation when all multihomed customer's needs in routing are covered by they >> upstream providers routing policies. In this situation more specific PA route >> can be originated by upstreams without allocation to customer new AS-num. >> Moreover, according to ripe-185: >> >> In order to help decrease global routing complexity, a new AS Number >> should be created only if a new routing policy is required. > >I didn't realize this, but I agree with Randy on this: without their >own AS number (and with them doing the BGP origination stuff and so >on), this isn't going to work anyway - if they do not want to do BGP, >then they should multi-home to the *same* ISP. Sorry, but this _is_ working with multi-homing on different ISPs: 1. They can build eBGP interoperation with their uplinks using private AS numbers. Uplinks can strip down private AS numbers from AS-path on uplink's AS boundaries ( Router(config)#router bgp YYYY Router(config-router)#nei X.X.X.X ? remove-private-AS Remove private AS number from outbound updates ). 2. They can build any kind of IGP with uplink. Each uplink redistribute they more specific network from appropriate IGP protocol to BGP. >[..] >> > - if one is filtering "no /24's", the end site is *still* be reachable, >> > which would not work with PI space. >> >> Disagree. During last time a number of routing curioses at least in our country >> have been caused by incorect announcements or filtering more specific routes >> within already announced less specific routes. If you want, I can describe some >> of the most common problems. PI addresses have its own set of problems, more >> specific PA addresses also have own set problems. This sets partly overlaps, >> but not same. And PA more specific isn't safer than PI. They just unsafe a bit >> more different. > >They will be much safer when people start filtering out "long prefixes". People have been filtering out "longer prefixes" for years. And /24 been (informal) longest _acceptable_ prefix for long time (just look at CIDR reports history). >Which will happen *soon*. One recomendation from one of our peers background: If you are going to filter prefixes based on prefix length _always_ filter it same on all sessions. Otherwise your chance to be affected by nasty routing loops will be very high. -- Regards, Vladimir. From he at uninett.no Tue Oct 9 17:31:56 2001 From: he at uninett.no (Havard Eidnes) Date: Tue, 09 Oct 2001 17:31:56 +0200 (CEST) Subject: automatic DB cleanup proposal In-Reply-To: <9050.1002623280@apnic.net> References: <200110081802.UAA15680@rocky.gatel.net> <9050.1002623280@apnic.net> Message-ID: <20011009.173156.61740677.he@uninett.no> > I think the base principles behind cleanups are great, and I intend > proposing APNIC explore a similar course of action to the manual > sweep. Indeed, I also applaud the initiative. > I am worried that there may be *external* referencees to objects, > and while we have no 'contractual' obligation it might not be nice > to do this to people without some engagement but I expect most > people would welcome losing a path to spam. I seem to recall statements to the effect that "the RIPE database is not a phone directory" from quite a while ago when the issue of the "dangling person" objects was discussed, indicating that the RIPE database should not be used in this manner. Regards, - H?vard From gert at space.net Tue Oct 9 17:35:43 2001 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2001 17:35:43 +0200 Subject: automatic DB cleanup proposal In-Reply-To: <200110081802.UAA15680@rocky.gatel.net>; from kieber@gatel.net on Mon, Oct 08, 2001 at 08:02:38PM +0200 References: <200110081802.UAA15680@rocky.gatel.net> Message-ID: <20011009173543.B16960@Space.Net> Hi, On Mon, Oct 08, 2001 at 08:02:38PM +0200, Ulf Kieber wrote: > following up to some personal talks during the RIPE meeting I propose > an automatic cleanup of orphaned person and role objects in the RIPE > DB. Proposal seconded, with the change discussed already (use the same time format as in "changed:"). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From bkrosnov at lirex.bg Tue Oct 9 16:45:42 2001 From: bkrosnov at lirex.bg (Boyan Krosnov) Date: Tue, 9 Oct 2001 17:45:42 +0300 Subject: more specific routes in today reality Message-ID: <3FAEA93E6179FA4FBB329456D0A9054A1E0EE1@tquila.lirex.com> Hi, There are other solutions for multihoming with NAT but I think we are again hitting that NAT against no NAT issue. I think that I should say it now to avoid further flamewars. NAT is not always a possible solution. It may be good to use it in some cases but it is not in others. Those other cases are the ones that this discussion is about. Or at least I think so :) CCNP Boyan Krosnov Network Administrator Lirex Net phone: +359-2-91815 > -----Original Message----- > From: Mirta Matic [mailto:mirta.matic at hinet.hr] > Sent: Tuesday, October 09, 2001 4:55 PM > To: Sascha E. Pollok > Cc: Gert Doering; Vladimir A. Jakovenko; lir-wg at ripe.net; > routing-wg at ripe.net > Subject: Re: more specific routes in today reality > > > Hello, > > have you ever heard for RADWARE solution for that problem? > Some RADWARE box can check distance to destination via both > ISP's and makes > decision from what IP address range have to get address for > NAT (of course, > customer have to have two ranges of addresses). If connection > via one ISP > failed, all traffic will be rerouted via another using IP > address from IP > address range of that ISP. > > Mirta Matic > mirta.matic at hinet.hr > > tel: +385 1 4914 207 > fax: +385 1 4914 222 From jan.czmok at jippiigroup.com Tue Oct 9 19:28:48 2001 From: jan.czmok at jippiigroup.com (Jan-Ahrent-Czmok) Date: Tue, 9 Oct 2001 19:28:48 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009131049.A60790@lucky.net> References: <20011009131049.A60790@lucky.net> Message-ID: <3BB9050D0006CB24@mail.epost.de> (added by postmaster@mail.epost.de) Hi, please allow me some comments as seen from a LIR member (de.jippii former de.ipf) and now from an external point of view (consulting company for isps and ripe members) > According to my observations at least since this summer the RIPE NCC staff > promotes usage of more specific PA routes (originated by more than one AS) > for multihomed customers opposite to the "classic" scheme with PI addresses > (or new enterpise LIR ;-). My observations show that RIPE NCC is quite able to judge it more or less efficiently. "More or Less" are defined as follows: - they take care about PA Assignments very well - they sometimes put too many questions for PA Space for bigger companies (like Banks, Cable Companies etc.) --> a seperate PA Proposal should be worked out how to handle with big multinational companies like banks or other companies. ARIN has dealt with a similar issue (but there we looking at CABLE Blocks) quite well - they are enforcing that every multihomed customer should be lir member(kind of) --> they shall create a new registry type called "multihomed but not isp" on which guidelines shall be established. this could solve some problems: - more direct contact between that customer <-> ripe - more "adress space clueness" at the customer side as past experience has shown, the isps are not 100% efficient in doing this; sorry. - would channelize the needs/wishes/possibilities from ripe and the customer. - would also cover some of the costs for running that kind of lir for ripe and generating more awareness at the "corporate" level. > In this situation we are going to expect increase of ammount of: > 1. Routes with more than one origin. > 2. Less specific routes within existing more specific. Which is REALLY bad, as seen from operator perspective, increasing the bloat of the routing table. > Actual (ripe-185) document of "IPv4 and ASN Policies in the RIPE NCC Service > Region" and working draft (on http://www.ripe.net/rs/ipv4policy.html) > refer to rfc1930 which contains section 7 - "One prefix, one origin AS": right. > Generally, a prefix can should belong to only one AS. This is a > direct consequence of the fact that at each point in the Internet > there can be exactly one routing policy for traffic destined to each > prefix. it SHOULD belong only to one as. Other things are bad ("inconsistent routes"). > According to measurements on RIPE DB dump on Oct 4 there were about 17% of > prefixes with more than on origin AS. It isn't just RIPE specific - > measurements from other IRRs are close. so this problem should be solved and addressed either with help of the IETF / IEPG and the LIR. > Just in fact there is still some network operators, > whose routing policy (in the part of BGP peers filtering) had been formed > by influence of rfc1930 and other aggregation issues, states something like > that: "if peer announces more specific routes within existent less specific > route, all more specific routes will be rejected unless peer explicity asks > to accept it". By also looking at the "old SWAMP" space we also should look more into this. we are not able (till now) to efficiently clean the swamp space. either RIPE (with the LIR) should find possible scenarios for this address space, either revoking it from the old users, forcing them to renumber to more clear address space. This would also help to eliminate MANY /24 or /23 out of the routing table. It CAN be done, but only policies need to be defined. If a user still would like to use it internally (for some purposes like products registered on ip addresses) then NAT can be used with help of the isp. But the swamp space needs to be cleaned up! > On my opinnion it would be also good to: > 1. Create new RIPE document which would describe usage of more specific > routes with multiple origins for multihoming, including all pros and > cons of such technique. ACKED. i'm happy to help with the creation of such document. > 2. Extend ripe-127 successor with references to new document mentioned > above or (why not?) integrate both of them in one document. > 3. Extend ripe-211 successor with something like that: > "Due to tendency of increasing number of small blocks (smaller than the default > allocation size) of PI or PA (more specific multihoming, load balancing, etc) > addresses network operators taking routing decisions based on prefix length are > recommended to accept and route longer (up to /24) prefixes with valid route > objects." Well, seeing the recent discussion on NANOG, there exists quite a lot of technology which does not need announced /24 for load balancing (like RAD products). Just my .2 euro-cents :-)) -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From gert at space.net Tue Oct 9 20:45:02 2001 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2001 20:45:02 +0200 Subject: more specific routes in today reality In-Reply-To: <3BB9050D0006CB24@mail.epost.de>; from jan.czmok@jippiigroup.com on Tue, Oct 09, 2001 at 07:28:48PM +0200 References: <20011009131049.A60790@lucky.net> <3BB9050D0006CB24@mail.epost.de> Message-ID: <20011009204502.G16960@Space.Net> Hi, On Tue, Oct 09, 2001 at 07:28:48PM +0200, Jan-Ahrent-Czmok wrote: > - they are enforcing that every multihomed customer should be lir member(kind of) > --> they shall create a new registry type called "multihomed but not isp" There is a LIR category, called "enterprise LIR". Which is exactly what this is: a LIR that is only serving itself. [..] > By also looking at the "old SWAMP" space we also should look more into this. > we are not able (till now) to efficiently clean the swamp space. either > RIPE (with the LIR) should find possible scenarios for this address space, either > revoking it from the old users, forcing them to renumber to more clear address > space. This is quite easy. Stop listening to it. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Tue Oct 9 21:29:54 2001 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2001 21:29:54 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009211305.26e5fcad.czmok@lambda-solutions.de>; from jan.czmok@jippiigroup.com on Tue, Oct 09, 2001 at 09:13:05PM +0200 References: <20011009131049.A60790@lucky.net> <3BB9050D0006CB24@mail.epost.de> <20011009204502.G16960@Space.Net> <20011009211305.26e5fcad.czmok@lambda-solutions.de> Message-ID: <20011009212954.K16960@Space.Net> Hi, On Tue, Oct 09, 2001 at 09:13:05PM +0200, Jan-Ahrent-Czmok wrote: > Some providers are multihomed > but cannot cover the costs, even for a small lir. If you want to be multihomed, the costs for routers & co. are far higher than for being LIR. If you can't afford being LIR, be single-homed. > >> By also looking at the "old SWAMP" space we also should look more into this. > > [...] > > > This is quite easy. Stop listening to it. > > This would dump the traffic to the owners of these blocks (e.g. AFAIK > xlink and RIPE) and SHOULD NOT be the correct way. Nonsense. Nobody is announcing 192.0.0.0/8, or supernets of other's networks - and what is in the RIPE database doesn't affect routing. To show the first few things from 192/8: *>i192.0.32.0 195.158.244.133 100 0 1755 1239 5676 226 i *>i192.0.34.0 195.158.244.133 100 0 1755 1239 5676 226 i * i192.0.36.0 195.206.66.61 3 100 0 3300 701 2914 20144 i *>i 195.158.244.133 100 0 1755 1239 2914 2014 4 i * i192.1.0.0/16 195.206.66.61 3 100 0 3300 701 1 i *>i 195.158.244.133 100 0 1755 1239 1 i * i192.2.0.0/16 195.206.66.61 3 100 0 3300 701 1 i *>i 195.158.244.133 100 0 1755 1239 1 i so if I filter those, why should the traffic go to XLink? Why should *any* traffic go to RIPE? It will be just blackholed (or default-routed to one of my upstreams, if I happen to have a default-route). Please do your homework about routing and BGP before selling people consulting about multihoming. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Wed Oct 10 00:21:09 2001 From: gert at space.net (Gert Doering) Date: Wed, 10 Oct 2001 00:21:09 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009231725.K2763@lucky.net>; from vovik@lucky.net on Tue, Oct 09, 2001 at 11:17:25PM +0300 References: <20011009131049.A60790@lucky.net> <3BB9050D0006CB24@mail.epost.de> <20011009204502.G16960@Space.Net> <20011009211305.26e5fcad.czmok@lambda-solutions.de> <20011009212954.K16960@Space.Net> <20011009231725.K2763@lucky.net> Message-ID: <20011010002109.L16960@Space.Net> Hi, On Tue, Oct 09, 2001 at 11:17:25PM +0300, Vladimir A. Jakovenko wrote: > >> Some providers are multihomed > >> but cannot cover the costs, even for a small lir. > >If you want to be multihomed, the costs for routers & co. are far higher > >than for being LIR. If you can't afford being LIR, be single-homed. > > Are you sure? Old BGP-capable Cisco routers (like 25xx), especialy from eBay > are very cheap. "Multihoming" with something less than full tables won't really solve anything - as "multihoming without an AS number", it's some weird thing that has its place, but doesn't buy you much in the long run. (As for your example with the IX - this could be done without globally visible space just fine, it's not "multihoming") Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Wed Oct 10 00:26:49 2001 From: gert at space.net (Gert Doering) Date: Wed, 10 Oct 2001 00:26:49 +0200 Subject: more specific routes in today reality In-Reply-To: ; from PLu@cw.net on Tue, Oct 09, 2001 at 04:38:36PM -0400 References: Message-ID: <20011010002649.N16960@Space.Net> Hi, On Tue, Oct 09, 2001 at 04:38:36PM -0400, Lu, Ping wrote: > > On Tue, Oct 09, 2001 at 09:13:05PM +0200, Jan-Ahrent-Czmok wrote: > > > Some providers are multihomed > > > but cannot cover the costs, even for a small lir. > > > > If you want to be multihomed, the costs for routers & co. are > > far higher > > than for being LIR. If you can't afford being LIR, be single-homed. > > > > Great! Now we have to collect routing policies from thousands of small LIRs > while still have to deal with thousands of small prefixes. So? There is no difference between thousands of PI prefixes and "thousands of small LIRs", except that the latter actually have to *pay* for what they cause. [..] > > Please do your homework about routing and BGP before selling people > > consulting about multihoming. > > Now more and more major ISPs are filtering out routes from other ISPs ( > becuase we don't have > transit agreements) so the multi-homed customer have to have their own AS. No. This is an interesting arguments, but the fact that C&W has problems with some of their peers doesn't mean "the whole world has to drown in multihomed ASes". Get your contracts right. > And if the major ISPs stop listening to the more specfic routes then even > using the address from PI space won't work (unless you are big enough). Yes. This is what it's all about. Small PI space really hurts people. > All these solutions kind of imply that if you can't have /20 prefix then you > can't be multi-homed. What happen if a customer want to have an OC-48 > multi-homed link but only use prefix < /20 (that happens to the Internet > Exchange people a lot ) ? So announce it to the internet exchange. Why does it have to be visible in the whole world? Letting "the whole world" see a /16 (from the upstream) and the direct peers a /24 (or whatever) means global routing will just work fine (over the upstream's PA block) and and IX routing will also work just fine (using the more specific). Bad example. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Wed Oct 10 00:31:39 2001 From: gert at space.net (Gert Doering) Date: Wed, 10 Oct 2001 00:31:39 +0200 Subject: more specific routes in today reality In-Reply-To: ; from aledm@qix.co.uk on Tue, Oct 09, 2001 at 10:00:37PM +0100 References: <20011009231725.K2763@lucky.net> Message-ID: <20011010003139.O16960@Space.Net> Hi, On Tue, Oct 09, 2001 at 10:00:37PM +0100, Aled Morris wrote: > On Tue, Oct 09, 2001 at 09:29:54PM +0200, Gert Doering wrote: > >If you want to be multihomed, the costs for routers & co. are far higher > >than for being LIR. If you can't afford being LIR, be single-homed. > > Surely there is more to being a LIR than simply as a way of buying a /20 > for multihoming! Yes. > RIPE is effectively a member-run organisation; being an LIR means taking > part responsibility and getting involved via the working groups. Yes. > The argument "buying the RIPE membership is cheaper than the router you > need to run full BGP" basically sends a message that anyone with enough > money can buy their own /20 and AS number without having to justify how > they will use the address space, and without any obligation to the > Internet community at large. Which is not the way it should be (and it is not, according to policies), but you're twisting my sentence without quoting the statement above. Jan was complaining that it's too expensive to become a LIR. I put that cost into relation to the cost people have to pay anyway if they want to do *proper* multihoming, or put more precisely, be part of the default-free zone. And compared to that cost, becoming a LIR should be the least of your worries. I do not advocate that everybody that wants to have globally visible address space become a LIR. It is one way, for ISPs it's a good way (because it means you can handle address requirements of your customers in a practical and direct way), but for other entities it might be the wrong way. But *costs* are not a good criterium to decide that. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From huberman at gblx.net Wed Oct 10 00:54:06 2001 From: huberman at gblx.net (David R Huberman) Date: Tue, 9 Oct 2001 15:54:06 -0700 (MST) Subject: more specific routes in today reality In-Reply-To: <20011010003139.O16960@Space.Net> Message-ID: > Jan was complaining that it's too expensive to become a LIR. I put > that cost into relation to the cost people have to pay anyway if they > want to do *proper* multihoming, or put more precisely, be part of the > default-free zone. And compared to that cost, becoming a LIR should be > the least of your worries. .and as a brief sidenote: the ARIN community discussed the high entry level fee as an effective barrier to entry for obtaining globally unique prefixes. It was discussed that such a high cost helped protect the global routing table from "contamination" by those with no bona fide engineering goals and/or questionable motivations for injecting further routes. /david From vovik at lucky.net Tue Oct 9 20:41:58 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Oct 2001 21:41:58 +0300 Subject: more specific routes in today reality In-Reply-To: ; from randy@psg.com on Tue, Oct 09, 2001 at 07:19:35AM -0700 References: <20011009131049.A60790@lucky.net> <20011009121557.C16960@Space.Net> <20011009160208.D2763@lucky.net> Message-ID: <20011009214158.I2763@lucky.net> On Tue, Oct 09, 2001 at 07:19:35AM -0700, Randy Bush wrote: >> We are talking about different types of multihoming. I mean simple >> multihoming situation when all multihomed customer's needs in routing are >> covered by they upstream providers routing policies. > ^ >note the use of plural above. now read rfc 1930. Randy, rfc1930 consists of 563 lines. I suppose you are talking about: line 287: * Unique routing policy An AS is only needed when you have a routing policy which is different from that of your border gateway peers. Here routing policy refers to how the rest of the Internet makes routing decisions based on information from your AS. See "Sample Cases" below to see exactly when this criteria will apply. line 323: * Multi-homed site Here multi-homed is taken to mean a prefix or group of prefixes which connects to more than one service provider (i.e. more than one AS with its own routing policy). It does not mean a network multi-homed running an IGP for the purposes of resilience. An AS is required; the site's prefixes should be part of a single AS, distinct from the ASes of its service providers. This allows the customer the ability to have a different repre- sentation of policy and preference among the different service providers. This is ALMOST THE ONLY case where a network operator should create its own AS number. In this case, the site should ensure that it has the necessary facilities to run appropriate routing protocols, such as BGP4. Also I think we should pay attention to rfc1930 header: line 10: Category: Best Current Practice line 11: March 1996 line 14: Guidelines for creation, selection, and registration of an Autonomous System (AS) Lets make some logick based on hypotetical situation with ISP (LIR) Network Engineer, Regional Internet Registry and the customer. ISP customer wants to be multihomed mostly for the following reason - resilience in the case of upstream failure (for my experience - on of the most common reasons). Yes, customer already tried to change: - ISP, - equipment, - technical staff. But hadn't reached enough resilience level. They technical and marketing staff considered that without multihoming they can't achieve sufficient resilience level. They don't ready to pay for Enterprise LIR because they know about PI. They asked ISP to help them to obtain PI block and AS num. With ISP Network Engineer assistance they filled in ripe-219. Network Engineer sent it to Regional Internet Registry. After some amount of time Regional Internet Registry staff replied to original request with something like: "They are aware that they can be multihomed with only PA space? Two or more LIRs can announce these address spaces if you discuss it with them, they don't even need an AS number. I don't quite understand why they feel the need to have PI space and all the problems that this will cause them. In addition if they ever have plans to expand in the future and need more address space they are going to have more trouble. I would suggest that you discuss this with them to see if they still want PI space. Finally, we are strict regarding the actual amounts of address space that customers request as there is a tendency to ask for more than is actually required, due to their agregation concerns." Lets imagine, that all customer uplinks are not against from such solution (there isn't any public IX-es, Telecom's, etc). After that please take a look at quoted lines from rfc1930. Who is reponsible for IP address space and AS-num allocation in LIR geographical region? RIR. If - RIR decided that multihomed customer (generaly) don't need separate AS-num - RIR routing database contains 17% of route objects with more than one origin (while rfc1930 defines it as exceptions) should Network Engineer think that: 1. Covered in rfc1930 "Best Practice" is a little bit outdated? 2. Meanings of "Multi-homed site", "Unique routing policy" and "resilenece" terms had been changed since 1996? 3. Something else? -- Regards, Vladimir. From jan.czmok at jippiigroup.com Tue Oct 9 21:13:05 2001 From: jan.czmok at jippiigroup.com (Jan-Ahrent-Czmok) Date: Tue, 9 Oct 2001 21:13:05 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009204502.G16960@Space.Net> References: <20011009131049.A60790@lucky.net> <3BB9050D0006CB24@mail.epost.de> <20011009204502.G16960@Space.Net> Message-ID: <20011009211305.26e5fcad.czmok@lambda-solutions.de> On Tue, 9 Oct 2001 20:45:02 +0200 Gert Doering wrote: > Hi, > On Tue, Oct 09, 2001 at 07:28:48PM +0200, Jan-Ahrent-Czmok wrote: >> - they are enforcing that every multihomed customer should be lir member(kind of) >> --> they shall create a new registry type called "multihomed but not isp" > There is a LIR category, called "enterprise LIR". Which is exactly what > this is: a LIR that is only serving itself. Gerd, enterprise LIR would only cover the enterprises and banks, but not the small isp and cor- porations which are multihomed. enterpreise LIR is, AFAIK, also more expensive than small lir. Some providers are multihomed but cannot cover the costs, even for a small lir. >> By also looking at the "old SWAMP" space we also should look more into this. [...] > This is quite easy. Stop listening to it. This would dump the traffic to the owners of these blocks (e.g. AFAIK xlink and RIPE) and SHOULD NOT be the correct way. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From vovik at lucky.net Tue Oct 9 22:17:25 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Oct 2001 23:17:25 +0300 Subject: more specific routes in today reality In-Reply-To: <20011009212954.K16960@Space.Net>; from gert@Space.Net on Tue, Oct 09, 2001 at 09:29:54PM +0200 References: <20011009131049.A60790@lucky.net> <3BB9050D0006CB24@mail.epost.de> <20011009204502.G16960@Space.Net> <20011009211305.26e5fcad.czmok@lambda-solutions.de> <20011009212954.K16960@Space.Net> Message-ID: <20011009231725.K2763@lucky.net> On Tue, Oct 09, 2001 at 09:29:54PM +0200, Gert Doering wrote: >Hi, > >On Tue, Oct 09, 2001 at 09:13:05PM +0200, Jan-Ahrent-Czmok wrote: >> Some providers are multihomed >> but cannot cover the costs, even for a small lir. > >If you want to be multihomed, the costs for routers & co. are far higher >than for being LIR. If you can't afford being LIR, be single-homed. Are you sure? Old BGP-capable Cisco routers (like 25xx), especialy from eBay are very cheap. Also pls do not forget about PC+Unix+zebra/gated/etc solutions. They are still on the market. As example - we have one "multihomed" (PI /23) customer with 64K external uplink and 10Mb connection to local IX. -- Regards, Vladimir. From jan.czmok at jippiigroup.com Tue Oct 9 22:26:14 2001 From: jan.czmok at jippiigroup.com (Jan-Ahrent-Czmok) Date: Tue, 9 Oct 2001 22:26:14 +0200 Subject: more specific routes in today reality In-Reply-To: <20011009212954.K16960@Space.Net> References: <20011009131049.A60790@lucky.net> <3BB9050D0006CB24@mail.epost.de> <20011009204502.G16960@Space.Net> <20011009211305.26e5fcad.czmok@lambda-solutions.de> <20011009212954.K16960@Space.Net> Message-ID: <20011009222614.6762f607.czmok@lambda-solutions.de> On Tue, 9 Oct 2001 21:29:54 +0200 Gert Doering wrote: > Hi, > On Tue, Oct 09, 2001 at 09:13:05PM +0200, Jan-Ahrent-Czmok wrote: >> Some providers are multihomed >> but cannot cover the costs, even for a small lir. > If you want to be multihomed, the costs for routers & co. are far higher > than for being LIR. If you can't afford being LIR, be single-homed. Sure ? Small providers tend to use open source software (like zebra) and have 2 x 10 or 2 x 100 Mbit/s to different providers, so your argument is not really true. But i understand your intentions, seen from provider perspective are right. > Nonsense. Nobody is announcing 192.0.0.0/8, or supernets of other's > networks - and what is in the RIPE database doesn't affect routing. I am not referring to 192.0.0.0/8, but in this case, we shall include an option to return old swamp space to their respective registry and issue address space from ripe. > so if I filter those, why should the traffic go to XLink? Why should > *any* traffic go to RIPE? It will be just blackholed (or default-routed > to one of my upstreams, if I happen to have a default-route). "if" you have a default route. Default route if multi-homed is surely bad IMHO. > Please do your homework about routing and BGP before selling people > consulting about multihoming. Ehm. IMHO, personal comments should be kept off-list. I am quite familiar with routing, BGP (and not just the usual i-know-routing-from-halabi lecture). I am currently finishing my CCIE. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From PLu at cw.net Tue Oct 9 22:38:36 2001 From: PLu at cw.net (Lu, Ping) Date: Tue, 9 Oct 2001 16:38:36 -0400 Subject: more specific routes in today reality Message-ID: Comments followed. > > Hi, > > On Tue, Oct 09, 2001 at 09:13:05PM +0200, Jan-Ahrent-Czmok wrote: > > Some providers are multihomed > > but cannot cover the costs, even for a small lir. > > If you want to be multihomed, the costs for routers & co. are > far higher > than for being LIR. If you can't afford being LIR, be single-homed. > Great! Now we have to collect routing policies from thousands of small LIRs while still have to deal with thousands of small prefixes. > > Nonsense. Nobody is announcing 192.0.0.0/8, or supernets of other's > networks - and what is in the RIPE database doesn't affect routing. > > To show the first few things from 192/8: > > *>i192.0.32.0 195.158.244.133 100 0 > 1755 1239 5676 226 > i > *>i192.0.34.0 195.158.244.133 100 0 > 1755 1239 5676 226 > i > * i192.0.36.0 195.206.66.61 3 100 0 > 3300 701 2914 20144 > i > *>i 195.158.244.133 100 0 > 1755 1239 2914 2014 > 4 i > * i192.1.0.0/16 195.206.66.61 3 100 0 > 3300 701 1 i > *>i 195.158.244.133 100 0 > 1755 1239 1 i > * i192.2.0.0/16 195.206.66.61 3 100 0 > 3300 701 1 i > *>i 195.158.244.133 100 0 > 1755 1239 1 i > > so if I filter those, why should the traffic go to XLink? > Why should > *any* traffic go to RIPE? It will be just blackholed (or > default-routed > to one of my upstreams, if I happen to have a default-route). > > Please do your homework about routing and BGP before selling people > consulting about multihoming. > Now more and more major ISPs are filtering out routes from other ISPs ( becuase we don't have transit agreements) so the multi-homed customer have to have their own AS. And if the major ISPs stop listening to the more specfic routes then even using the address from PI space won't work (unless you are big enough). All these solutions kind of imply that if you can't have /20 prefix then you can't be multi-homed. What happen if a customer want to have an OC-48 multi-homed link but only use prefix < /20 (that happens to the Internet Exchange people a lot ) ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From Robert.Kiessling at de.easynet.net Tue Oct 9 22:51:31 2001 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: Tue, 9 Oct 2001 22:51:31 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: <20011009222614.6762f607.czmok@lambda-solutions.de> References: <20011009131049.A60790@lucky.net> <3BB9050D0006CB24@mail.epost.de> <20011009204502.G16960@Space.Net> <20011009211305.26e5fcad.czmok@lambda-solutions.de> <20011009212954.K16960@Space.Net> <20011009222614.6762f607.czmok@lambda-solutions.de> Message-ID: <15299.25427.280580.480440@doncamillo.local.easynet.de> Jan-Ahrent-Czmok writes: > I am not referring to 192.0.0.0/8, but in this case, we shall include an > option to return old swamp space to their respective registry and issue > address space from ripe. So what are you refering to? Please name examples of your wild claim: | This would dump the traffic to the owners of these blocks (e.g. AFAIK | xlink and RIPE) and SHOULD NOT be the correct way. In particular: - In which way is XLink special so that by dropping /24 routes, they would receive non-customer traffic? - RIPE announces exactly 193.0.0.0/21. So how would traffic magically end up at RIPE if you applied strict filters? > > so if I filter those, why should the traffic go to XLink? Why should > > *any* traffic go to RIPE? It will be just blackholed (or default-routed > > to one of my upstreams, if I happen to have a default-route). > > "if" you have a default route. Default route if multi-homed is surely bad IMHO. Nonsense again. Traffic will be blackholed only if you have *no* default route. Robert From czmok at lambda-solutions.de Tue Oct 9 23:02:50 2001 From: czmok at lambda-solutions.de (Jan-Ahrent Czmok) Date: Tue, 9 Oct 2001 23:02:50 +0200 Subject: more specific routes in today reality In-Reply-To: References: Message-ID: <20011009230250.46f7d386.czmok@lambda-solutions.de> On Tue, 9 Oct 2001 16:38:36 -0400 "Lu, Ping" wrote: [..snip..] > Great! Now we have to collect routing policies from thousands of small LIRs > while still > have to deal with thousands of small prefixes. This is what i meant: if we "renumber" the old swamp space not only in RIPE Region, we have a cleaner routing table. many of the old swamp space "owners" are single homed, which would clean up a lot in the routing table if they are forced to use PA space from the respective provider. > And if the major ISPs stop listening to the more specfic routes then even > using the address from PI space won't work (unless you are big enough). Right, see my above comment. > All these solutions kind of imply that if you can't have /20 prefix then you > can't be multi-homed. What happen if a customer want to have an OC-48 > multi-homed link but only use prefix < /20 (that happens to the Internet > Exchange people a lot ) ? There should be also made some "golden networks" for the exchanges and "important" services, like DNS. This, correctly implemented together with the vendors, could make live easier: - route flap dampening works together seamless with the correct networks in "default" configurations. - more stability - less routes in routing table - clear "border" of address space together with registry borders. But again, these are only ideas from network operators. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From aledm at qix.co.uk Tue Oct 9 23:00:37 2001 From: aledm at qix.co.uk (Aled Morris) Date: Tue, 9 Oct 2001 22:00:37 +0100 (BST) Subject: more specific routes in today reality In-Reply-To: <20011009231725.K2763@lucky.net> Message-ID: On Tue, Oct 09, 2001 at 09:29:54PM +0200, Gert Doering wrote: > >If you want to be multihomed, the costs for routers & co. are far higher >than for being LIR. If you can't afford being LIR, be single-homed. Surely there is more to being a LIR than simply as a way of buying a /20 for multihoming! RIPE is effectively a member-run organisation; being an LIR means taking part responsibility and getting involved via the working groups. The argument "buying the RIPE membership is cheaper than the router you need to run full BGP" basically sends a message that anyone with enough money can buy their own /20 and AS number without having to justify how they will use the address space, and without any obligation to the Internet community at large. Aled From czmok at lambda-solutions.de Tue Oct 9 23:27:02 2001 From: czmok at lambda-solutions.de (Jan-Ahrent Czmok) Date: Tue, 9 Oct 2001 23:27:02 +0200 Subject: more specific routes in today reality In-Reply-To: <15299.25427.280580.480440@doncamillo.local.easynet.de> References: <20011009131049.A60790@lucky.net> <3BB9050D0006CB24@mail.epost.de> <20011009204502.G16960@Space.Net> <20011009211305.26e5fcad.czmok@lambda-solutions.de> <20011009212954.K16960@Space.Net> <20011009222614.6762f607.czmok@lambda-solutions.de> <15299.25427.280580.480440@doncamillo.local.easynet.de> Message-ID: <20011009232702.22263694.czmok@lambda-solutions.de> On Tue, 9 Oct 2001 22:51:31 +0200 (MEST) Robert Kiessling wrote: > Jan-Ahrent-Czmok writes: >> I am not referring to 192.0.0.0/8, but in this case, we shall include an >> option to return old swamp space to their respective registry and issue >> address space from ripe. > So what are you refering to? Please name examples of your wild claim: Okay, let's see if i find it: 192.124.115.0/24 == weblease AG, old address space from pre-ARIN, region should be ARIN/USA, is used in DE (okay -- no direct /16 or smaller announcement), but an example of the bad usage in the swamp space. inetnum: 194.13.111.0 - 194.13.111.255 route-server>sh ip bgp 194.13.111.0/24 shorter-prefixes * 194.13.0.0/17 12.123.25.245 0 7018 3549 1103 1103 i > In particular: > - In which way is XLink special so that by dropping /24 routes, they > would receive non-customer traffic? xlink used to keep some of the old swamp space overtook from uni karlsruhe > - RIPE announces exactly 193.0.0.0/21. So how would traffic magically > end up at RIPE if you applied strict filters? i am NOT referring to RIPE announced routes. >> > so if I filter those, why should the traffic go to XLink? Why should >> > *any* traffic go to RIPE? It will be just blackholed (or default-routed >> > to one of my upstreams, if I happen to have a default-route). >> >> "if" you have a default route. Default route if multi-homed is surely bad IMHO. > Nonsense again. Traffic will be blackholed only if you have *no* > default route. If you have a default route when multihomed, you create routing loops, when not filtering at both ends of the "transits". This created nice loops :-(( --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From sabri at bit.nl Tue Oct 9 23:30:47 2001 From: sabri at bit.nl (Sabri Berisha) Date: Tue, 9 Oct 2001 23:30:47 +0200 (CEST) Subject: more specific routes in today reality In-Reply-To: <20011009222614.6762f607.czmok@lambda-solutions.de> Message-ID: On Tue, 9 Oct 2001, Jan-Ahrent-Czmok wrote: > "if" you have a default route. Default route if multi-homed is surely > bad IMHO. Not necessarily. If you are multi-homed for redundancy reasons and have a small linux box with zebra your memory would be exhausted carrying to full route feeds. Two single default routes are far more efficient: at home I have cable and dsl. I have 2 tunnels to two different routers of my work. Over those tunnels I announce a /28 (which is aggregated to a /19) and receive two default routes. My dsl is faster so that has a higher local pref. If that goes down, the route switches over to the cable tunnel. -- Sabri Berisha ~~ my own opinions etc ~ From fredrik at sunet.se Tue Oct 9 23:41:48 2001 From: fredrik at sunet.se (Fredrik Widell) Date: Tue, 9 Oct 2001 23:41:48 +0200 (CEST) Subject: more specific routes in today reality In-Reply-To: Message-ID: On Tue, 9 Oct 2001, Sabri Berisha wrote: > On Tue, 9 Oct 2001, Jan-Ahrent-Czmok wrote: > > > "if" you have a default route. Default route if multi-homed is surely > > bad IMHO. > > Not necessarily. If you are multi-homed for redundancy reasons and have a > small linux box with zebra your memory would be exhausted carrying to full > route feeds. Two single default routes are far more efficient: at home I Well, not exactly, 128 Meg can carry 2 full feeds, triple that and you have no worries. > have cable and dsl. I have 2 tunnels to two different routers of my > work. Over those tunnels I announce a /28 (which is aggregated to a /19) > and receive two default routes. My dsl is faster so that has a higher > local pref. If that goes down, the route switches over to the cable > tunnel. > > -- Regards /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 ------------------------------------------------------- From czmok at lambda-solutions.de Wed Oct 10 00:02:07 2001 From: czmok at lambda-solutions.de (Jan-Ahrent Czmok) Date: Wed, 10 Oct 2001 00:02:07 +0200 Subject: more specific routes in today reality In-Reply-To: References: <20011009222614.6762f607.czmok@lambda-solutions.de> Message-ID: <20011010000207.287122c6.czmok@lambda-solutions.de> On Tue, 9 Oct 2001 23:30:47 +0200 (CEST) Sabri Berisha wrote: > On Tue, 9 Oct 2001, Jan-Ahrent-Czmok wrote: >> "if" you have a default route. Default route if multi-homed is surely >> bad IMHO. > Not necessarily. If you are multi-homed for redundancy reasons and have a > small linux box with zebra your memory would be exhausted carrying to full > route feeds. Two single default routes are far more efficient: at home I > have cable and dsl. I have 2 tunnels to two different routers of my > work. Over those tunnels I announce a /28 (which is aggregated to a /19) > and receive two default routes. My dsl is faster so that has a higher > local pref. If that goes down, the route switches over to the cable > tunnel. Well. I ACK your specific implementation. We are talking not about the small home user (or small business user). We are referring to ISP implementations here. In these ISP cases, when multihomed the "default route" is not a good idea, because of the danger of routing loops. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From czmok at lambda-solutions.de Wed Oct 10 01:22:31 2001 From: czmok at lambda-solutions.de (Jan-Ahrent Czmok) Date: Wed, 10 Oct 2001 01:22:31 +0200 Subject: more specific routes in today reality In-Reply-To: <20011010002109.L16960@Space.Net> References: <20011009131049.A60790@lucky.net> <3BB9050D0006CB24@mail.epost.de> <20011009204502.G16960@Space.Net> <20011009211305.26e5fcad.czmok@lambda-solutions.de> <20011009212954.K16960@Space.Net> <20011009231725.K2763@lucky.net> <20011010002109.L16960@Space.Net> Message-ID: <20011010012231.1a5c09a7.czmok@lambda-solutions.de> On Wed, 10 Oct 2001 00:21:09 +0200 Gert Doering wrote: > "Multihoming" with something less than full tables won't really solve > anything Right. - as "multihoming without an AS number", it's some weird thing > that has its place, but doesn't buy you much in the long run. well. multihoming with private AS also could work. Combined with Conditional Announcement, it's a really useful possibility. > (As for your example with the IX - this could be done without globally > visible space just fine, it's not "multihoming") Well. IX space & DNS space is "IMHO" a special case which cannot be used on corporate or business isp. We need some clean-up in the "special" cases. Swamp Space, pre-RIR phases and more... When we cannot clean up the "swamp" from the past, can we do clean work in the future ? jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From czmok at lambda-solutions.de Wed Oct 10 01:27:06 2001 From: czmok at lambda-solutions.de (Jan-Ahrent Czmok) Date: Wed, 10 Oct 2001 01:27:06 +0200 Subject: more specific routes in today reality In-Reply-To: <20011010002649.N16960@Space.Net> References: <20011010002649.N16960@Space.Net> Message-ID: <20011010012706.280c2871.czmok@lambda-solutions.de> >> >> Great! Now we have to collect routing policies from thousands of small LIRs >> while still have to deal with thousands of small prefixes. > So? There is no difference between thousands of PI prefixes and > "thousands of small LIRs", except that the latter actually have to > *pay* for what they cause. Right. Strong ACK on this. >> And if the major ISPs stop listening to the more specfic routes then even >> using the address from PI space won't work (unless you are big enough). > Yes. This is what it's all about. Small PI space really hurts people. Yep. And therefore these "small" PI stuff should be cleaned up. The User itself can use it internally and could get a /24 routed from PA space. But it is really not the optimum solution, as it waste's ip address space. And we have enough RFC1918 space... > Letting "the whole world" see a /16 (from the upstream) and the direct > peers a /24 (or whatever) means global routing will just work fine (over > the upstream's PA block) and and IX routing will also work just fine > (using the more specific). right, but is it generally used ? I see a lot of /24 out of the same block from a /16 announced space globally (AS5511 for example) --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From czmok at lambda-solutions.de Wed Oct 10 01:32:31 2001 From: czmok at lambda-solutions.de (Jan-Ahrent Czmok) Date: Wed, 10 Oct 2001 01:32:31 +0200 Subject: more specific routes in today reality In-Reply-To: <20011010003139.O16960@Space.Net> References: <20011009231725.K2763@lucky.net> <20011010003139.O16960@Space.Net> Message-ID: <20011010013231.1717089c.czmok@lambda-solutions.de> On Wed, 10 Oct 2001 00:31:39 +0200 Gert Doering wrote: (..snip..) > Jan was complaining that it's too expensive to become a LIR. I put > that cost into relation to the cost people have to pay anyway if they > want to do *proper* multihoming, or put more precisely, be part of the > default-free zone. And compared to that cost, becoming a LIR should be > the least of your worries. Well. Forcing PI owners to get involved within the RIPE would help all. Even sharing their experience (from business view) and teaching them (through ripe meetings & courses etc) would help everybody. And a "PI LIR" (NOT enterprise LIR) would bring some money back to RIPE helping the community as a whole. > I do not advocate that everybody that wants to have globally visible > address space become a LIR. It is one way, for ISPs it's a good way > (because it means you can handle address requirements of your > customers in a practical and direct way), but for other entities it > might be the wrong way. But *costs* are not a good criterium to > decide that. ACK, but it would solve a lot of problems. Solutions are not always good for all, but for most of all. Gerd, i think we should work more close together on this issue to address some of the issues as a draft to ripe. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From PLu at cw.net Wed Oct 10 06:51:37 2001 From: PLu at cw.net (Lu, Ping) Date: Wed, 10 Oct 2001 00:51:37 -0400 Subject: more specific routes in today reality Message-ID: > > > > Great! Now we have to collect routing policies from > thousands of small LIRs > > while still have to deal with thousands of small prefixes. > > So? There is no difference between thousands of PI prefixes and > "thousands of small LIRs", except that the latter actually have to > *pay* for what they cause. To syncronize between the major RIRs is already dufficult enough, to make sure thousands of small LIRs all have correct info is not worth the problem it is trying to solve. > > > > Now more and more major ISPs are filtering out routes from > other ISPs ( > > becuase we don't have > > transit agreements) so the multi-homed customer have to > have their own AS. > > No. This is an interesting arguments, but the fact that C&W > has problems > with some of their peers doesn't mean "the whole world has to drown in > multihomed ASes". Get your contracts right. > Maybe you will carry other ISP's transit routes and they can dump about several GB of traffic for you to pass thru. And you are asking ISP to spend tons of money to carry the traffic that other ISPs are making money of ? Compared to this solution I think multihomed ASes is more acceptable. > > And if the major ISPs stop listening to the more specfic > routes then even > > using the address from PI space won't work (unless you are > big enough). > > Yes. This is what it's all about. Small PI space really > hurts people. > The thing is any ISP can decide to only accept /20 and above and claim any routes beyond those are not important. The truth is the INTERNET is bandwidth oriented and business like IX and webhosting are high bandwidth but not prefixes hungry. But they are hurting because someone think they are not wasting IP addresses enough. So the advice is if for any reason you need a backup link from different ISPs you better claim a /20 even a /24 is enough. > > All these solutions kind of imply that if you can't have > /20 prefix then you > > can't be multi-homed. What happen if a customer want to > have an OC-48 > > multi-homed link but only use prefix < /20 (that happens to > the Internet > > Exchange people a lot ) ? > > So announce it to the internet exchange. Why does it have to > be visible > in the whole world? > > Letting "the whole world" see a /16 (from the upstream) and the direct > peers a /24 (or whatever) means global routing will just work > fine (over > the upstream's PA block) and and IX routing will also work just fine > (using the more specific). > > Bad example. > So if a end-user uses one ISP's /24 from their PA space and he want to divide 50-50 traffic with a second ISP then what ? The second ISP will say no /24 allowed so can you ask the first ISP to assign a /20 ? (Don't worry CW will happily accept your /24) Even worse example. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From PLu at cw.net Wed Oct 10 07:44:43 2001 From: PLu at cw.net (Lu, Ping) Date: Wed, 10 Oct 2001 01:44:43 -0400 Subject: more specific routes in today reality Message-ID: > > >> > >> Great! Now we have to collect routing policies from > thousands of small LIRs > >> while still have to deal with thousands of small prefixes. > > > So? There is no difference between thousands of PI prefixes and > > "thousands of small LIRs", except that the latter actually have to > > *pay* for what they cause. > > Right. Strong ACK on this. > So what do the small LIRs solve ? > >> And if the major ISPs stop listening to the more specfic > routes then even > >> using the address from PI space won't work (unless you are > big enough). > > > Yes. This is what it's all about. Small PI space really > hurts people. > > Yep. And therefore these "small" PI stuff should be cleaned > up. The User itself > can use it internally and could get a /24 routed from PA space. > > But it is really not the optimum solution, as it waste's ip > address space. And > we have enough RFC1918 space... > This is not enough but I am going to go with this solution. Then we will ask you to assign only aggregatable address( to a /20 of course) to your customer if they are going to use CW as a backup ISP. You will happily reassign their addresses once they got a link from CW, right ? If you don't then what ? CW will have to leak your /24 to the world but it is you causing it. On the other hand, if our customer ask you to be the backup ISP, we will ask them to change all their DNS records, all their host tables, all their static IP configs to change to the new aggregatable block. If they think this is too much hassle, we will advice them not to use your service because you don't accept /24 multi-homed customer. This sounds realistic enough ? > > Letting "the whole world" see a /16 (from the upstream) and > the direct > > peers a /24 (or whatever) means global routing will just > work fine (over > > the upstream's PA block) and and IX routing will also work just fine > > (using the more specific). > > right, but is it generally used ? > I see a lot of /24 out of the same block from a /16 announced > space globally > (AS5511 for example) > > Because it is not the solution to the real world, that's why people can only talk about it but not really to enforce it. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From djp-ripe-lists at djp.net Wed Oct 10 11:39:19 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Wed, 10 Oct 2001 11:39:19 +0200 (CEST) Subject: Multihoming - Resilience or Independence Message-ID: Hiya All, There has recently been a long thread, getting rather technical, about how best to achieve multihoming with the best resilience, etc. However, I feel there is another perhaps stronger argument as to why a customer wishes to obtain, keep and announce his own prefix(es): Bandwidth costs are reducing rapidly and customers do not wish to be tied to a single provider because of the pain associated with renumbering their address space. Going through the hoops to achieve multihoming may not improve resilience but, especially if they are "slow" setting up the second connection, the bandwidth can be cheaper as the customer can change ISPs much more easily if the price stays too high. It would be interesting to know which fraction of the "unclean" address space is singly connected. Our customer base may be unusual, but over 50% would not suprise me. Cheers Dave ps. Do not let any customers see this email..... :-) From kurtis at kpnqwest.net Wed Oct 10 10:54:22 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Wed, 10 Oct 2001 10:54:22 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: <20011009214158.I2763@lucky.net> Message-ID: > But hadn't reached enough resilience level. They technical and marketing staff > considered that without multihoming they can't achieve sufficient resilience > level. They don't ready to pay for Enterprise LIR because they know about PI. > They asked ISP to help them to obtain PI block and AS num. With ISP Network > Engineer assistance they filled in ripe-219. Network Engineer sent it to > Regional Internet Registry. I have a feeling that we are trying to solve the poor performance of some players in this business with addressing policy. The easiest and best way for a customer to get resiliency is a) Get a provider that is a Tier-1 or have multiple upstreams b) Make sure you provider have a resilient network c) Get dual (really) connections to your provider. I assure you this will be cheaper than to get your own address space, LIR status, and God knows what. If a provider can't supply the above to a customer that really have the need for multiple connections and is willing to pay for it, I would change provider anyay. - kurtis - From kurtis at kpnqwest.net Wed Oct 10 10:58:55 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Wed, 10 Oct 2001 10:58:55 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: <20011009222614.6762f607.czmok@lambda-solutions.de> Message-ID: > > If you want to be multihomed, the costs for routers & co. are far higher > > than for being LIR. If you can't afford being LIR, be single-homed. > > Sure ? Small providers tend to use open source software (like zebra) > and have 2 x 10 or 2 x 100 Mbit/s to different providers, so your > argument is not really true. But i understand your intentions, seen from > provider perspective are right. I think there are customers who have the need for redundancy but, not the need for a LIR. Actually a LIR is only needed if you have large amounts of address space to manage. That is at least always the way I have looked at LIRs. They have nothing to do with the routing policy. Now, you can have a small amount of address space, but sill have the need for resilience/redundancy/multiple uplinks. - kurtis - From arnold at nipper.de Wed Oct 10 12:04:23 2001 From: arnold at nipper.de (Nipper, Arnold) Date: Wed, 10 Oct 2001 12:04:23 +0200 Subject: Multihoming - Resilience or Independence References: Message-ID: <018801c15172$f139c060$0390a8c0@nipper.de> Hi dave, hi all, > Hiya All, > > There has recently been a long thread, getting rather technical, about how > best to achieve multihoming with the best resilience, etc. > > However, I feel there is another perhaps stronger argument as to why a > customer wishes to obtain, keep and announce his own prefix(es): > there are a lot of reasons why customers want to be multi-homed. And what I'm seeing here is, that the ISP community is not able to offer such a service. But instead of blaming the "stupid" customers, ISP should go home and make their homework. -- Arnold From gert at space.net Wed Oct 10 12:58:03 2001 From: gert at space.net (Gert Doering) Date: Wed, 10 Oct 2001 12:58:03 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <020201c15179$ae22e660$0390a8c0@nipper.de>; from arnold@nipper.de on Wed, Oct 10, 2001 at 12:52:37PM +0200 References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> Message-ID: <20011010125803.A16960@Space.Net> Hi, On Wed, Oct 10, 2001 at 12:52:37PM +0200, Nipper, Arnold wrote: > > You're taking the very easy way "stop complaining, it's all your own > fault". > > Maybe it's easy, but I must say I've seen megatons of complaints, rants, ... > but not yet a kilo of an idea how to solve the problem. I have provided a number of suggestions. Multiple times. The basic issue is that multihoming is not *the* answer. It's *one*, and it has to be evaluated whether it's the right one for any specific customer. Besides things caused by multihoming, there are many other prefixes that are announced but could be avoided by better aggregation or renumbering. > I still can't see why the idea of having own netblocks and AS for > multi-homing customers breaks if one ISP is going south. But of course there > are other and more financial drawbacks with this approach. Not "going south". But "leaving the confederation due to unsolvable political problems". See what happened with Contrib.NET when they broke into GTN and TCP/IP (to repeat myself). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Wed Oct 10 12:42:48 2001 From: gert at space.net (Gert Doering) Date: Wed, 10 Oct 2001 12:42:48 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <018801c15172$f139c060$0390a8c0@nipper.de>; from arnold@nipper.de on Wed, Oct 10, 2001 at 12:04:23PM +0200 References: <018801c15172$f139c060$0390a8c0@nipper.de> Message-ID: <20011010124248.Z16960@Space.Net> Hi, On Wed, Oct 10, 2001 at 12:04:23PM +0200, Nipper, Arnold wrote: > there are a lot of reasons why customers want to be multi-homed. And what > I'm seeing here is, that the ISP community is not able to offer such a > service. But instead of blaming the "stupid" customers, ISP should go home > and make their homework. So what should "their homework be", then? BGP has its limitations, and there are no other WAN routing protocols yet that *would* work with ever-increasing table size and topology complexity. You're taking the very easy way "stop complaining, it's all your own fault". Things like "ISP confederations, many ISPs using the same address space and multi-homing their customers among themselves" is something that might work, but are VERY problematic when this breaks apart. See what happened to Contrib.NET - lots of small routes from 194.77.* as a result of this. ... and if you make it "one organization", then you have exactly what my proposal for resiliency and stability is: multihome to different POPs of the same ISP. Which will be sufficient for most enterprise customers (that do not add address management and end customer issues into this), and it will be a lot less expensive on them and on the global network than doing "externally visible multihoming". Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From arnold at nipper.de Wed Oct 10 12:52:37 2001 From: arnold at nipper.de (Nipper, Arnold) Date: Wed, 10 Oct 2001 12:52:37 +0200 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> Message-ID: <020201c15179$ae22e660$0390a8c0@nipper.de> Hoi Gert, > You're taking the very easy way "stop complaining, it's all your own fault". > Maybe it's easy, but I must say I've seen megatons of complaints, rants, ... but not yet a kilo of an idea how to solve the problem. I still can't see why the idea of having own netblocks and AS for multi-homing customers breaks if one ISP is going south. But of course there are other and more financial drawbacks with this approach. The new mantra is: go home and do your homework -- Arnold From arnold at nipper.de Wed Oct 10 13:14:23 2001 From: arnold at nipper.de (Nipper, Arnold) Date: Wed, 10 Oct 2001 13:14:23 +0200 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> <20011010125803.A16960@Space.Net> Message-ID: <023201c1517c$c4fd1740$0390a8c0@nipper.de> Gert, > The basic issue is that multihoming is not *the* answer. It's *one*, and > it has to be evaluated whether it's the right one for any specific customer. > the basic issue is that multi-homing is *the demand*. And it's not the ISP who has to evaluate whether it's the right one but the *customer*. We live in a customer - driven world. Money makes the world go round, not techies. Go home and make your homework. -- Arnold From jacek_blocki at hp.com Wed Oct 10 13:18:08 2001 From: jacek_blocki at hp.com (BLOCKI,JACEK (HP-Poland,ex1)) Date: Wed, 10 Oct 2001 13:18:08 +0200 Subject: Multihoming - Resilience or Independence Message-ID: <952C79D45561D4119FCE00D0B708C8E002D7D09B@lem.poland.hp.com> Hi, Decisions are based on both science and superstition. In my opinion requests to connect to "two independent ISPs" result mostly from superstition. BGP routing is not particularly good at servicing resilient links. If an access link to ISP fails it takes some time before routing reconfigures, we don't like route flaps do we?. In my opinion OSPF + 2 access links to 2 POPs of single ISP would do the you much better. I wonder why virtually nobody offers such a service? From my perspective an entity running LIR is responsible for both IP addressing and IP traffic shaping. An entity may wish to become a LIR for number of business reasons. RIR should not verify validity of those reasons, however RIR should verify if to-be LIR understand what he applies for. This may mean technical consultancy for free, but since RIPE is a non-profit organization raised membership fees have to be spent anyway ;-) Regards, Jacek From carl at servicefactory.se Wed Oct 10 13:46:57 2001 From: carl at servicefactory.se (Carl Moberg) Date: Wed, 10 Oct 2001 13:46:57 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <023201c1517c$c4fd1740$0390a8c0@nipper.de> References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> <20011010125803.A16960@Space.Net> Message-ID: <5.1.0.14.0.20011010133601.02f66c00@10.2.0.27> At 01:14 PM 10/10/2001 +0200, you wrote: >Gert, > > > The basic issue is that multihoming is not *the* answer. It's *one*, and > > it has to be evaluated whether it's the right one for any specific >customer. > > > >the basic issue is that multi-homing is *the demand*. And it's not the ISP >who has to evaluate whether it's the right one but the *customer*. We live >in a customer - driven world. Money makes the world go round, not techies. - "I would like a car made out of wood." - "I don't think that that is a good..." - "Stop being a techie, give me a car made out of wood." >Go home and make your homework. ...and you could hear the customers router-"guru" on the verge of crying because he has *no* idea how to get out of this mess he's in from flapping his bgp-session ("umm a couple of times, no idea how many"), and where ever did his routers config go ("It was right here, honest")? >-- Arnold -- carl From mw at uk.yahoo-inc.com Wed Oct 10 13:25:55 2001 From: mw at uk.yahoo-inc.com (Marc Williams) Date: Wed, 10 Oct 2001 12:25:55 +0100 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> <20011010125803.A16960@Space.Net> <023201c1517c$c4fd1740$0390a8c0@nipper.de> Message-ID: <013401c1517e$539be7a0$789d9bd5@MW> > > the basic issue is that multi-homing is *the demand*. And it's not the ISP > who has to evaluate whether it's the right one but the *customer*. We live > in a customer - driven world. Money makes the world go round, not techies. Im going to stick a pile of money on my desk and ask it to configure this router for me. -- Marc From lars at marowsky-bree.de Wed Oct 10 13:30:55 2001 From: lars at marowsky-bree.de (Lars Marowsky-Bree) Date: Wed, 10 Oct 2001 13:30:55 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <023201c1517c$c4fd1740$0390a8c0@nipper.de>; from "Nipper, Arnold" on 2001-10-10T13:14:23 References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> <20011010125803.A16960@Space.Net> <023201c1517c$c4fd1740$0390a8c0@nipper.de> Message-ID: <20011010133055.X1206@marowsky-bree.de> On 2001-10-10T13:14:23, "Nipper, Arnold" said: > the basic issue is that multi-homing is *the demand*. And it's not the ISP > who has to evaluate whether it's the right one but the *customer*. We live > in a customer - driven world. Money makes the world go round, not techies. > > Go home and make your homework. That attitude is partly the problem for the current situation on the backbone. You see, if a solution just won't work, there is no point in selling it to the customer; you are not living in a customer-driven world, but in a world driven by the fastest access to his money. Anyway, this is seriously offtopic here and I would suggest that you go back home and make your _own_ homework first. -- "I'm extraordinarily patient provided I get my own way in the end." -- Margeret Thatcher From phk at critter.freebsd.dk Wed Oct 10 13:31:15 2001 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 10 Oct 2001 13:31:15 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: Your message of "Wed, 10 Oct 2001 12:42:48 +0200." <20011010124248.Z16960@Space.Net> Message-ID: <18639.1002713475@critter.freebsd.dk> In message <20011010124248.Z16960 at Space.Net>, Gert Doering writes: >Hi, > >On Wed, Oct 10, 2001 at 12:04:23PM +0200, Nipper, Arnold wrote: >> there are a lot of reasons why customers want to be multi-homed. And what >> I'm seeing here is, that the ISP community is not able to offer such a >> service. But instead of blaming the "stupid" customers, ISP should go home >> and make their homework. > >So what should "their homework be", then? BGP has its limitations, and >there are no other WAN routing protocols yet that *would* work with >ever-increasing table size and topology complexity. I have been monitoring IPv6 for exactly this point: how do IPv6 propose to give people redundancy/ressilience. So far I have not seen anybody really say "this is how it should be done". The best I have been able to gather is that it is expected that end customers assign multiple IP# to their servers and leave the selection to the DNS and the other end. I don't know if the "anycast" idea was part of this solution but right now I certainly don't see any other solution than DNS. My current advice to my customers are therefore: Multiple IP# per server, use DNS for load-balancing. I certainly think that in europe BGP-confederations can be a partial interrim solution, I can't see why we shouldn't be able to make one centered on the local IX'es for instance, but it would take actual will and interest from the local ISPs, and that would require market-demand... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From gert at space.net Wed Oct 10 14:04:22 2001 From: gert at space.net (Gert Doering) Date: Wed, 10 Oct 2001 14:04:22 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <023201c1517c$c4fd1740$0390a8c0@nipper.de>; from arnold@nipper.de on Wed, Oct 10, 2001 at 01:14:23PM +0200 References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> <20011010125803.A16960@Space.Net> <023201c1517c$c4fd1740$0390a8c0@nipper.de> Message-ID: <20011010140422.B16960@Space.Net> Hi, On Wed, Oct 10, 2001 at 01:14:23PM +0200, Nipper, Arnold wrote: > > The basic issue is that multihoming is not *the* answer. It's *one*, and > > it has to be evaluated whether it's the right one for any specific > customer. > > the basic issue is that multi-homing is *the demand*. And it's not the ISP > who has to evaluate whether it's the right one but the *customer*. We live > in a customer - driven world. Money makes the world go round, not techies. Which is part of the problem, yes. But as a responsible ISP, it *is* our job to recommend to our customers the best thing for them, and for the network in general. Nobody is served if we all try to make as much money as possible this year, just to see the basic infrastructure become unusable in a year or two. Randy says the IRTF needs about 5 years to come up with a new routing paradigm, so it's our job to make sure what we have lasts until then. > Go home and make your homework. Why don't you keep out of this discussion if you don't want to contribute? Besides, I *am* making my homework. I point fingers at problems that some persons claim do not exist. I point out possible (but inconvenient) solutions. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From stephenb at uk.uu.net Wed Oct 10 15:07:33 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Wed, 10 Oct 2001 14:07:33 +0100 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> Message-ID: <015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> ----- Original Message ----- From: "Nipper, Arnold" To: "Gert Doering" Cc: "Dave Pratt" ; ; Sent: Wednesday, October 10, 2001 11:52 AM Subject: Re: Multihoming - Resilience or Independence > Hoi Gert, > > > You're taking the very easy way "stop complaining, it's all your own > fault". > > > > Maybe it's easy, but I must say I've seen megatons of complaints, rants, ... > but not yet a kilo of an idea how to solve the problem. > > I still can't see why the idea of having own netblocks and AS for > multi-homing customers breaks if one ISP is going south. But of course there > are other and more financial drawbacks with this approach. One major problem is not being able to offer an SLA on the routing of the address space, apart from the fact it is yet another route in the global routing tables. > > > The new mantra is: go home and do your homework The new mantra is: We have done our homework now you do yours ;) > > > -- Arnold > From arnold at nipper.de Wed Oct 10 14:10:41 2001 From: arnold at nipper.de (Nipper, Arnold) Date: Wed, 10 Oct 2001 14:10:41 +0200 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> <20011010125803.A16960@Space.Net> <023201c1517c$c4fd1740$0390a8c0@nipper.de> <20011010140422.B16960@Space.Net> Message-ID: <028e01c15184$957cc6c0$0390a8c0@nipper.de> Gert meinte: > Randy says the IRTF needs about 5 years to come up with a new routing > paradigm, so it's our job to make sure what we have lasts until then. > If we can go for another five years, go on. If not than there has to be a solution earlier. It's almost unbelievable but obviously no one was thinking about this problem when we ran into the IPv4 debacle and invented IPv6. So hurry up. > > Go home and make your homework. > > Why don't you keep out of this discussion if you don't want to contribute? > Luckily it's not you who decides who contributes or not. -- Arnold From arnold at nipper.de Wed Oct 10 15:24:27 2001 From: arnold at nipper.de (Nipper, Arnold) Date: Wed, 10 Oct 2001 15:24:27 +0200 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> <015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> Message-ID: <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> Stephen meinte: > > I still can't see why the idea of having own netblocks and AS for > > multi-homing customers breaks if one ISP is going south. But of course > there > > are other and more financial drawbacks with this approach. > > One major problem is not being able to offer an SLA on the routing of the > address space, apart from the fact it is yet another route in the global > routing tables. > I can't see why you can't have SLAs. And which SLA exactly are you talking about? Of course another prefix and another AS is added to the routing table but thereby you are witdrawing at least more than two (both prefs as well as AS). ==> table gets smaller. > > > > > > The new mantra is: go home and do your homework > > The new mantra is: We have done our homework now you do yours ;) > motd (mantra of the day): re-do your homework. It was not good. -- Arnold From stephenb at uk.uu.net Wed Oct 10 17:07:24 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Wed, 10 Oct 2001 16:07:24 +0100 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de><20011010124248.Z16960@Space.Net><020201c15179$ae22e660$0390a8c0@nipper.de><015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> <1002724539.1532.7.camel@kumquat> <001b01c1519b$bd0e5b60$0390a8c0@nipper.de> Message-ID: <01a401c1519d$44a5b3b0$2e04bf3e@eu.frd.uu.net> ----- Original Message ----- From: "Nipper, Arnold" To: "Steven Bakker" Cc: "Stephen Burley" ; "Gert Doering" ; "Dave Pratt" ; ; Sent: Wednesday, October 10, 2001 3:56 PM Subject: Re: Multihoming - Resilience or Independence > > Read again. Stephen wrote "SLA on the routing of the address space". > > Global routing of anyone's address space is dependent on the routing > > policies of individual (third-party) ISPs. Some may be your direct > > peers and you can have agreements with them; many others won't and > > there's no way you can guarantee they'll route your customer's address > > space. The larger the prefix, the larger the chance of some network > > operator out there filtering it to oblivion. > > > > read again: the idea is to put all multi-homing customers in one region into > one prefix (ideally) (MH-pref) and one AS. The prefix should be large enough > to guarantee worldwide routing. Er you can not reserve space so you can not do this and if you give them enough space to garutee routing we are talking a /20 then that is LIR space size...hhmmm. > > > -- Arnold > > > From gert at space.net Wed Oct 10 17:12:37 2001 From: gert at space.net (Gert Doering) Date: Wed, 10 Oct 2001 17:12:37 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <01a401c1519d$44a5b3b0$2e04bf3e@eu.frd.uu.net>; from stephenb@uk.uu.net on Wed, Oct 10, 2001 at 04:07:24PM +0100 References: <018801c15172$f139c060$0390a8c0@nipper.de><20011010124248.Z16960@Space.Net><020201c15179$ae22e660$0390a8c0@nipper.de><015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> <1002724539.1532.7.camel@kumquat> <001b01c1519b$bd0e5b60$0390a8c0@nipper.de> <01a401c1519d$44a5b3b0$2e04bf3e@eu.frd.uu.net> Message-ID: <20011010171237.L16960@Space.Net> Hi, On Wed, Oct 10, 2001 at 04:07:24PM +0100, Stephen Burley wrote: > Er you can not reserve space so you can not do this and if you give them > enough space to garutee routing we are talking a /20 then that is LIR space > size...hhmmm. Back into MIR land :-) - but I think the main problem with this proposal is "what happens if the ISPs in question stop liking each other and this breaks apart" - which would not be the first time. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From steven at icoe.att.com Wed Oct 10 16:35:38 2001 From: steven at icoe.att.com (Steven Bakker) Date: 10 Oct 2001 16:35:38 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> <015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> Message-ID: <1002724539.1532.7.camel@kumquat> On Wed, 2001-10-10 at 15:24, Nipper, Arnold wrote: > Stephen meinte: > > > One major problem is not being able to offer an SLA on the routing of the > > address space, apart from the fact it is yet another route in the global > > routing tables. > > I can't see why you can't have SLAs. And which SLA exactly are you talking > about? > > [...] > > motd (mantra of the day): re-do your homework. It was not good. Read again. Stephen wrote "SLA on the routing of the address space". Global routing of anyone's address space is dependent on the routing policies of individual (third-party) ISPs. Some may be your direct peers and you can have agreements with them; many others won't and there's no way you can guarantee they'll route your customer's address space. The larger the prefix, the larger the chance of some network operator out there filtering it to oblivion. Cheers, Steven From steven at icoe.att.com Wed Oct 10 17:08:19 2001 From: steven at icoe.att.com (Steven Bakker) Date: 10 Oct 2001 17:08:19 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> <015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> Message-ID: <1002726499.1532.19.camel@kumquat> On Wed, 2001-10-10 at 15:24, Nipper, Arnold wrote: > Of course another prefix and another AS is added to the routing table > but thereby you are witdrawing at least more than two (both prefs as well as > AS). ==> table gets smaller. Your math is confusing... or maybe I'm misunderstanding the obvious. Yes, multihoming adds another AS and (at least one) (longish) prefix to the routing table. But in your reasoning, which two prefixes and one AS are being withdrawn? If I resiliently multi-home to one ISP, and I get my address space from its block, I do not add any prefix or AS to the (global) routing table. Even if I multi-home to two ISPs and selectively NAT depending on the outgoing connection, I'll be NAT-ing into the respective ISP's address space (which I presume is properly aggregated), adding no prefix or AS. Cheers, Steven From peter.galbavy at knowtion.net Wed Oct 10 17:34:53 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 10 Oct 2001 16:34:53 +0100 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de><20011010124248.Z16960@Space.Net><020201c15179$ae22e660$0390a8c0@nipper.de><015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> <1002724539.1532.7.camel@kumquat> Message-ID: <03d101c151a1$5e1e8ed0$5d00a8c0@interhouse.redbus.com> > space. The larger the prefix, the larger the chance of some network > operator out there filtering it to oblivion. Sorry to be picky, but I am sure you meant either 'the longer the prefix' or 'the smaller the prefix' ? Peter From stephenb at uk.uu.net Wed Oct 10 17:21:51 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Wed, 10 Oct 2001 16:21:51 +0100 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de><20011010124248.Z16960@Space.Net><020201c15179$ae22e660$0390a8c0@nipper.de><015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> <1002724539.1532.7.camel@kumquat> <001b01c1519b$bd0e5b60$0390a8c0@nipper.de> <01a401c1519d$44a5b3b0$2e04bf3e@eu.frd.uu.net> <20011010171237.L16960@Space.Net> Message-ID: <01b201c1519f$4989c4a0$2e04bf3e@eu.frd.uu.net> > Hi, > > On Wed, Oct 10, 2001 at 04:07:24PM +0100, Stephen Burley wrote: > > Er you can not reserve space so you can not do this and if you give them > > enough space to garutee routing we are talking a /20 then that is LIR space > > size...hhmmm. > > Back into MIR land :-) - but I think the main problem with this proposal > is "what happens if the ISPs in question stop liking each other and > this breaks apart" - which would not be the first time. Yes but my proposal was within one company not spanning comapnies but if you go down the route suggested you are trying to resurect the Lastresort Registry and no one wants that....urgh. > > Gert Doering > -- NetMaster > -- > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > From arnold at nipper.de Wed Oct 10 16:56:24 2001 From: arnold at nipper.de (Nipper, Arnold) Date: Wed, 10 Oct 2001 16:56:24 +0200 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de><20011010124248.Z16960@Space.Net><020201c15179$ae22e660$0390a8c0@nipper.de><015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> <1002724539.1532.7.camel@kumquat> Message-ID: <001b01c1519b$bd0e5b60$0390a8c0@nipper.de> > Read again. Stephen wrote "SLA on the routing of the address space". > Global routing of anyone's address space is dependent on the routing > policies of individual (third-party) ISPs. Some may be your direct > peers and you can have agreements with them; many others won't and > there's no way you can guarantee they'll route your customer's address > space. The larger the prefix, the larger the chance of some network > operator out there filtering it to oblivion. > read again: the idea is to put all multi-homing customers in one region into one prefix (ideally) (MH-pref) and one AS. The prefix should be large enough to guarantee worldwide routing. E.g. for DE you might have three or four of these clusters (or maybe only one). All ISP supporting this cluster are announceing this MH-pref. Internally of course you need a higher resolution. But that's not the problem. By covering the whole world with these MH-clusters you obtain 100 (maybe 200, maybe 1000) clusters. So BGP tablesize would be something of current #ISP + 1000 (or even 10000). Of course there are still a lot of problems. Mainly cashwise as ISP A could have to route traffic for customer X though he has no contract with customer X. And of course MH-AS look very messy. But ... -- Arnold From jacek_blocki at hp.com Wed Oct 10 19:09:42 2001 From: jacek_blocki at hp.com (BLOCKI,JACEK (HP-Poland,ex1)) Date: Wed, 10 Oct 2001 19:09:42 +0200 Subject: Multihoming - Resilience or Independence Message-ID: <952C79D45561D4119FCE00D0B708C8E002D7D3A7@lem.poland.hp.com> Hi, It seems multihoming discussion is an example of vicious circle (sp): More specific routes result in larger routing table but we want those routes and small table... Let me suggest a blasphemy: CIDR being advertised from two ASes. They say it should be only one, but why? In my opinion there is nothing wrong in advertising CIDR from two ASes as long as you can guarantee each border router advertises CIDR only if it can reach it. Imagine the following construction: AS-A--\ +(OSPF) --(CIDR) AS-B--/ Each BGP speaker advertises CIDR if and only if it learned about it from OSPF. It can be done, if you don't know how I'll forward you a working example. Each border router generates a default router and injects it into OSPF. From technical point of view I see no reasons why it should not work. What you need is: * An agreement between ISPs * Change in procedure making such a union of ASes an officially blessed solution so nobody would dare to hinder cooperation with filters. * Optionally you may need a separate CIDR, since both ASes have to advertise same prefix. You need it if each ISP wants to have private customers in addition to shared ones. The customer has "an independent connection to two ISPs" which is the quest item. I see more commercial than technical problems with such a solution. However my expertise is limited and somebody can point drawbacks I cannot see. Feel free to burn me on a stake, that's the right way of treating a blasphemy ;-) Regards, Jacek From gert at space.net Wed Oct 10 19:42:48 2001 From: gert at space.net (Gert Doering) Date: Wed, 10 Oct 2001 19:42:48 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <01b201c1519f$4989c4a0$2e04bf3e@eu.frd.uu.net>; from stephenb@uk.uu.net on Wed, Oct 10, 2001 at 04:21:51PM +0100 References: <018801c15172$f139c060$0390a8c0@nipper.de><20011010124248.Z16960@Space.Net><020201c15179$ae22e660$0390a8c0@nipper.de><015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> <1002724539.1532.7.camel@kumquat> <001b01c1519b$bd0e5b60$0390a8c0@nipper.de> <01a401c1519d$44a5b3b0$2e04bf3e@eu.frd.uu.net> <20011010171237.L16960@Space.Net> <01b201c1519f$4989c4a0$2e04bf3e@eu.frd.uu.net> Message-ID: <20011010194248.N16960@Space.Net> Hi, On Wed, Oct 10, 2001 at 04:21:51PM +0100, Stephen Burley wrote: > > Back into MIR land :-) - but I think the main problem with this proposal > > is "what happens if the ISPs in question stop liking each other and > > this breaks apart" - which would not be the first time. > > Yes but my proposal was within one company not spanning comapnies but if you > go down the route suggested you are trying to resurect the Lastresort > Registry and no one wants that....urgh. Definitely not. I was more thinking a long the route of "LIR confederations" (which APNIC had, as far as I know, and which didn't work). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From randy at psg.com Wed Oct 10 21:21:26 2001 From: randy at psg.com (Randy Bush) Date: Wed, 10 Oct 2001 12:21:26 -0700 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de> <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> <20011010125803.A16960@Space.Net> <023201c1517c$c4fd1740$0390a8c0@nipper.de> Message-ID: > the basic issue is that multi-homing is *the demand*. And it's not the ISP > who has to evaluate whether it's the right one but the *customer*. We live > in a customer - driven world. Money makes the world go round, not techies. not a problem. they can demand all they want. but i will listen to their flakey routes when they *pay* me to do so. randy From randy at psg.com Wed Oct 10 21:42:57 2001 From: randy at psg.com (Randy Bush) Date: Wed, 10 Oct 2001 12:42:57 -0700 Subject: Multihoming - Resilience or Independence References: Message-ID: >>> the basic issue is that multi-homing is *the demand*. And it's not the ISP >>> who has to evaluate whether it's the right one but the *customer*. We live >>> in a customer - driven world. Money makes the world go round, not techies. >> not a problem. they can demand all they want. but i will listen to their >> flakey routes when they *pay* me to do so. > No flame intended here, but aren't your customers already paying you to > get the best connectivity to remote sites? and part of that is running a reliable and stable network. i do kinda well at that. and part of it is routing stability. and part of that is not listening to rubbish. randy From he at uninett.no Wed Oct 10 22:04:22 2001 From: he at uninett.no (Havard Eidnes) Date: Wed, 10 Oct 2001 22:04:22 +0200 (CEST) Subject: more specific routes in today reality In-Reply-To: <20011009214158.I2763@lucky.net> References: <20011009160208.D2763@lucky.net> <20011009214158.I2763@lucky.net> Message-ID: <20011010.220422.58277992.he@uninett.no> > On Tue, Oct 09, 2001 at 07:19:35AM -0700, Randy Bush wrote: > >> We are talking about different types of multihoming. I mean simple > >> multihoming situation when all multihomed customer's needs in routing are > >> covered by they upstream providers routing policies. > > ^ > >note the use of plural above. now read rfc 1930. > > Randy, rfc1930 consists of 563 lines. I suppose you are talking about: I think it's far simpler than that. Quoting (and guessing): To rephrase succinctly: An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy. I.e. a provider (an AS) can only have a single routing policy. However, I also sense some language confusion above, and that what you're trying to say is actually "a simple multihoming situation where any one of the multiple uptstream providers' routing policy would be adequate for the client in question" However, I don't agree that it's a good idea to willfully cause the number of routes originated from different source ASes to increase. Furthermore, the routing complexity doesn't really rise as a function of the number of ASes -- it's rather the number of prefixes or perhaps rather the number of unique paths available which causes the entropy increase in the default-free zone which scares some of us. In the bigger picture it doesn't really make any difference whether the more- specific route comes from PI or PA space or whether the route is consistently originated from a new AS or (shudder) separately from the two (or more) upstream providers; the entrypy increase in the default- free zone would be the same either way. Regards, - H?vard From he at uninett.no Wed Oct 10 22:16:38 2001 From: he at uninett.no (Havard Eidnes) Date: Wed, 10 Oct 2001 22:16:38 +0200 (CEST) Subject: more specific routes in today reality In-Reply-To: <20011009232702.22263694.czmok@lambda-solutions.de> References: <20011009222614.6762f607.czmok@lambda-solutions.de> <15299.25427.280580.480440@doncamillo.local.easynet.de> <20011009232702.22263694.czmok@lambda-solutions.de> Message-ID: <20011010.221638.91297309.he@uninett.no> > > So what are you refering to? Please name examples of your wild claim: > > Okay, let's see if i find it: > > 192.124.115.0/24 == weblease AG, old address space from pre-ARIN, > region should be ARIN/USA, is used in DE (okay -- no direct /16 or > smaller announcement) [...] Right. Routing is more or less orthogonal to assignment or allocation policies. There's no general route 192.0.0/8 in the default-free zone, so one or more providers in the default-free zone stopped listening to prefixes longer than, say /20, packets from those providers' customers towards e.g. 192.124.115.0/24 would be dropped on the floor by the first router along the path which didn't have a default route. > [...], but an example of the bad usage in the swamp space. > > inetnum: 194.13.111.0 - 194.13.111.255 > > route-server>sh ip bgp 194.13.111.0/24 shorter-prefixes > * 194.13.0.0/17 12.123.25.245 0 7018 3549 1103 1103 i The routes 194.13.111.0/24 and 194.13.0.0/17 have different origin ASes, 1103 and 5409, respectively. My guess is that the originator of the 194.13.0.0/17 prefix is being a Good Guy, since he probably figures that he has the majority of the address space covered by that prefix, he originates that single /17 route instead of deaggregating to cover the exact address space he has allocated locally. If that /24 route should vanish from the network, traffic towards that prefix would be sent in the direction indicated by the enclosing /17, but there is in all probability no connectivity between the two networks, so the traffic would be dropped on the floor when it came within the zone of the /17-originators network (but the /24 route is gone, possibly due to an outage, so who cares?). And your point was what, again? Regards, - H?vard From mohta at necom830.hpcl.titech.ac.jp Wed Oct 10 22:44:43 2001 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 11 Oct 2001 05:43:43 +0859 () Subject: Multihoming - Resilience or Independence In-Reply-To: <18639.1002713475@critter.freebsd.dk> from Poul-Henning Kamp at "Oct 10, 2001 01:31:15 pm" Message-ID: <200110102043.FAA26347@necom830.hpcl.titech.ac.jp> Poul-Henning Kamp; > I have been monitoring IPv6 for exactly this point: how do IPv6 propose > to give people redundancy/ressilience. > > So far I have not seen anybody really say "this is how it should be done". draft-ohta-e2e-multihoming-00.txt is dated April 2000. And, now, there even is a multi6 WG of IETF. > The best I have been able to gather is that it is expected that end > customers assign multiple IP# to their servers and leave the selection > to the DNS and the other end. I don't know if the "anycast" idea > was part of this solution but right now I certainly don't see any > other solution than DNS. > > My current advice to my customers are therefore: Multiple IP# per > server, use DNS for load-balancing. The problem is that load-balancing is not a reason for multi-homing. With the same amount of payment, you should be able to get more bandwidth from a single ISP (bulk discount) than from multiple ISPs that there is no need for load-balancing. Masataka Ohta From hph at online.no Wed Oct 10 23:51:11 2001 From: hph at online.no (Hans Petter Holen) Date: Wed, 10 Oct 2001 23:51:11 +0200 Subject: 40.5: RFC 2050 mailinglist Message-ID: Dear lir-wg, At the meeting in Praha we briefly discussed how to contribute to the global effort to revise RFC 2050. We were informed that ARIN had set up a working group for this, with a mailing list. It was suggested that we might join the mailing list hosted by ARIN to participate in this work, thus forming a truly global effort on the matter. Ray Plzak the President of ARIN invited the RIPE community to do so. After positive reactions from the participants, and no voices against, the chair declared consensus on this matter. The details of the list is: * List Address: 2050-wg at arin.net * Subscription is open to all interested parties * List is archived More information about the list is available at: http://www.arin.net/members/mailing.htm The charter from ARINs announcement: "The objective of the RFC 2050 Working Group is to address the issues relating to relevance of RFC 2050 to the needs of today's Internet registry system. The group will evaluate RFC 2050 and propose a method of replacing it with a new document or documents. Once consensus has emerged on the process that will be used to replace RFC 2050, the working group will cooperatively develop its replacement. The working group will work in coordination with the other Regional Internet Registries, who will conduct a similar review process in their respective regions. " Hans Petter Holen WG Chair ARIN announcement: http://www.arin.net/mailinglists/arin-announce/0121.html From: Member Services (memsvcs at arin.net) Date: Mon Sep 10 2001 - 11:24:00 EDT ---------------------------------------------------------------------------- ---- At the last ARIN Open Policy meeting in San Francisco concerns were raised about RFC 2050. It was noted that this document has aged and that certain portions of it no longer reflected the current state of RIR policy and operations. Similar concerns have been raised in the APNIC and RIPE NCC regions. Accordingly, ARIN is establishing a working group to further examine this issue. Mark McFadden has volunteered to chair the 2050WG. The charter for the working group follows: The objective of the RFC 2050 Working Group is to address the issues relating to relevance of RFC 2050 to the needs of today's Internet registry system. The group will evaluate RFC 2050 and propose a method of replacing it with a new document or documents. Once consensus has emerged on the process that will be used to replace RFC 2050, the working group will cooperatively develop its replacement. The working group will work in coordination with the other Regional Internet Registries, who will conduct a similar review process in their respective regions. An email list for the 2050WG has been established. Subscription information can be found at the following URL: http://www.arin.net/members/mailing.htm All interested individuals are encouraged to participate in this discussion. This will be an agenda item at the next ARIN Open Policy meeting in Miami. Ray Plzak President -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3340 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Wed Oct 10 23:52:05 2001 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 11 Oct 2001 06:51:05 +0859 () Subject: Multihoming - Resilience or Independence In-Reply-To: <4023.1002748719@critter.freebsd.dk> from Poul-Henning Kamp at "Oct 10, 2001 11:18:39 pm" Message-ID: <200110102151.GAA26904@necom830.hpcl.titech.ac.jp> Poul-Henning Kamp; > > draft-ohta-e2e-multihoming-00.txt > > > >is dated April 2000. > > And, according to IETF rules, because of its age: obsolete ? Current most one is of version 02. > > draft-ohta-e2e-multihoming-00.txt > > >And, now, there even is a multi6 WG of IETF. > > Cool, lets see what they can disagree on in a couple of years... IETF process is so quick that you can see it already. :-) > Load-balancing means different things to different people... So is multihoming. > But that doesn't change the fact that people will still want a > solution now, that neither "go to IPv6" nor "wait for IPv6" will > satisfy them and that ISP's who are able to meet this demand will > make more money than ISP's who can't... Huh? It's you who asked about IPv6. Anyway, I think we will use up IPv4 address space before IPv4-style multihoming kills the backbone. It will happen within 3 years. A good news is that, not wating multi6 WG conclude, end-to-end multihoming will be implemented this year and used for commercial service (IPv4 service will, of course, continue) thanks to funding from Japanese Goverment. Masataka Ohta From PLu at cw.net Wed Oct 10 18:00:25 2001 From: PLu at cw.net (Lu, Ping) Date: Wed, 10 Oct 2001 12:00:25 -0400 Subject: Multihoming - Resilience or Independence Message-ID: > -----Original Message----- > From: Steven Bakker [mailto:steven at icoe.att.com] > Sent: Wednesday, October 10, 2001 11:08 AM > To: Nipper, Arnold > Cc: Stephen Burley; Gert Doering; Dave Pratt; lir-wg at ripe.net; > routing-wg at ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > On Wed, 2001-10-10 at 15:24, Nipper, Arnold wrote: > > Of course another prefix and another AS is added to the > routing table > > but thereby you are witdrawing at least more than two (both > prefs as well as > > AS). ==> table gets smaller. > > Your math is confusing... or maybe I'm misunderstanding the obvious. > Yes, multihoming adds another AS and (at least one) (longish) > prefix to > the routing table. But in your reasoning, which two prefixes > and one AS > are being withdrawn? If I resiliently multi-home to one ISP, > and I get > my address space from its block, I do not add any prefix or AS to the > (global) routing table. Even if I multi-home to two ISPs and > selectively NAT depending on the outgoing connection, I'll be NAT-ing > into the respective ISP's address space (which I presume is properly > aggregated), adding no prefix or AS. Your prefixes (let's say /24) has to be announced by two ISPs so the packets will come back to you. If ISP A's link failed then that /24 with ISP A in the ASPATH will be withdrawn. And ISP B's /24 will become active. So in the global routing table there will be TWO /24 with different ASPATH. If this /24 is in ISP A's PA space then it saves one but the one from ISP B's one NEEDs to be in the global routing table. The worse case: ISP A only announces aggregate block even if the link failed then the traffic will still go thru ISP A then get dropped. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From steven at icoe.att.com Wed Oct 10 17:43:56 2001 From: steven at icoe.att.com (Steven Bakker) Date: 10 Oct 2001 17:43:56 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <03d101c151a1$5e1e8ed0$5d00a8c0@interhouse.redbus.com> References: <018801c151 72$f139c060$0390a8c0@nipper.de><20011010124248.Z16960@Space.Net><020201c1517 9$ae22e660$0390a8c0@nipper.de><015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> <1002724539.1532.7.camel@kumquat> <03d101c151a1$5e1e8ed0$5d00a8c0@interhouse.redbus.com> Message-ID: <1002728636.1532.45.camel@kumquat> On Wed, 2001-10-10 at 17:34, Peter Galbavy wrote: > > space. The larger the prefix, the larger the chance of some network > > operator out there filtering it to oblivion. > > Sorry to be picky, but I am sure you meant either 'the longer the prefix' or > 'the smaller the prefix' ? Sorry, yes, longer prefix, i.e., "more specific". Steven From arnold at nipper.de Wed Oct 10 17:24:42 2001 From: arnold at nipper.de (Nipper, Arnold) Date: Wed, 10 Oct 2001 17:24:42 +0200 Subject: Multihoming - Resilience or Independence References: <018801c15172$f139c060$0390a8c0@nipper.de><20011010124248.Z16960@Space.Net><020201c15179$ae22e660$0390a8c0@nipper.de><015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> <1002724539.1532.7.camel@kumquat> <001b01c1519b$bd0e5b60$0390a8c0@nipper.de> <01a401c1519d$44a5b3b0$2e04bf3e@eu.frd.uu.net> <20011010171237.L16960@Space.Net> Message-ID: <00c101c1519f$b09095c0$0390a8c0@nipper.de> Gert meinte: > Hi, > > On Wed, Oct 10, 2001 at 04:07:24PM +0100, Stephen Burley wrote: > > Er you can not reserve space so you can not do this and if you give them > > enough space to garutee routing we are talking a /20 then that is LIR space > > size...hhmmm. > > Back into MIR land :-) - but I think the main problem with this proposal > is "what happens if the ISPs in question stop liking each other and > this breaks apart" - which would not be the first time. > Money is always the best string that things don't fail. E.g.: MIRs could be organized/overseen by IXP. Each ISP wanting to contribute to MIR has to have a contract with the organisation running the MIR. And high penalties guarantee that the MIR is still there even "if the ISPs in question stop liking each other". Obviously the big advantage is that this model scales very well. -- Arnold From kurtis at kpnqwest.net Wed Oct 10 18:43:16 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Wed, 10 Oct 2001 18:43:16 +0200 (MEST) Subject: Multihoming - Resilience or Independence In-Reply-To: <023201c1517c$c4fd1740$0390a8c0@nipper.de> Message-ID: Hi Arnold, > > The basic issue is that multihoming is not *the* answer. It's *one*, and > > it has to be evaluated whether it's the right one for any specific > customer. > > > > the basic issue is that multi-homing is *the demand*. And it's not the ISP > who has to evaluate whether it's the right one but the *customer*. We live > in a customer - driven world. Money makes the world go round, not techies. Is that really what the customer want? Or do they actually want resilience and redundancy? And for that there are other ways... - kurtis - From sabri at bit.nl Wed Oct 10 21:37:40 2001 From: sabri at bit.nl (Sabri Berisha) Date: Wed, 10 Oct 2001 21:37:40 +0200 (CEST) Subject: Multihoming - Resilience or Independence In-Reply-To: Message-ID: On Wed, 10 Oct 2001, Randy Bush wrote: > > the basic issue is that multi-homing is *the demand*. And it's not the ISP > > who has to evaluate whether it's the right one but the *customer*. We live > > in a customer - driven world. Money makes the world go round, not techies. > > not a problem. they can demand all they want. but i will listen to their > flakey routes when they *pay* me to do so. No flame intended here, but aren't your customers already paying you to get the best connectivity to remote sites? If a more specific route is shorter or has more bandwith available shouldn't you route the traffic that way in the interest of your customers? Of course I see the point in filling up 128megs of ram with routing tables but I ask myself what costs more; 128megs of extra ram or customers running off to another ISP because that has better connectivity to their favorite site? -- Sabri Berisha ~~ my own opinions etc ~ From vovik at lucky.net Wed Oct 10 21:58:02 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Wed, 10 Oct 2001 22:58:02 +0300 Subject: more specific routes in today reality In-Reply-To: ; from kurtis@kpnqwest.net on Wed, Oct 10, 2001 at 10:54:22AM +0200 References: <20011009214158.I2763@lucky.net> Message-ID: <20011010225802.A43856@lucky.net> On Wed, Oct 10, 2001 at 10:54:22AM +0200, Kurt Erik Lindqvist KPNQwest wrote: > >> But hadn't reached enough resilience level. They technical and marketing staff >> considered that without multihoming they can't achieve sufficient resilience >> level. They don't ready to pay for Enterprise LIR because they know about PI. >> They asked ISP to help them to obtain PI block and AS num. With ISP Network >> Engineer assistance they filled in ripe-219. Network Engineer sent it to >> Regional Internet Registry. > >I have a feeling that we are trying to solve the poor performance of some >players in this business with addressing policy. > >The easiest and best way for a customer to get resiliency is > >a) Get a provider that is a Tier-1 or have multiple upstreams >b) Make sure you provider have a resilient network >c) Get dual (really) connections to your provider. > >I assure you this will be cheaper than to get your own address space, LIR >status, and God knows what. > >If a provider can't supply the above to a customer that really have the >need for multiple connections and is willing to pay for it, I would change >provider anyay. There is one big issue: - you are ready to believe your "Tier-1 bla bla bla" provider for 24/7 non stop 100% quality of your Internet or - you are not Even in situation, when you can find close to you POP of reliable "Tier-1 bla bla bla" provider, two or more last mile providers, there always are people, who don't trust only one uplink. Psychology. Also pls don't forget about some geographical regions, covered by RIPE, where mostly impossible to build even one last mile channel to nearest "Tier-1 bla bla bla" provider for non-huge money. -- Regards, Vladimir. From kurtis at kpnqwest.net Wed Oct 10 22:08:09 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Wed, 10 Oct 2001 22:08:09 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: <20011010225802.A43856@lucky.net> Message-ID: > >If a provider can't supply the above to a customer that really have the > >need for multiple connections and is willing to pay for it, I would change > >provider anyay. > Also pls don't forget about some geographical regions, covered by RIPE, where > mostly impossible to build even one last mile channel to nearest "Tier-1 bla > bla bla" provider for non-huge money. And in what way would my own AS number and PA space give me more last-mile providers? - kurtis - From vovik at lucky.net Wed Oct 10 22:09:44 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Wed, 10 Oct 2001 23:09:44 +0300 Subject: more specific routes in today reality In-Reply-To: <20011010002109.L16960@Space.Net>; from gert@Space.Net on Wed, Oct 10, 2001 at 12:21:09AM +0200 References: <20011009131049.A60790@lucky.net> <3BB9050D0006CB24@mail.epost.de> <20011009204502.G16960@Space.Net> <20011009211305.26e5fcad.czmok@lambda-solutions.de> <20011009212954.K16960@Space.Net> <20011009231725.K2763@lucky.net> <20011010002109.L16960@Space.Net> Message-ID: <20011010230944.B43856@lucky.net> On Wed, Oct 10, 2001 at 12:21:09AM +0200, Gert Doering wrote: >Hi, > >On Tue, Oct 09, 2001 at 11:17:25PM +0300, Vladimir A. Jakovenko wrote: >> >> Some providers are multihomed >> >> but cannot cover the costs, even for a small lir. >> >If you want to be multihomed, the costs for routers & co. are far higher >> >than for being LIR. If you can't afford being LIR, be single-homed. >> >> Are you sure? Old BGP-capable Cisco routers (like 25xx), especialy from eBay >> are very cheap. > >"Multihoming" with something less than full tables won't really solve >anything - as "multihoming without an AS number", it's some weird thing >that has its place, but doesn't buy you much in the long run. Please pay attention to _like_ in above statement. Ohh ... and about eBay: ttyp8 vovik at quiver:~>whois -h whois.radb.net 216.32.120.133 route: 216.32.120.0/24 descr: NET-EXODUS-EBAY-1 origin: AS3967 mnt-by: MAINT-AS3967 changed: radb at bengi.exodus.net 19981116 source: RADB route: 216.32.120.0/24 descr: NET-EBAY-1 origin: AS11643 notify: tholo at sigmasoft.com mnt-by: MAINT-AS11643 changed: tholo at sigmasoft.com 19981116 source: RADB Perhaps you are right, and this 'weird' thing was happened in 1998 by staff misunderstanding of how they should create route-objects. Right? :-) >(As for your example with the IX - this could be done without globally >visible space just fine, it's not "multihoming") It depends on IX routing policy. -- Regards, Vladimir. From phk at critter.freebsd.dk Wed Oct 10 23:18:39 2001 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 10 Oct 2001 23:18:39 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: Your message of "Thu, 11 Oct 2001 05:43:43 +0859." <200110102043.FAA26347@necom830.hpcl.titech.ac.jp> Message-ID: <4023.1002748719@critter.freebsd.dk> In message <200110102043.FAA26347 at necom830.hpcl.titech.ac.jp>, Masataka Ohta wr ites: >> So far I have not seen anybody really say "this is how it should be done". > > draft-ohta-e2e-multihoming-00.txt > >is dated April 2000. And, according to IETF rules, because of its age: obsolete ? >And, now, there even is a multi6 WG of IETF. Cool, lets see what they can disagree on in a couple of years... >> My current advice to my customers are therefore: Multiple IP# per >> server, use DNS for load-balancing. > >The problem is that load-balancing is not a reason for multi-homing. (For the moment, you can save yourself a lot of time by assuming that I actually know what I'm talking about :-) Load-balancing means different things to different people... Some people include in "load-balancing" the ability to disable non-responsive servers, upstream providers and so on. Just as we learned that checksums and handshakes only matter if they are end-to-end, the same way people will eventually realize that load-balancing, redundancy and resillience only matter if implemented end-to-end. But that doesn't change the fact that people will still want a solution now, that neither "go to IPv6" nor "wait for IPv6" will satisfy them and that ISP's who are able to meet this demand will make more money than ISP's who can't... Human nature being what it is, we can also pressume that rules will be bent as far as possible and that more money speaks louder... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at critter.freebsd.dk Thu Oct 11 00:05:55 2001 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 11 Oct 2001 00:05:55 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: Your message of "Thu, 11 Oct 2001 06:51:05 +0859." <200110102151.GAA26904@necom830.hpcl.titech.ac.jp> Message-ID: <4801.1002751555@critter.freebsd.dk> In message <200110102151.GAA26904 at necom830.hpcl.titech.ac.jp>, Masataka Ohta wr ites: >> But that doesn't change the fact that people will still want a >> solution now, that neither "go to IPv6" nor "wait for IPv6" will >> satisfy them and that ISP's who are able to meet this demand will >> make more money than ISP's who can't... > >Huh? It's you who asked about IPv6. No, I didn't ask, I pointed out that there were _still_ neither an established technique nor a policy for IPv6 in this area. >Anyway, I think we will use up IPv4 address space before IPv4-style >multihoming kills the backbone. It will happen within 3 years. I think you will see a lot of IPv4 space reclaimed by force will be able to put IPv4 on life-support for a LONG time... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From vovik at lucky.net Thu Oct 11 04:10:55 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Thu, 11 Oct 2001 05:10:55 +0300 Subject: more specific routes in today reality In-Reply-To: <20011010.220422.58277992.he@uninett.no>; from he@uninett.no on Wed, Oct 10, 2001 at 10:04:22PM +0200 References: <20011009160208.D2763@lucky.net> <20011009214158.I2763@lucky.net> <20011010.220422.58277992.he@uninett.no> Message-ID: <20011011051055.H2763@lucky.net> On Wed, Oct 10, 2001 at 10:04:22PM +0200, Havard Eidnes wrote: >> On Tue, Oct 09, 2001 at 07:19:35AM -0700, Randy Bush wrote: >> >> We are talking about different types of multihoming. I mean simple >> >> multihoming situation when all multihomed customer's needs in routing are >> >> covered by they upstream providers routing policies. >> > ^ >> >note the use of plural above. now read rfc 1930. >> >> Randy, rfc1930 consists of 563 lines. I suppose you are talking about: > >I think it's far simpler than that. Quoting (and guessing): > > To rephrase succinctly: > > An AS is a connected group of one or more IP prefixes run by one > or more network operators which has a SINGLE and CLEARLY DEFINED > routing policy. > >I.e. a provider (an AS) can only have a single routing policy. > >However, I also sense some language confusion above, and that what >you're trying to say is actually > > "a simple multihoming situation where any one of the multiple > uptstream providers' routing policy would be adequate for the client > in question" Yes. >However, I don't agree that it's a good idea to willfully cause the >number of routes originated from different source ASes to increase. If we are talking about theory -- agree, it's not a good idea. >Furthermore, the routing complexity doesn't really rise as a function >of the number of ASes -- it's rather the number of prefixes or perhaps >rather the number of unique paths available which causes the entropy >increase in the default-free zone which scares some of us. In the >bigger picture it doesn't really make any difference whether the more- >specific route comes from PI or PA space or whether the route is >consistently originated from a new AS or (shudder) separately from the >two (or more) upstream providers; the entrypy increase in the default- >free zone would be the same either way. I agree with mentioned above statements about stability in "default-free zone". But (AFAIK) according to measurements and statistics amount of free AS-numbers are going to overflow more rapidly than free IPv4 address space. I believe that sometimes AS-numbers space will be extended, but (AFAIK) it requires global replacement of BGP-routing sotware. In this situation ?RIRs? are looking for ?temporary? solution how to decrease rate of AS-numbers allocation. One of such solutions (IMHO) is "more specific routes multihoming". I don't have exact information about other RIRs, but RIPE NCC already _promotes_ such solution. achieve multihoming) point of view adoption of such multihoming method, promoted by RIR, (sometimes) requires changes in routing policies and in what we are calling as "best practice". IMHO without new documents, recomendations, etc new multihoming method is (mostly) useless. Original posting was concerned in: - are there any already published/draft documents? - are there any plans to create such documents? If there aren't, and if community aren't going to accept such technology (from our discussion it seems that now there isn't common opinnion), IMHO, RIR "snake the air to no purpose" - such technology is (generally) useless. -- Regards, Vladimir. From vovik at lucky.net Thu Oct 11 04:41:50 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Thu, 11 Oct 2001 05:41:50 +0300 Subject: more specific routes in today reality In-Reply-To: ; from kurtis@kpnqwest.net on Wed, Oct 10, 2001 at 10:08:09PM +0200 References: <20011010225802.A43856@lucky.net> Message-ID: <20011011054150.I2763@lucky.net> On Wed, Oct 10, 2001 at 10:08:09PM +0200, Kurt Erik Lindqvist KPNQwest wrote: > >> >If a provider can't supply the above to a customer that really have the >> >need for multiple connections and is willing to pay for it, I would change >> >provider anyay. > >> Also pls don't forget about some geographical regions, covered by RIPE, where >> mostly impossible to build even one last mile channel to nearest "Tier-1 bla >> bla bla" provider for non-huge money. > >And in what way would my own AS number and PA space give me more last-mile >providers? Don't forget about cheap sattelite channels :-) Lets imagine situation - customer in a country, where all terrastical long- range channels are controlled by one big pro-government PTT. There isn't POPs of any of "Tier-1 bla bla bla" providers. All of them can be reached only by expensive long-rage terrastical or (less expensive) sattelite channel. In this situation the most popular solution for local customer, who needs reliable and cheap IP uplink and high speed access to regional Internet resources, is to build two channels to local ISPs (not so reliable, but much more cheaper than even one external uplink) and to local IX. -- Regards, Vladimir. From andrei at ripe.net Thu Oct 11 10:10:02 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 11 Oct 2001 10:10:02 +0200 Subject: changed attribute proposal and not only Message-ID: <3BC553DA.484EC3FE@ripe.net> Dear Colleagues, Please find enclosed the proposal of modification of the changed attribute that was presented at the RIPE-40 meeting in Prague. However, another proposal (or rather idea) came up in light of recent discussions regarding timestamping and cleanup procedures in the RIPE Database. Let me present you this idea first. As was pointed by the two proposals there is a need to store and display status information about an object in the database, such as last update time, number of references, etc. At the same time in order to be reliable this information should be automatically generated by the database software and be outside users' control. Regarding "changed attribute" proposal people felt that this changes some of the basic principles of the RIPE Database. Recent Ulf's proposal makes things even worse since it requires that modification to an object may be caused by an update of another object. But in fact these attributes/facilities do not represent an object, but rather status information about the object. Extending Ulf's analogy with the Unix FS, they are part of the inode, not the data blocks. So status information (object metadata) may be stored and displayed separately from the object itself by, say, using a flag. Much like we display the contents using cat, but status using ls. And this information will be used for cleanup procedure, reliable timestamping, etc. This will not affect any object template, preserve users' data and add flexibility to the database. Something like this: $ whois -q meta RC1234-RIPE ... person: Referenced Contact nic-hdl: RC1234-RIPE ... changed: refcon at somedom.dom 20011005 source: RIPE %metainfo: RC1234-RIPE %update-time: 2001-10-05 16:50:07 %ref-time: 2001-10-06 09:17:33 %ref-count: 3 Regards, Andrei Robachevsky DB Group Manager RIPE NCC From peter.galbavy at knowtion.net Thu Oct 11 10:16:41 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 11 Oct 2001 09:16:41 +0100 Subject: Multihoming - Resilience or Independence References: Message-ID: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> > > the basic issue is that multi-homing is *the demand*. And it's not the ISP > > who has to evaluate whether it's the right one but the *customer*. We live > > in a customer - driven world. Money makes the world go round, not techies. > > Is that really what the customer want? Or do they actually want resilience > and redundancy? And for that there are other ways... I have been watching this thread for a while now, and I finally cannot help but stick my oar in. There are two very clearly defined camps here; one the 'technical' camp that says 'we have many ways of making it work' or 'this is the only way it will work' and the other camp is the 'commercial' saying either 'the customer does not trust just one ISP' or 'I don't care how it works, but it must work'. Now, to add just another opinion to the thread, which is really not that different to some other but may possibly offer something new; In my line of work I have set-up 4 LIRs in the past two years for companies that have had either had bad experiences with their ISPs (usually more than one serially) or some have had to do all 'reasonable' things to ensure good, reliable connectivity for either contractual or due-diligence reasons. Regardless of how good an ISP is *now*, there will come a time when they are sold, bought, merge or go bust that causes change. My personal bugbear was INS. Great in the early days, but within days of Clueless&Witless buying them, the whole thing started to come apart. This is not isolated, and they are not the only ones at all. Also, especially in Europe, ISPs tend to be reliant on 3rd party local-loop carriers, even when we are talking about data-centre / co-location delivery of services. In the UK, all ISPs exclude 3rd party links from SLAs. Right. Good one. Trying to solve the problem of people not trusting ISPs by changing the technology to ensure that people *must* trust one ISP (IPv6 IMHO is just such a technology) is not a very customer friendly attitude. It does not work and will not work. In every other line of business, it is quite normal to buy your product or service from two suppliers, telecoms and Internet are the only real exceptions. You could also discount other utilities, but there is an issue of delivery there that precludes efficient and real competition, so no more there please. As the Internet becomes a true necessity for business, supply will more and more be selected like any other service, and the same contingencies will be made. So, IMHO, please stop trying to 'solve' the problem by pretending that you or any other ISP is reliable, civil and economically viable and stop trying to 'solve' the problem by mandating technology solutions that enforce this goal. It will not work. Peter From peter.galbavy at knowtion.net Thu Oct 11 10:18:15 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 11 Oct 2001 09:18:15 +0100 Subject: more specific routes in today reality References: Message-ID: <01d701c1522d$49da3e10$5d00a8c0@interhouse.redbus.com> > And in what way would my own AS number and PA space give me more last-mile > providers? Potential for independence from any one supplier. Peter From bkrosnov at lirex.bg Thu Oct 11 10:26:06 2001 From: bkrosnov at lirex.bg (Boyan Krosnov) Date: Thu, 11 Oct 2001 11:26:06 +0300 Subject: Multihoming - Resilience or Independence Message-ID: <3FAEA93E6179FA4FBB329456D0A9054A1E0EE7@tquila.lirex.com> > Your prefixes (let's say /24) has to be announced by two ISPs > so the packets > will come back to you. If ISP A's link failed then that /24 > with ISP A in > the > ASPATH will be withdrawn. And ISP B's /24 will become active. > So in the > global > routing table there will be TWO /24 with different ASPATH. > > If this /24 is in ISP A's PA space then it saves one but the > one from ISP > B's one > NEEDs to be in the global routing table. Either I didn't understand you right, or you were wrong. It does not save a route in the DFZ. Let's say the customer gets A/24 out of proider A's A/17 prefix. B has to announce A/24 to the internet along with it's current prefixes. A has to announce A/17 AND A/24 to the internet. If A advertises A/17 only all the traffic for A/24 will go through B (because of the longest match rule), and I think that's not what that customer wants. So Being multihomed to two ASs with NAT or two addreses on each host does not create an extra route in the DFZ. Being multihomed to a single AS does not create an extra route in the DFZ. Being multihomed to two ASs (It doesn't matter PA or PI, separate AS or anounced by the two ASs. Prefix out of PA, separate AS is generally recognised to be the better technical solution.) does create at least 1 extra prefix and 2 extra as-paths in the DFZ. These are the facts about growth of the DFZ routing table caused by multihoming as I see them. There are of course other reasons for the growth like providers advertising 14 separate /24s when they can agregate it to /20 because "We were trying to do some input channel load balacing and have left this anouncements for months because our administrator does not have the time to deal with this thing, he/she has more important work to do". Now it's time to think how we can make people prefer the first 2 possibilities over the third. We've had enough of technical discussion I think. Regards, Boyan Krosnov, CCNP Network Administrator Lirex Net phone: +359-2-91815 From arnold.nipper at de-cix.net Thu Oct 11 10:41:41 2001 From: arnold.nipper at de-cix.net (Nipper, Arnold) Date: Thu, 11 Oct 2001 10:41:41 +0200 Subject: OT: distribution time of RIPE lists (was: Re: Multihoming - Resilience or Independence) References: <018801c15172$f139c060$0390a8c0@nipper.de><20011010124248.Z16960@Space.Net><020201c15179$ae22e660$0390a8c0@nipper.de><015401c1518c$864625e0$2e04bf3e@eu.frd.uu.net> <031c01c1518e$e97bdfe0$0390a8c0@nipper.de> <1002724539.1532.7.camel@kumquat> <001b01c1519b$bd0e5b60$0390a8c0@nipper.de> <01a401c1519d$44a5b3b0$2e04bf3e@eu.frd.uu.net> <20011010171237.L16960@Space.Net> <00c101c1519f$b09095c0$0390a8c0@nipper.de> Message-ID: <008401c15230$992c2700$0390a8c0@nipper.de> A little bit OT: I notify that the order of distribution is more or less randomly. Anyone else noticed this as well? IMHO it's quite contraproductive for discussions ... Examples: sent 2001/10/10 17:24 recv 2001/10/11 09:57 sent 2001/10/10 19:09 recv 2001/10/11 10:03 sent 2001/10/10 17:43 recv 2001/10/11 18:08 -- Arnold From djp-ripe-lists at djp.net Thu Oct 11 12:44:57 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Thu, 11 Oct 2001 12:44:57 +0200 (CEST) Subject: OT: distribution time of RIPE lists In-Reply-To: <008401c15230$992c2700$0390a8c0@nipper.de> Message-ID: Hiya Arnold, This is well known in some circles. Posts to the list are manually approved by the RIPE NCC to reduce spam, unless you send the message from an account which is subscribed (to that individual list I believe). That is why my messages have the sender djp-ripe-lists at djp.net, because that is the address under which I am subscribed and my messages appear almost immediately :) Cheers Dave Normally, djp at djp.net BT Ignite GmbH On Thu, 11 Oct 2001, Nipper, Arnold wrote: ->A little bit OT: I notify that the order of distribution is more or less ->randomly. Anyone else noticed this as well? IMHO it's quite contraproductive ->for discussions ... -> ->Examples: -> ->sent 2001/10/10 17:24 recv 2001/10/11 09:57 ->sent 2001/10/10 19:09 recv 2001/10/11 10:03 ->sent 2001/10/10 17:43 recv 2001/10/11 18:08 -> -> ->-- Arnold -> From niallm-ripe at enigma.ie Thu Oct 11 14:50:50 2001 From: niallm-ripe at enigma.ie (Niall Richard Murphy) Date: Thu, 11 Oct 2001 13:50:50 +0100 Subject: Multihoming - Resilience or Independence In-Reply-To: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com>; from peter.galbavy@knowtion.net on Thu, Oct 11, 2001 at 09:16:41AM +0100 References: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> Message-ID: <20011011135050.C23599@enigma.ie> On Thu, Oct 11, 2001 at 09:16:41AM +0100, Peter Galbavy wrote: Hi Peter, > Trying to solve the problem of people not trusting ISPs by changing the > technology to ensure that people *must* trust one ISP (IPv6 IMHO is just > such a technology) is not a very customer friendly attitude. It does not > work and will not work. Not that I know anything, but in my opinion, you are inaccurate in two respects here. Firstly, IPv6 *technology* is not the issue. You can do everything that you could do in IPv4 with IPv6, and this includes the current methodology for multihoming. It also introduces another way of multihoming, which is akin to taking PA space from multiple upstreams and initiating/receiving connections according to some well defined algorithms. I don't think there is any case to be made that the technology forces a user to trust one ISP. Secondly, however, it has been in my limited experience IPv6 *policy* which has been perhaps more restrictive, inflexible and badly defined than necessary, and in particular address allocation policy. Thankfully this is well on the way to being changed, particularly after the developments of the last RIPE meeting. If you are interested, you should contribute; that way we all benefit from your insights. Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/ From nurani at ripe.net Thu Oct 11 17:34:10 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 11 Oct 2001 17:34:10 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <20011011135050.C23599@enigma.ie> References: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> Message-ID: <5.1.0.14.2.20011011172428.02e426b0@localhost> Just a short comment from the RIR perspective. The issues brought up in this discussion are questions that the RIPE NCC hostmasters are confronted with daily in the IP request handling. Requesters who wish to multi-home (for one reason or the other) often ask the hostmasters for advise on whether to do it with PI address space or by having their upstream announcing a more specific route within a PA aggregate (which is then also separately announced through a second upstream). Rather than the RIRs giving advise on these operational matters, we think it would be appropriate and helpful if these recommendations would come from the ISP community. A few BCPs or guideline documents would be useful to point these requesters to. Could this be an initiative for the routing-wg? Kind regards, Nurani Nimpuno RIPE NCC At 11/10/01 13:50 +0100, Niall Richard Murphy wrote: >On Thu, Oct 11, 2001 at 09:16:41AM +0100, Peter Galbavy wrote: > >Hi Peter, > > > Trying to solve the problem of people not trusting ISPs by changing the > > technology to ensure that people *must* trust one ISP (IPv6 IMHO is just > > such a technology) is not a very customer friendly attitude. It does not > > work and will not work. > >Not that I know anything, but in my opinion, you are inaccurate in two >respects here. > >Firstly, IPv6 *technology* is not the issue. You can do everything that >you could do in IPv4 with IPv6, and this includes the current methodology for >multihoming. It also introduces another way of multihoming, which is akin >to taking PA space from multiple upstreams and initiating/receiving >connections >according to some well defined algorithms. > >I don't think there is any case to be made that the technology forces >a user to trust one ISP. > >Secondly, however, it has been in my limited experience IPv6 *policy* >which has been perhaps more restrictive, inflexible and badly defined >than necessary, and in particular address allocation policy. Thankfully >this is well on the way to being changed, particularly after the developments >of the last RIPE meeting. If you are interested, you should contribute; >that way we all benefit from your insights. > >Niall > >-- >Enigma Consulting Limited: Security, UNIX and telecommunications consultants. >Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. >http://www.enigma.ie/ From kurtis at kpnqwest.net Thu Oct 11 15:45:27 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Thu, 11 Oct 2001 15:45:27 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: <20011011054150.I2763@lucky.net> Message-ID: > Don't forget about cheap sattelite channels :-) > > Lets imagine situation - customer in a country, where all terrastical long- > range channels are controlled by one big pro-government PTT. There isn't POPs > of any of "Tier-1 bla bla bla" providers. All of them can be reached only by > expensive long-rage terrastical or (less expensive) sattelite channel. Well, this can ofcourse then be taken to the extreme. Let's assume that I am cost concious resdient with a sattelite down-link (yupp, they exist), and a DSL line and a Cable link. Should I not be allowed the same easy choice of up-link as the corporate world? Let's then assume that I have my home on VoIP only so NAT is out. Do I get my own AS-number and PA space then? I think we all agree that the current routing model is broken and no longer does what we would expect it to do. However, I think Randy is right in that this will take at least 5 years to redo though. Just look at addressing / CIDR /IPv6. That has taken what, 8 years? At least, and we are not really near any deployment. A CIDR like solution of this is simple. Filter. > In this situation the most popular solution for local customer, who needs > reliable and cheap IP uplink and high speed access to regional Internet > resources, is to build two channels to local ISPs (not so reliable, but much > more cheaper than even one external uplink) and to local IX. IXes are a bad example as just beeing present won't do. You need to get peers as well. And if you are a company my guess is that most providers rather sell you bandwidth than peer. - kurtis - From kurtis at kpnqwest.net Thu Oct 11 16:12:21 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Thu, 11 Oct 2001 16:12:21 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: <01d701c1522d$49da3e10$5d00a8c0@interhouse.redbus.com> Message-ID: > > And in what way would my own AS number and PA space give me more last-mile > > providers? > > Potential for independence from any one supplier. The point was that there only was a single last-mile provider. Then a /8 and AS1 won't give you protection againt local-tail failures. - kurtis - From PLu at cw.net Thu Oct 11 17:02:07 2001 From: PLu at cw.net (Lu, Ping) Date: Thu, 11 Oct 2001 11:02:07 -0400 Subject: Multihoming - Resilience or Independence Message-ID: > -----Original Message----- > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki at hp.com] > Sent: Wednesday, October 10, 2001 1:10 PM > To: lir-wg at ripe.net; routing-wg at ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > Hi, > It seems multihoming discussion is an example of vicious > circle (sp): More > specific routes result in larger routing table but we want > those routes and > small table... Let me suggest a blasphemy: CIDR being > advertised from two > ASes. They say it should be only one, but why? In my opinion there is > nothing wrong in advertising CIDR from two ASes as long as > you can guarantee > each border router advertises CIDR only if it can reach it. > Imagine the > following construction: > AS-A--\ > +(OSPF) --(CIDR) > AS-B--/ > That's the problem. When customer want to be muitl-homed you can't tell them to use which ISP ? If the original prefix are not in the CIDR with the other ISP then the customer have to change all their IP address. If they don't then the second ISP have to leak the original prefix into global routing table. The question is how do you convince your customer to change all their IP addresses to have a second link without the risk of losing its business ? > Each BGP speaker advertises CIDR if and only if it learned > about it from > OSPF. It can be done, if you don't know how I'll forward you a working > example. Each border router generates a default router and > injects it into > OSPF. From technical point of view I see no reasons why it > should not work. > What you need is: > * An agreement between ISPs > * Change in procedure making such a union of ASes an > officially blessed > solution so nobody would dare to hinder cooperation with filters. > * Optionally you may need a separate CIDR, since both ASes > have to advertise > same prefix. You need it if each ISP wants to have private > customers in > addition to shared ones. > > The customer has "an independent connection to two ISPs" > which is the quest > item. I see more commercial than technical problems with such > a solution. > However my expertise is limited and somebody can point > drawbacks I cannot > see. Feel free to burn me on a stake, that's the right way of > treating a > blasphemy ;-) > Regards, > Jacek > It is a good idea but not easy to implement under the pressure of making revenue. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From PLu at cw.net Thu Oct 11 17:23:50 2001 From: PLu at cw.net (Lu, Ping) Date: Thu, 11 Oct 2001 11:23:50 -0400 Subject: Multihoming - Resilience or Independence Message-ID: It is odd that I have to agree with you on "customer do need multiple links to different ISPs" but I hope it is not because CW carries other ISP's non-CIDRable prefixes to let you think "CW less" about us. The point is we will aggregate other ISP's prefixes if they are CIDR able. Most of the case are there are holes in the range so CIDR is out-of-question. While the other camp insist to filter out any routes more specific than /20. They are doing nothing to re-allocate their PA assigned to multi-homed customers so CW can CIDR them into /20. The funny thing is the solution are controlled by the other camp but they are all talk but no action. (Or trying to tell you multi-homed is a bad idea because they can't deal with the routing table ). Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: Peter Galbavy [mailto:peter.galbavy at knowtion.net] > Sent: Thursday, October 11, 2001 4:17 AM > To: Kurt Erik Lindqvist KPNQwest; Nipper, Arnold > Cc: lir-wg at ripe.net; routing-wg at ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > > > the basic issue is that multi-homing is *the demand*. And > it's not the > ISP > > > who has to evaluate whether it's the right one but the > *customer*. We > live > > > in a customer - driven world. Money makes the world go round, not > techies. > > > > Is that really what the customer want? Or do they actually > want resilience > > and redundancy? And for that there are other ways... > > I have been watching this thread for a while now, and I > finally cannot help > but stick my oar in. > > There are two very clearly defined camps here; one the > 'technical' camp that > says 'we have many ways of making it work' or 'this is the > only way it will > work' and the other camp is the 'commercial' saying either > 'the customer > does not trust just one ISP' or 'I don't care how it works, > but it must > work'. > > Now, to add just another opinion to the thread, which is > really not that > different to some other but may possibly offer something new; > > In my line of work I have set-up 4 LIRs in the past two years > for companies > that have had either had bad experiences with their ISPs > (usually more than > one serially) or some have had to do all 'reasonable' things > to ensure good, > reliable connectivity for either contractual or due-diligence reasons. > > Regardless of how good an ISP is *now*, there will come a > time when they are > sold, bought, merge or go bust that causes change. My > personal bugbear was > INS. Great in the early days, but within days of > Clueless&Witless buying > them, the whole thing started to come apart. This is not > isolated, and they > are not the only ones at all. > > Also, especially in Europe, ISPs tend to be reliant on 3rd > party local-loop > carriers, even when we are talking about data-centre / > co-location delivery > of services. In the UK, all ISPs exclude 3rd party links from > SLAs. Right. > Good one. > > Trying to solve the problem of people not trusting ISPs by > changing the > technology to ensure that people *must* trust one ISP (IPv6 > IMHO is just > such a technology) is not a very customer friendly attitude. > It does not > work and will not work. > > In every other line of business, it is quite normal to buy > your product or > service from two suppliers, telecoms and Internet are the only real > exceptions. You could also discount other utilities, but > there is an issue > of delivery there that precludes efficient and real > competition, so no more > there please. As the Internet becomes a true necessity for > business, supply > will more and more be selected like any other service, and the same > contingencies will be made. > > So, IMHO, please stop trying to 'solve' the problem by > pretending that you > or any other ISP is reliable, civil and economically viable > and stop trying > to 'solve' the problem by mandating technology solutions that > enforce this > goal. It will not work. > > Peter > > > From randy at psg.com Thu Oct 11 17:44:08 2001 From: randy at psg.com (Randy Bush) Date: Thu, 11 Oct 2001 08:44:08 -0700 Subject: more specific routes in today reality References: <01d701c1522d$49da3e10$5d00a8c0@interhouse.redbus.com> Message-ID: > The point was that there only was a single last-mile provider. Then a /8 > and AS1 won't give you protection againt local-tail failures. which is where, in my small experience, over 90% of the problems occur. randy From peter.galbavy at knowtion.net Thu Oct 11 18:12:02 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 11 Oct 2001 17:12:02 +0100 Subject: more specific routes in today reality References: Message-ID: <038701c1526f$79b5f560$5d00a8c0@interhouse.redbus.com> > The point was that there only was a single last-mile provider. Then a /8 > and AS1 won't give you protection againt local-tail failures. And my point was that many ISPs will one use *one* last-mile provider each, in those territories where there is competition. So taking service from two selected ISPs will bring you services from two last-mile providers in turn. Most ISPs will *not* provide diversely purchased local-loop connections. Peter From manuel at ripe.net Thu Oct 11 18:13:58 2001 From: manuel at ripe.net (Manuel Valente) Date: Thu, 11 Oct 2001 18:13:58 +0200 Subject: ANNOUNCEMENT: Public Release of Asused Message-ID: <20011011181358.597f28c5.manuel@ripe.net> Greetings, The RIPE NCC is pleased to announce the release of asused version 3.64. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The software is written in Perl and uses several Perl modules. Please grab it from: ftp://ftp.ripe.net/tools/asused-3.64.tar.gz ChangeLog for version 3.64: 3.64 Wed Oct 10 14:22:24 2001 * Fixed recognition of inetnum objects with sign in the range. * Broken dates in changed: field now handled properly, without exiting the program. * Fixed failure in case of registry with no allocations. * Recognize mixed case status: fields. 3.63 Tue Aug 21 13:52:04 2001 * Fixed netname handling according to the RIPE223 - now, case doesn't matter, so netnames with different letter-case still match. * There have been reports about Makefile failure with Perl 5.002, due changed format in the output of the MakeMaker. This is fixed now, by using our own stubs in the Makefile.PL. * Couple of strange inetnum objects were found in the DB, namely - 192.0.0.0 - 192.255.255.255, which broke proper recognition of the allocation. Now they are recognized by asused. Still, it's possible that there are other similar objects in DB. Note: Versions 3.61 and 3.62 were not publicly released. -- Manuel Valente - Software Manager - RIPE NCC From gert at space.net Thu Oct 11 18:13:02 2001 From: gert at space.net (Gert Doering) Date: Thu, 11 Oct 2001 18:13:02 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <5.1.0.14.2.20011011172428.02e426b0@localhost>; from nurani@ripe.net on Thu, Oct 11, 2001 at 05:34:10PM +0200 References: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <20011011135050.C23599@enigma.ie> <5.1.0.14.2.20011011172428.02e426b0@localhost> Message-ID: <20011011181302.V16960@Space.Net> Hi, On Thu, Oct 11, 2001 at 05:34:10PM +0200, Nurani Nimpuno wrote: > A few BCPs or guideline documents would be useful to point these requesters > to. > Could this be an initiative for the routing-wg? I agree that such BCP documents would be very useful. The tricky thing is to agree on what "best" means in that context, as everybody seems to disagree on what they think should be the goal... Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jacek_blocki at hp.com Thu Oct 11 20:11:37 2001 From: jacek_blocki at hp.com (BLOCKI,JACEK (HP-Poland,ex1)) Date: Thu, 11 Oct 2001 20:11:37 +0200 Subject: Multihoming - Resilience or Independence Message-ID: <952C79D45561D4119FCE00D0B708C8E002D7DBAA@lem.poland.hp.com> Hi, The customer will of course use 2 ISP - as requested. He will use addresses coming from a single PA block advertised by two providers. Of course you need to ensure 100% up connection between border routers. If connection between border routers is down one of them has to stop advertising PA block. Otherwise you have problem with return traffic. Imagine provider B lost connection to both customer and provider A. If B is still advertising common block some ASes may decide to reach customer over B, but B cannot reach customer network... In order to deliver proposed service providers A and B have to be connected with redundant network, which is quite common. Vicious circle (sp) as I see it: *Providers want small routing tables *Customers 100% up service so they as for resilience *Providers usually have single POP in area *Customers go BGP creating problem for community (table grows) and themselves (BGP expert costs) Solution: Providers enter into cooperation so they can advertise customer addresses over 2 independent BGP speakers. This idea is not very different from existing aggregation. Specific routing information is hidden in a group of ASes instead of single AS. Of course you need some administrative effort (e.g. consistent billing) but from technical point of view it seems feasible. I may be wrong, it won't be for the first time ;-) Regards, Jacek -----Original Message----- From: Lu, Ping [mailto:PLu at cw.net] Sent: Thursday, October 11, 2001 5:02 PM To: 'BLOCKI,JACEK (HP-Poland,ex1)'; lir-wg at ripe.net; routing-wg at ripe.net Subject: RE: Multihoming - Resilience or Independence > -----Original Message----- > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki at hp.com] > Sent: Wednesday, October 10, 2001 1:10 PM > To: lir-wg at ripe.net; routing-wg at ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > Hi, > It seems multihoming discussion is an example of vicious > circle (sp): More > specific routes result in larger routing table but we want > those routes and > small table... Let me suggest a blasphemy: CIDR being > advertised from two > ASes. They say it should be only one, but why? In my opinion there is > nothing wrong in advertising CIDR from two ASes as long as > you can guarantee > each border router advertises CIDR only if it can reach it. > Imagine the > following construction: > AS-A--\ > +(OSPF) --(CIDR) > AS-B--/ > That's the problem. When customer want to be muitl-homed you can't tell them to use which ISP ? If the original prefix are not in the CIDR with the other ISP then the customer have to change all their IP address. If they don't then the second ISP have to leak the original prefix into global routing table. The question is how do you convince your customer to change all their IP addresses to have a second link without the risk of losing its business ? > Each BGP speaker advertises CIDR if and only if it learned > about it from > OSPF. It can be done, if you don't know how I'll forward you a working > example. Each border router generates a default router and > injects it into > OSPF. From technical point of view I see no reasons why it > should not work. > What you need is: > * An agreement between ISPs > * Change in procedure making such a union of ASes an > officially blessed > solution so nobody would dare to hinder cooperation with filters. > * Optionally you may need a separate CIDR, since both ASes > have to advertise > same prefix. You need it if each ISP wants to have private > customers in > addition to shared ones. > > The customer has "an independent connection to two ISPs" > which is the quest > item. I see more commercial than technical problems with such > a solution. > However my expertise is limited and somebody can point > drawbacks I cannot > see. Feel free to burn me on a stake, that's the right way of > treating a > blasphemy ;-) > Regards, > Jacek > It is a good idea but not easy to implement under the pressure of making revenue. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From bortzmeyer at gitoyen.net Thu Oct 11 22:37:36 2001 From: bortzmeyer at gitoyen.net (Stephane Bortzmeyer) Date: Thu, 11 Oct 2001 22:37:36 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <018801c15172$f139c060$0390a8c0@nipper.de> ("Nipper, Arnold" 's message of Wed, 10 Oct 2001 12:04:23 +0200) Message-ID: <200110112037.WAA26825@ludwigV.sources.org> On Wednesday 10 October 2001, at 12 h 4, "Nipper, Arnold" wrote: > there are a lot of reasons why customers want to be multi-homed. And what > I'm seeing here is, that the ISP community is not able to offer such a > service. But instead of blaming the "stupid" customers, ISP should go home > and make their homework. Or, said in an other way: RIPE policies make very difficult to be multihomed, therefore people in RIPEland take a lot of time to explain that multihoming is bad. From PLu at cw.net Thu Oct 11 18:07:20 2001 From: PLu at cw.net (Lu, Ping) Date: Thu, 11 Oct 2001 12:07:20 -0400 Subject: more specific routes in today reality Message-ID: > > Well, this can ofcourse then be taken to the extreme. Let's > assume that I > am cost concious resdient with a sattelite down-link (yupp, > they exist), > and a DSL line and a Cable link. Should I not be allowed the same easy > choice of up-link as the corporate world? > > Let's then assume that I have my home on VoIP only so NAT is > out. Do I get > my own AS-number and PA space then? > You are using three different IP addresses that are dynamically (OK. If you insist statically) assigned to three different links. But how can I reach your web server ? This is different from the corporate world to have the same IP coming in from different links. > I think we all agree that the current routing model is broken and no > longer does what we would expect it to do. However, I think > Randy is right > in that this will take at least 5 years to redo though. Just look at > addressing / CIDR /IPv6. That has taken what, 8 years? At > least, and we > are not really near any deployment. A CIDR like solution of this is > simple. Filter. > Maybe you are willing to black-hole some /24 block like eBay ? > > In this situation the most popular solution for local > customer, who needs > > reliable and cheap IP uplink and high speed access to > regional Internet > > resources, is to build two channels to local ISPs (not so > reliable, but much > > more cheaper than even one external uplink) and to local IX. In this SOHO situation you don't need a seperate entry in the global routing table. Also the point is two links (phone line won't die the same time as the satellite, will they ?) > > IXes are a bad example as just beeing present won't do. You > need to get > peers as well. And if you are a company my guess is that most > providers > rather sell you bandwidth than peer. This is going backward to ask company to have full mesh among all the ISPs ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From arnold.nipper at de-cix.net Thu Oct 11 19:21:31 2001 From: arnold.nipper at de-cix.net (Nipper, Arnold) Date: Thu, 11 Oct 2001 18:21:31 +0100 Subject: Multihoming - Resilience or Independence References: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <20011011135050.C23599@enigma.ie> <5.1.0.14.2.20011011172428.02e426b0@localhost> <20011011181302.V16960@Space.Net> Message-ID: <002f01c15279$2cd595c0$0290a8c0@nipper.de> ----- Original Message ----- From: "Gert Doering" To: "Nurani Nimpuno" Cc: ; Sent: Thursday, October 11, 2001 5:13 PM Subject: Re: Multihoming - Resilience or Independence > Hi, > > On Thu, Oct 11, 2001 at 05:34:10PM +0200, Nurani Nimpuno wrote: > > A few BCPs or guideline documents would be useful to point these requesters > > to. > > Could this be an initiative for the routing-wg? > > I agree that such BCP documents would be very useful. > > The tricky thing is to agree on what "best" means in that context, as > everybody seems to disagree on what they think should be the goal... > BCP does not mean that you only have to propose one solution. -- Arnold From PLu at cw.net Thu Oct 11 21:03:34 2001 From: PLu at cw.net (Lu, Ping) Date: Thu, 11 Oct 2001 15:03:34 -0400 Subject: Multihoming - Resilience or Independence Message-ID: That is very common procedure. In doing that at least 2 entries will be in the global routing table. And that's exactly the intension of the customer so in case one path failed(thus withdrwan properly ) the other path will kick in. If the provider B lost both connections to the customer and provider A then it lost the FULL correct routing table then this is not the issue of filtering /20 anymore. If provider B configure their BGP sessions right then it should withdraw all the routes from provider A and the customer. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki at hp.com] > Sent: Thursday, October 11, 2001 2:12 PM > To: Lu, Ping; lir-wg at ripe.net; routing-wg at ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > Hi, > The customer will of course use 2 ISP - as requested. He will > use addresses > coming from a single PA block advertised by two providers. Of > course you > need to ensure 100% up connection between border routers. If > connection > between border routers is down one of them has to stop > advertising PA block. > Otherwise you have problem with return traffic. Imagine > provider B lost > connection to both customer and provider A. If B is still > advertising common > block some ASes may decide to reach customer over B, but B > cannot reach > customer network... In order to deliver proposed service > providers A and B > have to be connected with redundant network, which is quite common. > > Vicious circle (sp) as I see it: > *Providers want small routing tables > *Customers 100% up service so they as for resilience > *Providers usually have single POP in area > *Customers go BGP creating problem for community (table grows) and > themselves (BGP expert costs) > > Solution: > Providers enter into cooperation so they can advertise > customer addresses > over 2 independent BGP speakers. This idea is not very different from > existing aggregation. Specific routing information is hidden > in a group of > ASes instead of single AS. Of course you need some > administrative effort > (e.g. consistent billing) but from technical point of view it seems > feasible. I may be wrong, it won't be for the first time ;-) > Regards, > Jacek > > > -----Original Message----- > From: Lu, Ping [mailto:PLu at cw.net] > Sent: Thursday, October 11, 2001 5:02 PM > To: 'BLOCKI,JACEK (HP-Poland,ex1)'; lir-wg at ripe.net; > routing-wg at ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > > > -----Original Message----- > > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki at hp.com] > > Sent: Wednesday, October 10, 2001 1:10 PM > > To: lir-wg at ripe.net; routing-wg at ripe.net > > Subject: RE: Multihoming - Resilience or Independence > > > > > > Hi, > > It seems multihoming discussion is an example of vicious > > circle (sp): More > > specific routes result in larger routing table but we want > > those routes and > > small table... Let me suggest a blasphemy: CIDR being > > advertised from two > > ASes. They say it should be only one, but why? In my > opinion there is > > nothing wrong in advertising CIDR from two ASes as long as > > you can guarantee > > each border router advertises CIDR only if it can reach it. > > Imagine the > > following construction: > > AS-A--\ > > +(OSPF) --(CIDR) > > AS-B--/ > > > > That's the problem. When customer want to be muitl-homed you > can't tell them > to use which ISP ? If the original prefix are not in the CIDR > with the other > ISP > then the customer have to change all their IP address. If > they don't then > the second > ISP have to leak the original prefix into global routing table. > > The question is how do you convince your customer to change > all their IP > addresses to > have a second link without the risk of losing its business ? > > > > Each BGP speaker advertises CIDR if and only if it learned > > about it from > > OSPF. It can be done, if you don't know how I'll forward > you a working > > example. Each border router generates a default router and > > injects it into > > OSPF. From technical point of view I see no reasons why it > > should not work. > > What you need is: > > * An agreement between ISPs > > * Change in procedure making such a union of ASes an > > officially blessed > > solution so nobody would dare to hinder cooperation with filters. > > * Optionally you may need a separate CIDR, since both ASes > > have to advertise > > same prefix. You need it if each ISP wants to have private > > customers in > > addition to shared ones. > > > > The customer has "an independent connection to two ISPs" > > which is the quest > > item. I see more commercial than technical problems with such > > a solution. > > However my expertise is limited and somebody can point > > drawbacks I cannot > > see. Feel free to burn me on a stake, that's the right way of > > treating a > > blasphemy ;-) > > Regards, > > Jacek > > > > It is a good idea but not easy to implement under the > pressure of making > revenue. > > > Ping Lu > Cable & Wireless USA > Network Tools and Analysis Group > W: +1-703-292-2359 > E: plu at cw.net > From SchmitzJo at aol.com Thu Oct 11 21:27:37 2001 From: SchmitzJo at aol.com (SchmitzJo at aol.com) Date: Thu, 11 Oct 2001 15:27:37 EDT Subject: Multihoming - Resilience or Independence Message-ID: <62.15462f85.28f74ca9@aol.com> Dear Nurani, you wrote: > Rather than the RIRs giving advise on these operational matters, we think > it would be appropriate and helpful if these recommendations would come > from the ISP community. I fully support this statement. > A few BCPs or guideline documents would be useful to point these > requesters to. Could this be an initiative for the routing-wg? I had some general input on this in the past months. I am also aware that there are some very early drafts which had not been circulated widely. interesting in various ways ;-) I have no objections against discussing this in the Routing WG, even with the initial modest goal of collecting the individual points of view (which would form a suitable basis to further develop the ideas presented). Nonetheless, it is obvious that within the Routing WG the focus is on technical issues only. Anybody who is interested in summarizing and presenting his/hers ideas is welcome to do so. I can easily reserve some time for that in the next Routing WG session in January to give this a focus. Just step up... :-) Thanks Joachim --- JS395-RIPE -- standard disclaimer --- From czmok at lambda-solutions.de Fri Oct 12 02:56:08 2001 From: czmok at lambda-solutions.de (Jan-Ahrent Czmok) Date: Fri, 12 Oct 2001 02:56:08 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <5.1.0.14.2.20011011172428.02e426b0@localhost> References: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <5.1.0.14.2.20011011172428.02e426b0@localhost> Message-ID: <20011012025608.30b546bc.czmok@lambda-solutions.de> On Thu, 11 Oct 2001 17:34:10 +0200 Nurani Nimpuno wrote: > Just a short comment from the RIR perspective. > The issues brought up in this discussion are questions that the RIPE NCC > hostmasters are confronted with daily in the IP request handling. > Requesters who wish to multi-home (for one reason or the other) often ask > the hostmasters for advise on whether to do it with PI address space or by > having their upstream announcing a more specific route within a PA > aggregate (which is then also separately announced through a second upstream). > Rather than the RIRs giving advise on these operational matters, we think > it would be appropriate and helpful if these recommendations would come > from the ISP community. > A few BCPs or guideline documents would be useful to point these requesters > to. > Could this be an initiative for the routing-wg? > Kind regards, > Nurani Nimpuno > RIPE NCC Hi Nuriani, hi lir-wg, hi routing-wg, i am starting to write a BCP / guideline document covering this issue. I would appreciate the help of other network operators, since i do not know all network operators directly. The version(s) of the document can be accessed at www.lambda-solutions.de/bcp/ I already did a first draft covering the items which will be in the document but would appreciate if i could get help from the different operators. I would like to have input from the current practice from: - Level3 - UUnet - Sprint - C&W - Ebone (which i would declare as "major transit provider" because i don't like the terminology about "tier-xyz") and also from the other important downstream isps, how they handle this issues. Also some information from ripe would be handy, if they ACK issue PA assignments or do PI requests for this kind of issue. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From jan.czmok at jippiigroup.com Fri Oct 12 03:37:38 2001 From: jan.czmok at jippiigroup.com (Jan-Ahrent-Czmok) Date: Fri, 12 Oct 2001 03:37:38 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <5.1.0.14.2.20011011172428.02e426b0@localhost> References: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <5.1.0.14.2.20011011172428.02e426b0@localhost> Message-ID: <20011012033738.3e0b51e2.czmok@lambda-solutions.de> On Thu, 11 Oct 2001 17:34:10 +0200 Nurani Nimpuno wrote: > Just a short comment from the RIR perspective. > The issues brought up in this discussion are questions that the RIPE NCC > hostmasters are confronted with daily in the IP request handling. > Requesters who wish to multi-home (for one reason or the other) often ask > the hostmasters for advise on whether to do it with PI address space or by > having their upstream announcing a more specific route within a PA > aggregate (which is then also separately announced through a second upstream). > Rather than the RIRs giving advise on these operational matters, we think > it would be appropriate and helpful if these recommendations would come > from the ISP community. > A few BCPs or guideline documents would be useful to point these requesters > to. > Could this be an initiative for the routing-wg? > Kind regards, > Nurani Nimpuno > RIPE NCC Hi Nuriani, hi lir-wg, hi routing-wg, i am starting to write a BCP / guideline document covering this issue. I would appreciate the help of other network operators, since i do not know all network operators directly. The version(s) of the document can be accessed at www.lambda-solutions.de/bcp/ I already did a first draft covering the items which will be in the document but would appreciate if i could get help from the different operators. I would like to have input from the current practice from: - Level3 - UUnet - Sprint - C&W - Ebone (which i would declare as "major transit provider" because i don't like the terminology about "tier-xyz") and also from the other important downstream isps, how they handle this issues. Also some information from ripe would be handy, if they ACK issue PA assignments or do PI requests for this kind of issue. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From he at uninett.no Fri Oct 12 11:36:55 2001 From: he at uninett.no (Havard Eidnes) Date: Fri, 12 Oct 2001 11:36:55 +0200 (CEST) Subject: Multihoming - Resilience or Independence In-Reply-To: References: Message-ID: <20011012.113655.91560780.he@uninett.no> > On Wed, 10 Oct 2001, Randy Bush wrote: > > > the basic issue is that multi-homing is *the demand*. And it's > > > not the ISP who has to evaluate whether it's the right one but > > > the *customer*. We live in a customer - driven world. Money > > > makes the world go round, not techies. > > > > not a problem. they can demand all they want. but i will listen > > to their flakey routes when they *pay* me to do so. > > No flame intended here, but aren't your customers already paying you > to get the best connectivity to remote sites? Presumably the customers also want this connectivity to be reasonably stable? If there is a conflict between "stable connectivity to most of the Internet" or "not quite so stable connectivity to everywhere", I think it's a no-brainer for an ISP to choose between the two. This in combination with a certain dose of defensive conservatism is what caused the birth of "route filtering on RIR allocation boundaries". > Of course I see the point in filling up 128megs of ram with routing > tables but I ask myself what costs more; 128megs of extra ram or > customers running off to another ISP because that has better > connectivity to their favorite site? As has been said in other venues many other times: it's not just the cost of the DRAM that's the issue here. Certain CPU boards or router systems typically have a maximum amount of memory which can be installed, and there's a certain "step function" associated with crossing that limit, and the price increase is quite a bit higher than the cost of an additional 128MB module. Secondly, trying to solve this problem by just throwing more memory at the problem is likely to expose other scalability problems caused by a large default-free routing table, such as excessive convergence times, CPU horsepower deficiencies to keep up with doing the route computation in the face of an increasing stream of routing updates etc. etc. etc. The real worry has however been that the growth in the default-free routing table has in the past exceeded the growth predicted by "Moore's law" (which in the past has reasonably well predicted the electronics component manufacturers' ability to produce faster or higher-density components, be that CPUs, DRAMs or what have you), which does not bode well for the longer-term success of the approach of "throwing hardware at the problem". So, it's some peoples' opinion that if this problem is going to be solved properly (in a properly scalable fashion), we probably need a new routing and addressing paradigm. It is my current personal opinion that in this context IPv6 doesn't really contribute anything up and above IPv4's routing architecture except "more of the same" (i.e. longer addresses, but still holding on to most other aspects of the IPv4 routing architecture). However, let's just say that I'm not holding my breath while waiting... Regards, - H?vard From PLu at cw.net Thu Oct 11 21:03:34 2001 From: PLu at cw.net (Lu, Ping) Date: Thu, 11 Oct 2001 15:03:34 -0400 Subject: Multihoming - Resilience or Independence Message-ID: That is very common procedure. In doing that at least 2 entries will be in the global routing table. And that's exactly the intension of the customer so in case one path failed(thus withdrwan properly ) the other path will kick in. If the provider B lost both connections to the customer and provider A then it lost the FULL correct routing table then this is not the issue of filtering /20 anymore. If provider B configure their BGP sessions right then it should withdraw all the routes from provider A and the customer. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki at hp.com] > Sent: Thursday, October 11, 2001 2:12 PM > To: Lu, Ping; lir-wg at ripe.net; routing-wg at ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > Hi, > The customer will of course use 2 ISP - as requested. He will > use addresses > coming from a single PA block advertised by two providers. Of > course you > need to ensure 100% up connection between border routers. If > connection > between border routers is down one of them has to stop > advertising PA block. > Otherwise you have problem with return traffic. Imagine > provider B lost > connection to both customer and provider A. If B is still > advertising common > block some ASes may decide to reach customer over B, but B > cannot reach > customer network... In order to deliver proposed service > providers A and B > have to be connected with redundant network, which is quite common. > > Vicious circle (sp) as I see it: > *Providers want small routing tables > *Customers 100% up service so they as for resilience > *Providers usually have single POP in area > *Customers go BGP creating problem for community (table grows) and > themselves (BGP expert costs) > > Solution: > Providers enter into cooperation so they can advertise > customer addresses > over 2 independent BGP speakers. This idea is not very different from > existing aggregation. Specific routing information is hidden > in a group of > ASes instead of single AS. Of course you need some > administrative effort > (e.g. consistent billing) but from technical point of view it seems > feasible. I may be wrong, it won't be for the first time ;-) > Regards, > Jacek > > > -----Original Message----- > From: Lu, Ping [mailto:PLu at cw.net] > Sent: Thursday, October 11, 2001 5:02 PM > To: 'BLOCKI,JACEK (HP-Poland,ex1)'; lir-wg at ripe.net; > routing-wg at ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > > > -----Original Message----- > > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki at hp.com] > > Sent: Wednesday, October 10, 2001 1:10 PM > > To: lir-wg at ripe.net; routing-wg at ripe.net > > Subject: RE: Multihoming - Resilience or Independence > > > > > > Hi, > > It seems multihoming discussion is an example of vicious > > circle (sp): More > > specific routes result in larger routing table but we want > > those routes and > > small table... Let me suggest a blasphemy: CIDR being > > advertised from two > > ASes. They say it should be only one, but why? In my > opinion there is > > nothing wrong in advertising CIDR from two ASes as long as > > you can guarantee > > each border router advertises CIDR only if it can reach it. > > Imagine the > > following construction: > > AS-A--\ > > +(OSPF) --(CIDR) > > AS-B--/ > > > > That's the problem. When customer want to be muitl-homed you > can't tell them > to use which ISP ? If the original prefix are not in the CIDR > with the other > ISP > then the customer have to change all their IP address. If > they don't then > the second > ISP have to leak the original prefix into global routing table. > > The question is how do you convince your customer to change > all their IP > addresses to > have a second link without the risk of losing its business ? > > > > Each BGP speaker advertises CIDR if and only if it learned > > about it from > > OSPF. It can be done, if you don't know how I'll forward > you a working > > example. Each border router generates a default router and > > injects it into > > OSPF. From technical point of view I see no reasons why it > > should not work. > > What you need is: > > * An agreement between ISPs > > * Change in procedure making such a union of ASes an > > officially blessed > > solution so nobody would dare to hinder cooperation with filters. > > * Optionally you may need a separate CIDR, since both ASes > > have to advertise > > same prefix. You need it if each ISP wants to have private > > customers in > > addition to shared ones. > > > > The customer has "an independent connection to two ISPs" > > which is the quest > > item. I see more commercial than technical problems with such > > a solution. > > However my expertise is limited and somebody can point > > drawbacks I cannot > > see. Feel free to burn me on a stake, that's the right way of > > treating a > > blasphemy ;-) > > Regards, > > Jacek > > > > It is a good idea but not easy to implement under the > pressure of making > revenue. > > > Ping Lu > Cable & Wireless USA > Network Tools and Analysis Group > W: +1-703-292-2359 > E: plu at cw.net > From jan.czmok at jippiigroup.com Fri Oct 12 03:37:38 2001 From: jan.czmok at jippiigroup.com (Jan-Ahrent-Czmok) Date: Fri, 12 Oct 2001 03:37:38 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <5.1.0.14.2.20011011172428.02e426b0@localhost> References: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <5.1.0.14.2.20011011172428.02e426b0@localhost> Message-ID: <20011012033738.3e0b51e2.czmok@lambda-solutions.de> On Thu, 11 Oct 2001 17:34:10 +0200 Nurani Nimpuno wrote: > Just a short comment from the RIR perspective. > The issues brought up in this discussion are questions that the RIPE NCC > hostmasters are confronted with daily in the IP request handling. > Requesters who wish to multi-home (for one reason or the other) often ask > the hostmasters for advise on whether to do it with PI address space or by > having their upstream announcing a more specific route within a PA > aggregate (which is then also separately announced through a second upstream). > Rather than the RIRs giving advise on these operational matters, we think > it would be appropriate and helpful if these recommendations would come > from the ISP community. > A few BCPs or guideline documents would be useful to point these requesters > to. > Could this be an initiative for the routing-wg? > Kind regards, > Nurani Nimpuno > RIPE NCC Hi Nuriani, hi lir-wg, hi routing-wg, i am starting to write a BCP / guideline document covering this issue. I would appreciate the help of other network operators, since i do not know all network operators directly. The version(s) of the document can be accessed at www.lambda-solutions.de/bcp/ I already did a first draft covering the items which will be in the document but would appreciate if i could get help from the different operators. I would like to have input from the current practice from: - Level3 - UUnet - Sprint - C&W - Ebone (which i would declare as "major transit provider" because i don't like the terminology about "tier-xyz") and also from the other important downstream isps, how they handle this issues. Also some information from ripe would be handy, if they ACK issue PA assignments or do PI requests for this kind of issue. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From czmok at lambda-solutions.de Fri Oct 12 02:56:08 2001 From: czmok at lambda-solutions.de (Jan-Ahrent Czmok) Date: Fri, 12 Oct 2001 02:56:08 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <5.1.0.14.2.20011011172428.02e426b0@localhost> References: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <5.1.0.14.2.20011011172428.02e426b0@localhost> Message-ID: <20011012025608.30b546bc.czmok@lambda-solutions.de> On Thu, 11 Oct 2001 17:34:10 +0200 Nurani Nimpuno wrote: > Just a short comment from the RIR perspective. > The issues brought up in this discussion are questions that the RIPE NCC > hostmasters are confronted with daily in the IP request handling. > Requesters who wish to multi-home (for one reason or the other) often ask > the hostmasters for advise on whether to do it with PI address space or by > having their upstream announcing a more specific route within a PA > aggregate (which is then also separately announced through a second upstream). > Rather than the RIRs giving advise on these operational matters, we think > it would be appropriate and helpful if these recommendations would come > from the ISP community. > A few BCPs or guideline documents would be useful to point these requesters > to. > Could this be an initiative for the routing-wg? > Kind regards, > Nurani Nimpuno > RIPE NCC Hi Nuriani, hi lir-wg, hi routing-wg, i am starting to write a BCP / guideline document covering this issue. I would appreciate the help of other network operators, since i do not know all network operators directly. The version(s) of the document can be accessed at www.lambda-solutions.de/bcp/ I already did a first draft covering the items which will be in the document but would appreciate if i could get help from the different operators. I would like to have input from the current practice from: - Level3 - UUnet - Sprint - C&W - Ebone (which i would declare as "major transit provider" because i don't like the terminology about "tier-xyz") and also from the other important downstream isps, how they handle this issues. Also some information from ripe would be handy, if they ACK issue PA assignments or do PI requests for this kind of issue. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404 From arnold.nipper at de-cix.net Thu Oct 11 19:21:31 2001 From: arnold.nipper at de-cix.net (Nipper, Arnold) Date: Thu, 11 Oct 2001 18:21:31 +0100 Subject: Multihoming - Resilience or Independence References: <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <01cb01c1522d$11b58800$5d00a8c0@interhouse.redbus.com> <20011011135050.C23599@enigma.ie> <5.1.0.14.2.20011011172428.02e426b0@localhost> <20011011181302.V16960@Space.Net> Message-ID: <002f01c15279$2cd595c0$0290a8c0@nipper.de> ----- Original Message ----- From: "Gert Doering" To: "Nurani Nimpuno" Cc: ; Sent: Thursday, October 11, 2001 5:13 PM Subject: Re: Multihoming - Resilience or Independence > Hi, > > On Thu, Oct 11, 2001 at 05:34:10PM +0200, Nurani Nimpuno wrote: > > A few BCPs or guideline documents would be useful to point these requesters > > to. > > Could this be an initiative for the routing-wg? > > I agree that such BCP documents would be very useful. > > The tricky thing is to agree on what "best" means in that context, as > everybody seems to disagree on what they think should be the goal... > BCP does not mean that you only have to propose one solution. -- Arnold From SchmitzJo at aol.com Thu Oct 11 21:27:37 2001 From: SchmitzJo at aol.com (SchmitzJo at aol.com) Date: Thu, 11 Oct 2001 15:27:37 EDT Subject: Multihoming - Resilience or Independence Message-ID: <62.15462f85.28f74ca9@aol.com> Dear Nurani, you wrote: > Rather than the RIRs giving advise on these operational matters, we think > it would be appropriate and helpful if these recommendations would come > from the ISP community. I fully support this statement. > A few BCPs or guideline documents would be useful to point these > requesters to. Could this be an initiative for the routing-wg? I had some general input on this in the past months. I am also aware that there are some very early drafts which had not been circulated widely. interesting in various ways ;-) I have no objections against discussing this in the Routing WG, even with the initial modest goal of collecting the individual points of view (which would form a suitable basis to further develop the ideas presented). Nonetheless, it is obvious that within the Routing WG the focus is on technical issues only. Anybody who is interested in summarizing and presenting his/hers ideas is welcome to do so. I can easily reserve some time for that in the next Routing WG session in January to give this a focus. Just step up... :-) Thanks Joachim --- JS395-RIPE -- standard disclaimer --- From bortzmeyer at gitoyen.net Thu Oct 11 22:37:36 2001 From: bortzmeyer at gitoyen.net (Stephane Bortzmeyer) Date: Thu, 11 Oct 2001 22:37:36 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <018801c15172$f139c060$0390a8c0@nipper.de> ("Nipper, Arnold" 's message of Wed, 10 Oct 2001 12:04:23 +0200) Message-ID: <200110112037.WAA26825@ludwigV.sources.org> On Wednesday 10 October 2001, at 12 h 4, "Nipper, Arnold" wrote: > there are a lot of reasons why customers want to be multi-homed. And what > I'm seeing here is, that the ISP community is not able to offer such a > service. But instead of blaming the "stupid" customers, ISP should go home > and make their homework. Or, said in an other way: RIPE policies make very difficult to be multihomed, therefore people in RIPEland take a lot of time to explain that multihoming is bad. From PLu at cw.net Thu Oct 11 18:07:20 2001 From: PLu at cw.net (Lu, Ping) Date: Thu, 11 Oct 2001 12:07:20 -0400 Subject: more specific routes in today reality Message-ID: > > Well, this can ofcourse then be taken to the extreme. Let's > assume that I > am cost concious resdient with a sattelite down-link (yupp, > they exist), > and a DSL line and a Cable link. Should I not be allowed the same easy > choice of up-link as the corporate world? > > Let's then assume that I have my home on VoIP only so NAT is > out. Do I get > my own AS-number and PA space then? > You are using three different IP addresses that are dynamically (OK. If you insist statically) assigned to three different links. But how can I reach your web server ? This is different from the corporate world to have the same IP coming in from different links. > I think we all agree that the current routing model is broken and no > longer does what we would expect it to do. However, I think > Randy is right > in that this will take at least 5 years to redo though. Just look at > addressing / CIDR /IPv6. That has taken what, 8 years? At > least, and we > are not really near any deployment. A CIDR like solution of this is > simple. Filter. > Maybe you are willing to black-hole some /24 block like eBay ? > > In this situation the most popular solution for local > customer, who needs > > reliable and cheap IP uplink and high speed access to > regional Internet > > resources, is to build two channels to local ISPs (not so > reliable, but much > > more cheaper than even one external uplink) and to local IX. In this SOHO situation you don't need a seperate entry in the global routing table. Also the point is two links (phone line won't die the same time as the satellite, will they ?) > > IXes are a bad example as just beeing present won't do. You > need to get > peers as well. And if you are a company my guess is that most > providers > rather sell you bandwidth than peer. This is going backward to ask company to have full mesh among all the ISPs ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From alipour at mail.dci.co.ir Sat Oct 13 13:45:32 2001 From: alipour at mail.dci.co.ir (Hamid Alipour) Date: Sat, 13 Oct 2001 15:15:32 +0330 Subject: Multihoming - Resilience or Independence References: <20011012.113655.91560780.he@uninett.no> Message-ID: <010701c153dc$94d0b1a0$223b92c3@itc.ir> would IP address defragmentation of Multi homed ISPs help to condense the BGP routing tables? two multi home ISPs with one prefix each will take the same routing table space as one multi homed ISP with two prefixes Regards, Hamid Alipour From aledm at qix.co.uk Fri Oct 12 14:58:44 2001 From: aledm at qix.co.uk (Aled Morris) Date: Fri, 12 Oct 2001 13:58:44 +0100 (BST) Subject: Multihoming - Resilience or Independence In-Reply-To: <200110112037.WAA26825@ludwigV.sources.org> Message-ID: On Thu, 11 Oct 2001, Stephane Bortzmeyer wrote: >Or, said in an other way: RIPE policies make very difficult to be multihomed, >therefore people in RIPEland take a lot of time to explain that multihoming is >bad. RIPE doesn't make up the policies - the members make the policies. RIPE didn't invent IP either, nor did they have a say in the design of router architecture, nor in the pricing of RAM chips. Multihoming which relies on long prefixes being carried in the default free zone, and/or more AS numbers, simply doesn't scale. That isn't a policy matter, it's simple math. Which policy do you think should be changed in order to "solve" the multihoming problem? Aled -- QiX Limited From aid at vianw.net Fri Oct 12 16:16:49 2001 From: aid at vianw.net (Adrian Bool) Date: Fri, 12 Oct 2001 15:16:49 +0100 Subject: Multihoming - Resilience or Independence In-Reply-To: <020201c15179$ae22e660$0390a8c0@nipper.de> References: <20011010124248.Z16960@Space.Net> <020201c15179$ae22e660$0390a8c0@nipper.de> Message-ID: <01101215164909.09106@ewe.noc.u-net.net> Hi All, On Wednesday 10 October 2001 11:52, Nipper, Arnold wrote: > I still can't see why the idea of having own netblocks and AS for > multi-homing customers breaks if one ISP is going south. But of course > there are other and more financial drawbacks with this approach. > > > The new mantra is: go home and do your homework I agreed with Arnold, that networks should be able to muli-home without the feeling that they are breaking the Internet. Of course that is sadly the case today. So, as per Arnold's suggestion, I did some homework on an alternative solution, basically to IPv6. This is only the first thoughts, just to get the main points across. Its is far from complete! If you can spare the time, wander to, http://logic.org.uk/ip-1.0.txt and see what you think. Regards, aid -- Adrian Bool | http://noc.vianetworks.net/ Director, Global Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ From kurtis at kpnqwest.net Mon Oct 15 08:38:28 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Mon, 15 Oct 2001 08:38:28 +0200 (MEST) Subject: Multihoming - Resilience or Independence In-Reply-To: Message-ID: > The point is we will aggregate other ISP's prefixes if they are CIDR able. > Most of the case > are there are holes in the range so CIDR is out-of-question. > > While the other camp insist to filter out any routes more specific than /20. > They are doing nothing to re-allocate their PA assigned to multi-homed > customers so CW can CIDR them into /20. > > The funny thing is the solution are controlled by the other camp but they > are all talk but > no action. (Or trying to tell you multi-homed is a bad idea because they > can't deal with the > routing table ). I am not sure I am following you here. Are you saying that we should re-adress customers so that we get larger blocks of PA space to give to mulithomed customers? I think that re-addressing is pretty hard to do in any larger scale, although that would certanly help some other issues. another good start would be to start reclaiming space that has been handed out from various ISPs old B-space and later taken with the customer. I know a few operators that have done that (including us to some extent), and it's a rather demanding task but will help the operators and reudce the routing table as well. - kurtis - From kurtis at kpnqwest.net Mon Oct 15 08:58:44 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Mon, 15 Oct 2001 08:58:44 +0200 (MEST) Subject: Multihoming - Resilience or Independence In-Reply-To: <5.1.0.14.2.20011011172428.02e426b0@localhost> Message-ID: > A few BCPs or guideline documents would be useful to point these requesters > to. > Could this be an initiative for the routing-wg? IMHO - yes. If we could come up with a common policy to handle these requests it would be better for all. - kurtis - From kurtis at kpnqwest.net Mon Oct 15 09:06:34 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Mon, 15 Oct 2001 09:06:34 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: Message-ID: > > assume that I > > am cost concious resdient with a sattelite down-link (yupp, > > they exist), > > and a DSL line and a Cable link. Should I not be allowed the same easy > > choice of up-link as the corporate world? > > > > Let's then assume that I have my home on VoIP only so NAT is > > out. Do I get > > my own AS-number and PA space then? > > > > You are using three different IP addresses that are dynamically (OK. If you > insist statically) assigned to three different links. But how can I reach > your web server ? > This is different from the corporate world to have the same IP coming in > from different links. If I only have three addresses I need some form of NAT on my home network, and that will brak my services as well as block the Web-server, just as point out. So I need a routable block. > > > In this situation the most popular solution for local > > customer, who needs > > > reliable and cheap IP uplink and high speed access to > > regional Internet > > > resources, is to build two channels to local ISPs (not so > > reliable, but much > > > more cheaper than even one external uplink) and to local IX. > > In this SOHO situation you don't need a seperate entry in the > global routing table. Also the point is two links (phone line won't > die the same time as the satellite, will they ?) No, but in order to use this Sat uplink I need to have globally routable address block. Which will pollut the routigtable. So in my extream example, we would end up with a address block per SOHO user. - kurtis - From kurtis at kpnqwest.net Mon Oct 15 09:09:42 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Mon, 15 Oct 2001 09:09:42 +0200 (MEST) Subject: yRe: more specific routes in today reality In-Reply-To: <038701c1526f$79b5f560$5d00a8c0@interhouse.redbus.com> Message-ID: > And my point was that many ISPs will one use *one* last-mile provider each, > in those territories where there is competition. So taking service from two > selected ISPs will bring you services from two last-mile providers in turn. > > Most ISPs will *not* provide diversely purchased local-loop connections. This will vary alot, depending on country. In some countries, you will find one provider giving you redundant connections, you will find carriers using dual providers, and you will find countries that still have a PTT monopoly. There is not a "single" scenario. This however, does not mean though that multiple uplinks to more than one provider gives you more security than mulitple uplinks to one. - kurtis - From peter.galbavy at knowtion.net Mon Oct 15 10:27:04 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Mon, 15 Oct 2001 09:27:04 +0100 Subject: more specific routes in today reality References: Message-ID: <00c401c15553$2ed56cb0$5d00a8c0@interhouse.redbus.com> > This however, does not mean though that multiple uplinks to more than one > provider gives you more security than mulitple uplinks to one. I completely disagree with you. Multiple links may have failure modes in addition to and identical to some of the failure modes of a single connection, but multiple links also removes a complete calls of failure modes associated with a single connection. This is a pretty fundemental tenet of communications systems in general as is not limited to IP. Peter From peter.galbavy at knowtion.net Mon Oct 15 10:30:40 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Mon, 15 Oct 2001 09:30:40 +0100 Subject: Multihoming - Resilience or Independence References: Message-ID: <010101c15553$afb202d0$5d00a8c0@interhouse.redbus.com> > RIPE doesn't make up the policies - the members make the policies. Member involvement in RIPE is the same as with most 'standards' bodies. A very small %age of the membership understand the weird (acadaemia originated) processes and the beaurocrary required to be involved. Most members just want a service... Peter From peter.galbavy at knowtion.net Mon Oct 15 11:03:40 2001 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Mon, 15 Oct 2001 10:03:40 +0100 Subject: more specific routes in today reality References: <00c401c15553$2ed56cb0$5d00a8c0@interhouse.redbus.com> Message-ID: <024f01c15558$4bf931f0$5d00a8c0@interhouse.redbus.com> > a complete calls of failure modes associated with a single connection. s/calls/class/ of course :) Peter From nurani at ripe.net Mon Oct 15 12:16:01 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Mon, 15 Oct 2001 12:16:01 +0200 Subject: Multihoming - Resilience or Independence In-Reply-To: <010101c15553$afb202d0$5d00a8c0@interhouse.redbus.com> References: Message-ID: <5.1.0.14.2.20011015112804.02f39660@localhost> All, A clarification: The policies implemented by the RIPE NCC are set by the Internet community (i.e the RIPE community). The RIPE community is open to everyone who is interested in the workings of the Internet. The RIPE community has no formal membership and its activities are performed on a voluntary basis, except the activities performed by the RIPE NCC (http://www.ripe.net/ripencc/about/). You do not have to be a member of the RIPE NCC to suggest a change of policy or to raise an issue you think needs to be discussed. There are no complicated processes or steps involved to change policy. All you need to do is to post a mail to the relevant mailing list (for policy matters it is ) or to bring it up one of the working groups in a RIPE meeting. If, after some discussion in relevant working group, consensus is reached, then the RIPE NCC will implement this policy. Kind regards, Nurani Nimpuno RIPE NCC At 15/10/01 09:30 +0100, Peter Galbavy wrote: > > RIPE doesn't make up the policies - the members make the policies. > >Member involvement in RIPE is the same as with most 'standards' bodies. A >very small %age of the membership understand the weird (acadaemia >originated) processes and the beaurocrary required to be involved. Most >members just want a service... > >Peter From kurtis at kpnqwest.net Mon Oct 15 11:07:12 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Mon, 15 Oct 2001 11:07:12 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: <00c401c15553$2ed56cb0$5d00a8c0@interhouse.redbus.com> Message-ID: > > This however, does not mean though that multiple uplinks to more than one > > provider gives you more security than mulitple uplinks to one. > > I completely disagree with you. > > Multiple links may have failure modes in addition to and identical to some > of the failure modes of a single connection, but multiple links also removes > a complete calls of failure modes associated with a single connection. > > This is a pretty fundemental tenet of communications systems in general as > is not limited to IP. Well, teoretically this is certanly true. However, looking at reality, I don't think this is wort an extra entry in the global routing table, and where do this stop? How about the SOHO user that I described? Why are not they allowed broken up PA or PI space to be multihomed? - kurtis - From michael.hallgren at Teleglobe.com Mon Oct 15 13:23:55 2001 From: michael.hallgren at Teleglobe.com (Hallgren, Michael) Date: Mon, 15 Oct 2001 12:23:55 +0100 Subject: more specific routes in today reality Message-ID: > > > This however, does not mean though that multiple uplinks to > more than one > > provider gives you more security than mulitple uplinks to one. > > I completely disagree with you. > So do I (at least in this little part of the thread, which I haven't had the opportunity to follow at all length). For example, a provider-wide routing (or performance, or whatever) problem would be your problem if homed only to that one provider. > Multiple links may have failure modes in addition to and > identical to some > of the failure modes of a single connection, but multiple > links also removes > a complete calls of failure modes associated with a single connection. > > This is a pretty fundemental tenet of communications systems > in general as > is not limited to IP. > mh > Peter > > From gert at space.net Mon Oct 15 13:33:39 2001 From: gert at space.net (Gert Doering) Date: Mon, 15 Oct 2001 13:33:39 +0200 Subject: more specific routes in today reality In-Reply-To: ; from michael.hallgren@Teleglobe.com on Mon, Oct 15, 2001 at 12:23:55PM +0100 References: Message-ID: <20011015133339.H40342@Space.Net> Hi, On Mon, Oct 15, 2001 at 12:23:55PM +0100, Hallgren, Michael wrote: > > > This however, does not mean though that multiple uplinks to > > more than one > > > provider gives you more security than mulitple uplinks to one. > > > > I completely disagree with you. > > So do I (at least in this little part of the thread, which I haven't > had the opportunity to follow at all length). For example, a provider-wide > routing (or performance, or whatever) problem would be your problem if > homed only to that one provider. Yes. But if one ISP really messes up his routing, he can still blackhole his multi-homed customers as well (like "redistribute IGP into BGP, announce that as more-specifics into the global table and get all the traffic for the netblock in question"). On the other hand: how many "provider wide routing outages" have you seen recently in business provider networks (that haven't been fixed more quickly than a customer would have needed to figure out what's going on and disconnect one upstream to get rid of those problems)? Be realistic about what outage scenarios you're planning for. I still think that for most outages these days, it's sufficient to get multiple uplinks to the same ISP (maybe to different POPs). This will also take care of "the local router at the customer falls down due to BGP table growth and out of memory" (or other BGP related problems), which IS something that a strategy for maximum reliability has to take into account. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From kurtis at kpnqwest.net Mon Oct 15 13:33:25 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Mon, 15 Oct 2001 13:33:25 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: Message-ID: > > > This however, does not mean though that multiple uplinks to > > more than one > > > provider gives you more security than mulitple uplinks to one. > > > > I completely disagree with you. > > > > So do I (at least in this little part of the thread, which I haven't > had the opportunity to follow at all length). For example, a provider-wide > routing (or performance, or whatever) problem would be your problem if > homed only to that one provider. If it is a outage and you are running BGP you will need to wait for your router to converge. In worst case you will be dragged into the routing problems. However, I agree with Randy that 90% of outages are due to local-tail problems. I agree that two links to two operators are more reliable, but the real questions are if they are enough MORE reliable to justify the extra routes, and if so how do we implement this? And this should be a general solution all the way down to the residential users... I am not conviced that having multiple upstreams for entrprises, SOHO, residentials or even small ISPs are worth it. - kurtis - From kurtis at kpnqwest.net Mon Oct 15 13:37:17 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Mon, 15 Oct 2001 13:37:17 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: Message-ID: > > So do I (at least in this little part of the thread, which I haven't > > had the opportunity to follow at all length). For example, a provider-wide > > routing (or performance, or whatever) problem would be your problem if > > homed only to that one provider. > > > If it is a outage and you are running BGP you will need to wait for your > router to converge. In worst case you will be dragged into the routing > problems. However, I agree with Randy that 90% of outages are due to > local-tail problems. > > I agree that two links to two operators are more reliable, but the real > questions are if they are enough MORE reliable to justify the extra > routes, and if so how do we implement this? And this should be a general > solution all the way down to the residential users... > > I am not conviced that having multiple upstreams for entrprises, SOHO, > residentials or even small ISPs are worth it. Oh, and BTW. I do think that in the long run we need to address this (among other things) one way to the other, but I don't think that todays routing technologies will scale for it. - kurtis - From michael.hallgren at Teleglobe.com Mon Oct 15 15:17:23 2001 From: michael.hallgren at Teleglobe.com (Hallgren, Michael) Date: Mon, 15 Oct 2001 14:17:23 +0100 Subject: more specific routes in today reality Message-ID: > > > If it is a outage and you are running BGP you will need to > wait for your > router to converge. In worst case you will be dragged into the routing > problems. However, I agree with Randy that 90% of outages are due to > local-tail problems. > > I agree that two links to two operators are more reliable, > but the real > questions are if they are enough MORE reliable to justify the extra > routes, and if so how do we implement this? And this should > be a general > solution all the way down to the residential users... > OK. I went backstreams up the thread. Sure, since we're talking about "all the way down to the residential users..." > I am not conviced that having multiple upstreams for entrprises, SOHO, > residentials or even small ISPs are worth it. OK mh > > - kurtis - > > From gert at space.net Mon Oct 15 16:28:11 2001 From: gert at space.net (Gert Doering) Date: Mon, 15 Oct 2001 16:28:11 +0200 Subject: [hostmaster-staff] Re: MIR proposal / reservation revisited? In-Reply-To: ; from jhma@KPNQwest.net on Mon, Oct 01, 2001 at 09:45:06PM +0200 References: <20011001185535.K16960@Space.Net> Message-ID: <20011015162811.U40342@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From PLu at cw.net Mon Oct 15 17:57:03 2001 From: PLu at cw.net (Lu, Ping) Date: Mon, 15 Oct 2001 11:57:03 -0400 Subject: Multihoming - Resilience or Independence Message-ID: > > > The point is we will aggregate other ISP's prefixes if they > are CIDR able. > > Most of the case > > are there are holes in the range so CIDR is out-of-question. > > > > While the other camp insist to filter out any routes more > specific than /20. > > They are doing nothing to re-allocate their PA assigned to > multi-homed > > customers so CW can CIDR them into /20. > > > > The funny thing is the solution are controlled by the other > camp but they > > are all talk but > > no action. (Or trying to tell you multi-homed is a bad idea > because they > > can't deal with the > > routing table ). > > I am not sure I am following you here. Are you saying that we should > re-adress customers so that we get larger blocks of PA space > to give to > mulithomed customers? > > I think that re-addressing is pretty hard to do in any larger scale, > although that would certanly help some other issues. > That's why filtering /20 only without re-aligning the holes in the block won't work. In the end /20 make the routing table looks pretty but they are black-holing lots of traffic. As we all agree that re-assign address is NOT practical at all thus just filtering /20 block is not a good solution. > another good start would be to start reclaiming space that > has been handed > out from various ISPs old B-space and later taken with the customer. I > know a few operators that have done that (including us to > some extent), > and it's a rather demanding task but will help the operators > and reudce > the routing table as well. > > - kurtis - > I am with you here. Starting from the beginning is much better than asking them to change later. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From PLu at cw.net Mon Oct 15 18:18:40 2001 From: PLu at cw.net (Lu, Ping) Date: Mon, 15 Oct 2001 12:18:40 -0400 Subject: more specific routes in today reality Message-ID: > > > assume that I > > > am cost concious resdient with a sattelite down-link (yupp, > > > they exist), > > > and a DSL line and a Cable link. Should I not be allowed > the same easy > > > choice of up-link as the corporate world? > > > > > > Let's then assume that I have my home on VoIP only so NAT is > > > out. Do I get > > > my own AS-number and PA space then? > > > > > > > You are using three different IP addresses that are > dynamically (OK. If you > > insist statically) assigned to three different links. But > how can I reach > > your web server ? > > This is different from the corporate world to have the same > IP coming in > > from different links. > > If I only have three addresses I need some form of NAT on my > home network, > and that will brak my services as well as block the > Web-server, just as > point out. So I need a routable block. > OK. There are two different requirements here. One is people just want to connect to Internet and have different links for back-up thus no-need for static IP. The problem will be the SOHO customers running application that needs static IP address. Assume they uses /28 then it will be a big problem for the up-stream to leak them into the global routing table. By just filtering out /28 won't solve the problem. But I think it is a little bit easier to make them to be reassigned to the aggregate block with their back-up link provider, don't you think ? This way, we can have the cake and eat it too. > > > > In this situation the most popular solution for local > > > customer, who needs > > > > reliable and cheap IP uplink and high speed access to > > > regional Internet > > > > resources, is to build two channels to local ISPs (not so > > > reliable, but much > > > > more cheaper than even one external uplink) and to local IX. > > > > In this SOHO situation you don't need a seperate entry in the > > global routing table. Also the point is two links (phone line won't > > die the same time as the satellite, will they ?) > > No, but in order to use this Sat uplink I need to have > globally routable > address block. Which will pollut the routigtable. So in my extream > example, we would end up with a address block per SOHO user. > > - kurtis - > My point is still you can have these customers' business and making sure they are ASSIGNED (by you) on the aggregate block so the other ISP can aggregate them. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From PLu at cw.net Mon Oct 15 18:52:24 2001 From: PLu at cw.net (Lu, Ping) Date: Mon, 15 Oct 2001 12:52:24 -0400 Subject: Multihoming - Resilience or Independence Message-ID: > -----Original Message----- > From: Aled Morris [mailto:aledm at qix.co.uk] > Sent: Friday, October 12, 2001 8:59 AM > To: Stephane Bortzmeyer > Cc: Nipper, Arnold; Dave Pratt; lir-wg at ripe.net; routing-wg at ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > On Thu, 11 Oct 2001, Stephane Bortzmeyer wrote: > > >Or, said in an other way: RIPE policies make very difficult > to be multihomed, > >therefore people in RIPEland take a lot of time to explain > that multihoming is > >bad. > > RIPE doesn't make up the policies - the members make the policies. > > RIPE didn't invent IP either, nor did they have a say in the design of > router architecture, nor in the pricing of RAM chips. > > Multihoming which relies on long prefixes being carried in the default > free zone, and/or more AS numbers, simply doesn't scale. That isn't a > policy matter, it's simple math. > > Which policy do you think should be changed in order to "solve" the > multihoming problem? > > Aled > -- > QiX Limited > I do think it is policy related. For example, Customer Alpha want to be multi-homed from the very beginning so he requests a /24 block from RIPE. What RIPE should do is asking which TWO ISPs Alpha is going to use. Let's say the policy requires Alpha to be under the CIDR block between these two ISPs according to a table like: UUnet & CW : 123.45.32.0/20 UUnet & Quest : 123.45.64.0/20 Ebone & Sprint: 123.45.96.0/20 ... and IX range: 123.45.128.0/20 Some note about this example: 1. The major ISP can always filter these range at /20 without worring the holes inside them. 2. It won't need to cover 100% of multi-homed customer but if major ISPs are covered it will reduce the routing table dramatically. 3. For IX people(more than 2 ISPs), it won't be aggregate possible but by allocating them in the same range we might find some small blocks (/23 /22 are highly possible ) that are aggregate possible. This is just one example what RIPE CAN do. And because it involves different ISPs it certainly looks like a community affair that belongs to the RIR level. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From acb at ukgateway.net Mon Oct 15 23:51:56 2001 From: acb at ukgateway.net (Tony Barber) Date: Mon, 15 Oct 2001 22:51:56 +0100 Subject: Multihoming - Resilience or Independence In-Reply-To: <952C79D45561D4119FCE00D0B708C8E002D7D09B@lem.poland.hp.com > Message-ID: <3.0.6.32.20011015225156.007fbc20@pop.ukgateway.net> At 01:18 PM 10/10/01 +0200, BLOCKI,JACEK \(HP-Poland,ex1\) wrote: >like route flaps do we?. In my opinion OSPF + 2 access links to 2 POPs of >single ISP would do the you much better. I wonder why virtually nobody >offers such a service? Because extending your IGP to customer sites is a bit silly, bloating your IGP and inducing a potential for misinformation from an external domain. You really don't want to do this. It may work well in small networks but certainly not in large players. Tony From acb at ukgateway.net Mon Oct 15 23:52:47 2001 From: acb at ukgateway.net (Tony Barber) Date: Mon, 15 Oct 2001 22:52:47 +0100 Subject: Multihoming - Resilience or Independence In-Reply-To: <952C79D45561D4119FCE00D0B708C8E002D7D3A7@lem.poland.hp.com > Message-ID: <3.0.6.32.20011015225247.00918b60@pop.ukgateway.net> At 07:09 PM 10/10/01 +0200, BLOCKI,JACEK \(HP-Poland,ex1\) wrote: > >Each BGP speaker advertises CIDR if and only if it learned about it from >OSPF. It can be done, if you don't know how I'll forward you a working >example. Each border router generates a default router and injects it into >OSPF. From technical point of view I see no reasons why it should not work. >What you need is: >* An agreement between ISPs ^^^^^^^^^^^^^^^^^^^^ And there is the first problem. Tony From kurtis at kpnqwest.net Tue Oct 16 08:39:16 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Tue, 16 Oct 2001 08:39:16 +0200 (MEST) Subject: Multihoming - Resilience or Independence In-Reply-To: Message-ID: > That's why filtering /20 only without re-aligning the holes in the block > won't > work. In the end /20 make the routing table looks pretty but they are > black-holing > lots of traffic. Well, it won't. The proposal for filtering is to filter on assigment boundary, and for swamp space filter on /24. Now, what will break is people punching holes in their PA space for multihomed users. Funny enough, this has never been discussed (to my knowledge) as a problem in PTOMAIN WG of the IETF. There the argument was for traffic engineering and commercial relationships... > As we all agree that re-assign address is NOT practical at all thus just > filtering > /20 block is not a good solution. That is not the suggestion. See above. The assignments per block and RIR is well known. Best regards, - kurtis - From kurtis at kpnqwest.net Tue Oct 16 10:01:50 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Tue, 16 Oct 2001 10:01:50 +0200 (MEST) Subject: Multihoming - Resilience or Independence In-Reply-To: <3.0.6.32.20011015225156.007fbc20@pop.ukgateway.net> Message-ID: > >like route flaps do we?. In my opinion OSPF + 2 access links to 2 POPs of > >single ISP would do the you much better. I wonder why virtually nobody > >offers such a service? > > Because extending your IGP to customer sites is a bit silly, bloating your > IGP and inducing a potential for misinformation from an external domain. > You really don't want to do this. It may work well in small networks but > certainly not in large players. This assumes that the CPE is under the control of the customer, but you could equally have the Eth interface as the demarcation point so that you own the CPE. - kurtis - From marcel at eu.uu.net Tue Oct 16 12:29:17 2001 From: marcel at eu.uu.net (Anne Marcel Roorda) Date: Tue, 16 Oct 2001 10:29:17 +0000 Subject: Multihoming - Resilience or Independence In-Reply-To: Your message of "Tue, 16 Oct 2001 10:01:50 +0200." Message-ID: In message , Kurt Erik Lindq vist KPNQwest writes: > > > >like route flaps do we?. In my opinion OSPF + 2 access links to 2 POPs of > > >single ISP would do the you much better. I wonder why virtually nobody > > >offers such a service? > > > > Because extending your IGP to customer sites is a bit silly, bloating your > > IGP and inducing a potential for misinformation from an external domain. > > You really don't want to do this. It may work well in small networks but > > certainly not in large players. > > This assumes that the CPE is under the control of the customer, but you > could equally have the Eth interface as the demarcation point so that you > own the CPE. Hi, Even if the CPE is under direct control, you'd have to include all edge devices where customers connect into the IGP. Add in all CPE devices and you have something that will not scale. Limiting the number of locations where this is done would scale, but may create other problems. - marcel From kurtis at kpnqwest.net Mon Oct 15 13:37:17 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Mon, 15 Oct 2001 13:37:17 +0200 (MEST) Subject: more specific routes in today reality In-Reply-To: Message-ID: > > So do I (at least in this little part of the thread, which I haven't > > had the opportunity to follow at all length). For example, a provider-wide > > routing (or performance, or whatever) problem would be your problem if > > homed only to that one provider. > > > If it is a outage and you are running BGP you will need to wait for your > router to converge. In worst case you will be dragged into the routing > problems. However, I agree with Randy that 90% of outages are due to > local-tail problems. > > I agree that two links to two operators are more reliable, but the real > questions are if they are enough MORE reliable to justify the extra > routes, and if so how do we implement this? And this should be a general > solution all the way down to the residential users... > > I am not conviced that having multiple upstreams for entrprises, SOHO, > residentials or even small ISPs are worth it. Oh, and BTW. I do think that in the long run we need to address this (among other things) one way to the other, but I don't think that todays routing technologies will scale for it. - kurtis - From PLu at cw.net Wed Oct 17 01:58:07 2001 From: PLu at cw.net (Lu, Ping) Date: Tue, 16 Oct 2001 19:58:07 -0400 Subject: Multihoming - Resilience or Independence Message-ID: > > That's why filtering /20 only without re-aligning the holes > in the block > > won't > > work. In the end /20 make the routing table looks pretty > but they are > > black-holing > > lots of traffic. > > Well, it won't. The proposal for filtering is to filter on assigment > boundary, and for swamp space filter on /24. Now, what will break is > people punching holes in their PA space for multihomed users. Funny > enough, this has never been discussed (to my knowledge) as a > problem in > PTOMAIN WG of the IETF. There the argument was for traffic > engineering and > commercial relationships... > Even for PI and swamp space, if the organization divides their space among different ISPs for multi-homed links. You still got a problem. > > As we all agree that re-assign address is NOT practical at > all thus just > > filtering > > /20 block is not a good solution. > > That is not the suggestion. See above. The assignments per > block and RIR > is well known. Well known and lots of holes in it. That's the problem. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From djp-ripe-lists at djp.net Wed Oct 17 12:02:19 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Wed, 17 Oct 2001 12:02:19 +0200 (CEST) Subject: IPv6 Network Plans (Forcasting) Message-ID: Hiya Folks, I would like to elaborate on a comment made at the end of the LIR/IPv6 session in Prague about the ability of IPv6 address space requesters to forecast their address requirements. These suggestions probably might not make it into the provisional policy, but should be considered for later policy. A large ISP, probably global, and certainly national, could build its entire infrastructure with a single /48 network block. For example this would allow 256 "locations", each with 256 networks, each with more hosts than ants on this planet.... With the popular /127 for point-point connections even customer lines can be accomodated. Accordingly, the only driver for longer prefixes would seem to be the /48 customer networks. How will applicants for IPv6 address allocations quantify these networks ? The only way I can see is from very early marketing forcasts. In the past RIPE have viewed marketing forecasts with a lot of suspicion (quite rightly). However, unless RIPE issue a "one size fits all" prefix they may have to base allocations on these marketing forecasts. One thing however can be relatively easily determined, and that is "whether an applicant has ANY customers". For those LIR WITHOUT any customers, we could allocate a /48 and even large multinational corporations would have plenty of addresses (see second paragraph above again). For those LIR WITH customers, we should be much more generous because we cannot accurately judge needs from marketing forecasts. Assuming a HD ratio of 0.8, then a moderately successful city carrier LIR with 100,000 DSL or Cable customers (each requiring a /48) will qualify for more than a /28 allocation. Do we want such LIRs to come back and ask for a second route (in the global routing table) ? Conclusion: 1. We should consider allocating a /48 to LIR without any customers as this is plenty. 2. Even a /28 would result in considerable numbers of followup requests if cable/DSL customers (mass users) get /48. Opinions, Comments, Concensus ? Cheers Dave From djp-ripe-lists at djp.net Wed Oct 17 12:10:30 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Wed, 17 Oct 2001 12:10:30 +0200 (CEST) Subject: Action: 40.9 RIRs Set up global IPv6 policy list In-Reply-To: Message-ID: Hiya all, Have I missed something or are we still waiting for this ? Is there a hold up ? It would be good to get this going as soon as possible. Can RIPE set up such a list at ipv6-global-policy at ripe.net ? Cheers Dave BT Ignite GmbH From turchany at sunserv.kfki.hu Wed Oct 17 15:01:59 2001 From: turchany at sunserv.kfki.hu (Turchanyi Geza) Date: Wed, 17 Oct 2001 15:01:59 +0200 (MEST) Subject: Action: 40.9 RIRs Set up global IPv6 policy list In-Reply-To: Message-ID: Hi, I fully support the idea. However, it is not important, where the @ is. (@ripe.net, @apnic.net ...) Best, Geza On Wed, 17 Oct 2001, Dave Pratt wrote: > Hiya all, > > Have I missed something or are we still waiting for this ? > Is there a hold up ? It would be good to get this going as soon as possible. > > Can RIPE set up such a list at ipv6-global-policy at ripe.net ? > > Cheers > Dave > BT Ignite GmbH > From turchany at sunserv.kfki.hu Wed Oct 17 15:37:13 2001 From: turchany at sunserv.kfki.hu (Turchanyi Geza) Date: Wed, 17 Oct 2001 15:37:13 +0200 (MEST) Subject: IPv6 Network Plans (Forcasting) In-Reply-To: Message-ID: Dave and all, Untill now I postponed my comments, waiting for the global mailing list. However, as there is still no mailing list, I would like to make some comments now. The firs lesson what I learned from the IPv4 address allocation history, that allocating addresses for ever has good consequences for early adopters and bad consequences for the late adopters. Early adopter should have some benefit, however, colonialisation of the address space should be avoided. The IPv6 address space is not as big as it seems to be, as the limiting effects of the multihoming, renumbering and aggregation are not clear yet. Therefore I suggest to introduce sliding allocation time window (ATW). The size of the ATW can be fine tuned by future policies, however, this could never reduce the already allocated address space allocation time, however, might increase it. For example, the ATW can be set initially for 10 year. Any ISP (LIR) will receive its address block for 3ATW, and any customer of the LIR will receive its address block for ATW. When the ATW expire, It should be checked, that the old policy is still valid. If yes, tha allocation can be extended for an other ATW period of time. If not, the customer will receive a now address block according to the new policy, and with the customer should renumber its network within the new ATW period of time and give back the old address space. When all customer of a LIR should have already migrated to the new address block, then the LIR should give back its address block, and this can be reused later on by others, according to the new policy. In this long enough allocation policy we can run the network minimize burocracy save the future Best, Geza From plzak at arin.net Wed Oct 17 21:56:22 2001 From: plzak at arin.net (Ray Plzak) Date: Wed, 17 Oct 2001 15:56:22 -0400 Subject: IPv6 Network Plans (Forcasting) In-Reply-To: Message-ID: <000701c15745$cc7898e0$e9fc95c0@arin.net> APNIC has established the global list. Hopefully you will see an announcement from RIPE NCC shortly. Ray > -----Original Message----- > From: owner-ipv6-wg at ripe.net > [mailto:owner-ipv6-wg at ripe.net]On Behalf Of > Turchanyi Geza > Sent: Wednesday, October 17, 2001 9:37 AM > To: Dave Pratt > Cc: lir-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: IPv6 Network Plans (Forcasting) > > > > Dave and all, > > Untill now I postponed my comments, waiting for the global > mailing list. > However, as there is still no mailing list, I would like to make some > comments now. > > The firs lesson what I learned from the IPv4 address > allocation history, > that allocating addresses for ever has good consequences for early > adopters and bad consequences for the late adopters. > > Early adopter should have some benefit, however, > colonialisation of the > address space should be avoided. > > The IPv6 address space is not as big as it seems to be, as the > limiting effects of the multihoming, renumbering and > aggregation are not > clear yet. > > Therefore I suggest to introduce sliding allocation time > window (ATW). The > size > of the ATW can be fine tuned by future policies, however, > this could never > reduce the already allocated address space allocation time, however, > might increase it. > > For example, the ATW can be set initially for 10 year. Any > ISP (LIR) will > receive its address block for 3ATW, and any customer of the LIR will > receive its address block for ATW. > > When the ATW expire, It should be checked, that the old > policy is still > valid. If yes, tha allocation can be extended for an other > ATW period of > time. If not, the customer will receive a now address block > according to > the new policy, and with the customer should renumber its > network within > the new ATW period of time and give back the old address space. > > When all customer of a LIR should have already migrated to > the new address > block, then the LIR should give back its address block, and > this can be > reused later on by others, according to the new policy. > > In this long enough allocation policy we can > run the network > minimize burocracy > save the future > > Best, > > Geza > > > From pfs at cisco.com Thu Oct 18 06:00:14 2001 From: pfs at cisco.com (Philip Smith) Date: Thu, 18 Oct 2001 14:00:14 +1000 Subject: IPv6 Network Plans (Forcasting) In-Reply-To: <000701c15745$cc7898e0$e9fc95c0@arin.net> References: Message-ID: <5.1.0.14.2.20011018135859.03bb2108@localhost> This went out to apnic-announce earlier today... philip -- ------------------------------------------------ * GLOBAL DEVELOPMENT OF REVISED IPv6 ADDRESS POLICY A new mailing list has been established to co-ordinate global policy discussions on the development of a revised IPv6 addressing policy to replace the "Provisional IPv6 assignment and allocation policy document". The list name is . Although this list is hosted by APNIC, it is open to all members of the global Internet community with an interest in IPv6 address policy. Subscription information is available at: http://www.apnic.net/net_comm/lists/ Archives of discussions are available at: http://www.apnic.net/mailing-lists/global-v6 -------------- APNIC encourages all interested parties to subscribe to these lists and contribute to the development of important global address policy. Kind regards, Anne Lord __________________________________________________________ APNIC Secretariat http://www.apnic.net ph/fx +61 7 3367 0490/82 * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request at apnic.net * At 15:56 17/10/2001 -0400, Ray Plzak wrote: >APNIC has established the global list. Hopefully you will see an >announcement from RIPE NCC shortly. > >Ray > > > -----Original Message----- > > From: owner-ipv6-wg at ripe.net > > [mailto:owner-ipv6-wg at ripe.net]On Behalf Of > > Turchanyi Geza > > Sent: Wednesday, October 17, 2001 9:37 AM > > To: Dave Pratt > > Cc: lir-wg at ripe.net; ipv6-wg at ripe.net > > Subject: Re: IPv6 Network Plans (Forcasting) > > > > > > > > Dave and all, > > > > Untill now I postponed my comments, waiting for the global > > mailing list. > > However, as there is still no mailing list, I would like to make some > > comments now. > > > > The firs lesson what I learned from the IPv4 address > > allocation history, > > that allocating addresses for ever has good consequences for early > > adopters and bad consequences for the late adopters. > > > > Early adopter should have some benefit, however, > > colonialisation of the > > address space should be avoided. > > > > The IPv6 address space is not as big as it seems to be, as the > > limiting effects of the multihoming, renumbering and > > aggregation are not > > clear yet. > > > > Therefore I suggest to introduce sliding allocation time > > window (ATW). The > > size > > of the ATW can be fine tuned by future policies, however, > > this could never > > reduce the already allocated address space allocation time, however, > > might increase it. > > > > For example, the ATW can be set initially for 10 year. Any > > ISP (LIR) will > > receive its address block for 3ATW, and any customer of the LIR will > > receive its address block for ATW. > > > > When the ATW expire, It should be checked, that the old > > policy is still > > valid. If yes, tha allocation can be extended for an other > > ATW period of > > time. If not, the customer will receive a now address block > > according to > > the new policy, and with the customer should renumber its > > network within > > the new ATW period of time and give back the old address space. > > > > When all customer of a LIR should have already migrated to > > the new address > > block, then the LIR should give back its address block, and > > this can be > > reused later on by others, according to the new policy. > > > > In this long enough allocation policy we can > > run the network > > minimize burocracy > > save the future > > > > Best, > > > > Geza > > > > > > From mir at ripe.net Thu Oct 18 16:45:31 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 18 Oct 2001 14:45:31 +0000 Subject: NEW mailing lists for global IPv6 address policy Message-ID: <200110181445.f9IEjV226329@birch.ripe.net> Dear Colleagues, Please find below information about a new mailing list set up to discuss IPv6 address policy on a global level. Kind Regards, Mirjam Kuhne RIPE NCC -------------------------------------------------- * GLOBAL DEVELOPMENT OF REVISED IPv6 ADDRESS POLICY A new mailing list has been established to co-ordinate global policy discussions on the development of a revised IPv6 addressing policy to replace the "Provisional IPv6 assignment and allocation policy document". The list name is . Although this list is hosted by APNIC, it is open to all members of the global Internet community with an interest in IPv6 address policy. Subscription information is available at: http://www.apnic.net/net_comm/lists/ Archives of discussions are available at: http://www.apnic.net/mailing-lists/global-v6 --------------- The RIRs encourage all interested parties to subscribe to this list and contribute to the development of important global address policy. From mir at ripe.net Thu Oct 18 17:22:33 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 18 Oct 2001 15:22:33 +0000 Subject: 219/8 allocated to APNIC Message-ID: <200110181522.f9IFMX204387@birch.ripe.net> Dear Colleagues, Please see the announcement below. Mirjam Kuhne RIPE NCC ------- Forwarded Message Date: Wed, 17 Oct 2001 13:58:50 +1000 From: George Michaelson Sender: owner-apnic-announce at lists.apnic.net To: apnic-announce at lists.apnic.net Subject: [apnic-announce] Additional IPv4 address range allocated to APNIC [Note "reply-to:" field] - --------------------------- Dear colleagues APNIC received the IPv4 address range 219/8 from IANA on 12 October 2001 and will now begin making allocations from this range. Please configure your routing filters accordingly. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html Kind regards Son APNIC Member Services Department - ------------------------------------------------------------- * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request at apnic.net * ------- End of Forwarded Message From ncc at ripe.net Mon Oct 22 13:45:41 2001 From: ncc at ripe.net (RIPE NCC Document Announcement Service) Date: Mon, 22 Oct 2001 13:45:41 +0200 Subject: Revised Document available: RIPE-229 Message-ID: <200110221145.f9MBjfq07988@birch.ripe.net> Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Short content description ------------------------- This document recommends a set of route-flap damping parameters that should be applied by all ISPs in the Internet and should be deployed as default values by BGP router vendors. This document obsoletes ripe-210 and ripe-178. The document is available in HTML format at: http://www.ripe.net/ripe/docs/ripe-229.html Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-229.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-229.txt plain text version From kurtis at kpnqwest.net Tue Oct 23 08:28:48 2001 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Tue, 23 Oct 2001 08:28:48 +0200 (MEST) Subject: Multihoming - Resilience or Independence In-Reply-To: Message-ID: > Even for PI and swamp space, if the organization divides their space among > different ISPs for > multi-homed links. You still got a problem. That is what I thought this thread was about? > > That is not the suggestion. See above. The assignments per > > block and RIR > > is well known. > > Well known and lots of holes in it. That's the problem. Uhm, say again? You mean that there are people that take address assignments with them when they change provider? I think that is a much larger problem than that of multihoming then... - kurtis - From nurani at ripe.net Tue Oct 23 11:17:40 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Tue, 23 Oct 2001 11:17:40 +0200 Subject: LIR-PARTITIONED - Final version Message-ID: <5.1.0.14.2.20011023111508.037f4a60@localhost> Dear all, Following the announcement 28 Sep 2001 on these lists, please find below the final details of the LIR-PARTITIONED PROPOSAL. This proposal will be implemented by the RIPE NCC in the coming period and presented at the RIPE 41 meeting in January 2002. Comments and suggestions made on this list have been incorporated in the proposal below. +-----------------+ | LIR-PARTITIONED | +-----------------+ Background ----------- This proposal (initially named "LIR-ALLOCATED") was originally discussed at September 1999. James Aldridge later sent out a first proposal to the LIR-WG mailing list, 14 Jan 2000. (See: http://www.ripe.net/ripe/mail-archives/lir-wg/20000101-20000401/msg00007.html) The full final proposal (15 Jan 2001) by Aldridge can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/20010101-20010401/msg00003.html At the RIPE 38 meeting,(22-26 Jan 2001), the RIPE NCC accepted the action to implement this proposal. Motivation (as expressed by James Aldridge) -------------------------------------------- "For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s)." Database Objects affected ------------------------- Only inetnum objects may have the "LIR-PARTITIONED" status value. Usage ----- The "LIR-PARTITIONED" feature allows LIRs to delegate maintenance of lower-level objects representing assignments within the address space specified by the inetnum object with the status "LIR-PARTITIONED PA" OR "LIR-PARTITIONED PI". Functionality ------------- When creating or modifying the inetnum object the database will check the value of the "status:" attribute according to the following rules: - The value of "ALLOCATED PA" or "ALLOCATED PI" is allowed if the object is maintained by the RIPE-NCC-HM-MNT mntner (this name is specified in ALLOCMNT variable of the configuration file) - The value of "LIR-PARTITIONED PA" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PA" or "LIR-PARTITIONED PA". - The value of "LIR-PARTITIONED PI" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PI" or "LIR-PARTITIONED PI". Additional clarification ------------------------ This proposal addresses the added inetnum status value as proposed by James Aldridge. This is strictly a database feature, allowing LIRs to delegate maintenance within their allocations in the RIPE Database. The implementation of this proposal will not affect IP address allocation policy. This means that it will not affect the responsibility LIRs have for allocations and assignments held by them. Furthermore, it will not change the manner in which the RIPE NCC verifies allocation utilisation. There is an on-going policy discussion addressing this specific issue. Kind regards, Nurani Nimpuno *-----------------------------------* | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *-----------------------------------* From huberman at gblx.net Tue Oct 23 19:41:51 2001 From: huberman at gblx.net (David R Huberman) Date: Tue, 23 Oct 2001 10:41:51 -0700 (MST) Subject: FreeIPdb to be released Message-ID: Hello, As discussed last month on this list, Global Crossing uses a powerful suite of tools, called IPdb, to manage its address space, address space assignments, and RIR requirements for both IPv4 and IPv6. Version 1.0 of FreeIPdb will be released next week as open source. I will post all the pertinent details in the coming days. /david *--------------------------------* | Global Crossing API | | Manager, Global IP Addressing | | (703) 627-5800 | | huberman at gblx.net | *--------------------------------* From PLu at cw.net Tue Oct 23 21:27:18 2001 From: PLu at cw.net (Lu, Ping) Date: Tue, 23 Oct 2001 15:27:18 -0400 Subject: Multihoming - Resilience or Independence Message-ID: > > > Even for PI and swamp space, if the organization divides > their space among > > different ISPs for > > multi-homed links. You still got a problem. > > That is what I thought this thread was about? > > > > That is not the suggestion. See above. The assignments per > > > block and RIR > > > is well known. > > > > Well known and lots of holes in it. That's the problem. > > Uhm, say again? You mean that there are people that take address > assignments with them when they change provider? I think that > is a much > larger problem than that of multihoming then... > I mean when a customer get a second link from a backup ISP using the same block from the primary ISP. Then it became a hole in the primary ISP's CIDR block. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net