From Frank.Bohnsack at de.uu.net Thu Feb 1 15:22:27 2001 From: Frank.Bohnsack at de.uu.net (Frank Bohnsack) Date: Thu, 01 Feb 2001 15:22:27 +0100 (MET) Subject: RtConfig and rpsl.ripe.net Message-ID: Hi again, Do you have an idea, why i can't use rpsl.ripe.net with RtConfig ? > fb at sun5 58> RtConfig -h rpsl.ripe.net < eg:cisco > ... > Warning: no byte count error for query !s-*. cheers Frank From woeber at cc.univie.ac.at Thu Feb 1 15:37:25 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 01 Feb 2001 15:37:25 +0100 Subject: RtConfig and rpsl.ripe.net Message-ID: <009F6FED.56FE397E.12@cc.univie.ac.at> >Do you have an idea, why i can't use rpsl.ripe.net with RtConfig ? I seem to remember a bug report on some (minor?) problems with RaToolSet and the new v3 code. NCC was/is applying a path to RaToolSet, I think. Wilfried. From shane at ripe.net Thu Feb 1 15:58:29 2001 From: shane at ripe.net (Shane Kerr) Date: Thu, 1 Feb 2001 15:58:29 +0100 (CET) Subject: RtConfig and rpsl.ripe.net In-Reply-To: <009F6FED.56FE397E.12@cc.univie.ac.at> Message-ID: On Thu, 1 Feb 2001, Wilfried Woeber, UniVie/ACOnet wrote: > >Do you have an idea, why i can't use rpsl.ripe.net with RtConfig ? > > I seem to remember a bug report on some (minor?) problems with RaToolSet > and the new v3 code. NCC was/is applying a path to RaToolSet, I think. First, make sure you're specifying the Bird protocol (it's the closest to the RIPE protocol). As soon as RIPE begins maintenance of the RAToolSet we'll add the RIPE protocol specifically. :) Second, you'll need to modify the sources somewhat. If you look in the file src/irr/birdwhoisc.cc you need to add the following function: // remove RIPE-style comments static void stripRipeComments(Buffer &buf) { // remove leading '\n' characters, if any while ((buf.getSize() > 0) && ((buf.getContents())[0] == '\n')) { buf.flush(1); } // remove comments at beginning of buffer while ((buf.getSize() >= 2) && ((buf.getContents())[0] == '%')) { char *contents = buf.getContents(); char *eol = (char *)memchr(contents, '\n', buf.getSize()); if (eol == NULL) { // no EOL, no comment to strip (yet) return; } buf.flush(eol-contents+1); } } This stips comments that begin with '%', which are RIPE-specific. This needs to be called from the method BirdWhoisClient::getResponse(). You'll see the following line: } while (!found); Change this to: stripRipeComments(*response); } while (!found); Finally, you need to handle the case where no output except for comments are returned. Change the lines: if (found) break; To be: if ((response->size == 2) && (response->contents[0] == '\n') && (response->contents[1] == '\n')) { found = true; } if (found) break; Compile, install, and you should be able to produce router configs. If necessary, I can send the entire file to somebody who doesn't feel comfortable with editing the code by hand. -- Shane From woeber at cc.univie.ac.at Thu Feb 1 16:23:34 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 01 Feb 2001 16:23:34 +0100 Subject: RtConfig and rpsl.ripe.net Message-ID: <009F6FF3.C98C089E.15@cc.univie.ac.at> >First, make sure you're specifying the Bird protocol (it's the closest >to the RIPE protocol). As soon as RIPE begins maintenance of the >RAToolSet we'll add the RIPE protocol specifically. :) Any details about the "As soon as"? >Second, you'll need to modify the sources somewhat. If you look in the >file src/irr/birdwhoisc.cc you need to add the following function: At least _I_ would feel more comfortable to find - the baseline dist - the patch or diff file against that version - and a patched version (that you had already run against the build procedure) somewhere on the NCC's server! Can this be easily done? Wilfried. From andrei at ripe.net Thu Feb 1 16:41:26 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 01 Feb 2001 16:41:26 +0100 Subject: RtConfig and rpsl.ripe.net References: <009F6FF3.C98C089E.15@cc.univie.ac.at> Message-ID: <3A7983A6.F3E28DCE@ripe.net> Hi, "Wilfried Woeber, UniVie/ACOnet" wrote: > > >First, make sure you're specifying the Bird protocol (it's the closest > >to the RIPE protocol). As soon as RIPE begins maintenance of the > >RAToolSet we'll add the RIPE protocol specifically. :) > > Any details about the "As soon as"? Officially the USC project finishes in March. Then we take it over. > > >Second, you'll need to modify the sources somewhat. If you look in the > >file src/irr/birdwhoisc.cc you need to add the following function: > > At least _I_ would feel more comfortable to find > > - the baseline dist > - the patch or diff file against that version > - and a patched version > (that you had already run against the build procedure) > > somewhere on the NCC's server! Can this be easily done? We will make the patch available along with the information where to find the baseline distribution. We will also put the patched version online. > > Wilfried. Regards, Andrei Robachevsky DB Group Manager RIPE NCC From woeber at cc.univie.ac.at Thu Feb 1 17:00:22 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 01 Feb 2001 17:00:22 +0100 Subject: RtConfig and rpsl.ripe.net Message-ID: <009F6FF8.EDCCA2AE.8@cc.univie.ac.at> >Officially the USC project finishes in March. Then we take it over. I see. >We will make the patch available along with the information where to >find the baseline distribution. We will also put the patched version >online. Great, thanks! Wilfried. From andrei at ripe.net Mon Feb 5 10:18:59 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 05 Feb 2001 10:18:59 +0100 Subject: Migration issues: route creation Message-ID: <3A7E7003.46E3DBC3@ripe.net> Dear Colleagues, You may know that the new version of the RIPE database (v3.0) also supports Routing Policy Security System (RFC2725). One of the implications is that this may prevent registrations of "foreign" routes in the RIPE IRR (that is routes from non RIPE address space and/or non RIPE ASN). According to RFC2725, creation of a route object should be authorized by the "owner" of the respective address space or aggregate route and by the "owner" of the ASN that is specified as route origin. In case of absence of the corresponding objects, creation of the route object will fail. The creation of the corresponding "foreign" objects will not be as easy in the new version as it is in the current one. The ASN space will be protected by as-block object, and IP address space by corresponding top level inetnum object. This makes registration of "foreign" routes almost impossible, which affects current practice when an IPS requests that clients' routes should be registered in the RIPE IRR. Possible solutions to this problem are: 1. Send such registration requests to the Database Administration (ripe-dbm) who will perform registration by overriding security (and performing necessary checks before). This puts additional load on ripe-dbm and creates duplicate objects in the RIPE database and "foreign" IRR. 2. Do not allow such registrations. In this case some ISPs will need to change their peering policy and accept routing information from a "foreign" IRR. Your comments and suggestions are highly appreciated. Regards, Andrei Robachevsky DB Group Manager RIPE NCC From SchmitzJo at aol.com Tue Feb 13 01:31:42 2001 From: SchmitzJo at aol.com (SchmitzJo at aol.com) Date: Mon, 12 Feb 2001 19:31:42 EST Subject: Migration issues: route creation Message-ID: <68.bff559e.27b9da6e@aol.com> Dear Andrei, you wrote that there will be problems creating duplicates of aut-nums and routes in other registries if they do not formally belong there due to the authorization rules introduced with the RPSL transition at RIPE. You suggested two solutions: > Possible solutions to this problem are: > > 1. Send such registration requests to the Database Administration > (ripe-dbm) who will perform registration by overriding security (and > performing necessary checks before). This puts additional load on > ripe-dbm and creates duplicate objects in the RIPE database and > "foreign" IRR. > > 2. Do not allow such registrations. In this case some ISPs will need to > change their peering policy and accept routing information from a > "foreign" IRR. > > Your comments and suggestions are highly appreciated. > I did not yet see an answer to your question. However, I believe that your first suggestion should *not* be followed. I definitely would want to avoid opening "side" paths to enter data into the RIPE database. Using ripe-dbm should be the exception for special requirements. For everything else, the robots should be used. Regarding duplication: this had originally been introduced to help people along while mirroring was not working. With RIPE having transitioned to RPSL, we will have compatible formats again, and do not need duplication anymore - under the prerequisite that you are properly coordinating with RADB and any other major IRR. I am inclined to say, that avoiding duplication is the purpose of the effort! Looking at your second proposal, I believe that you are saying the right thing, but phrased it a little different. Peering policy is probably a term which may be confused with routing policy - and nobody needs to change its routing policy by looking at several IRRs now. Actually, I believe that there is not much of an issue: Smaller ISPs have always registered in only one IRR; only bigger providers with international reach have entered their information into several IRRs and duplicated data, but then also using data from all IRRs they registered into. It should not be too much of a pain to use this information to continue with this practice after the RPSL transition. Those parties who do not agree, speak up loudly now! Thanks Joachim --- JS395-RIPE -- standard disclaimer --- From plu at cw.net Tue Feb 13 04:27:21 2001 From: plu at cw.net (Lu, Ping) Date: Mon, 12 Feb 2001 22:27:21 -0500 Subject: Migration issues: route creation Message-ID: I think that's me :) Let's talk about the GLOBAL issues and the practical use of RR. For all RIRs like RIPE, ARIN, APNIC and so on. They are in a regulartory position so they OWN all the objects (AN, PN, MT) and they seldom need to CROSS-REFERENCE with other RIRs. So the self-contained assumption (all references should be resloved locally ) is fine with RIR. But for the LIRs (especially the ISPs) RR has a more practical use, like auto-generated access-lists and as-path filters. Almost all the major ISPs have their own tools or use the public tool like RAToolSet to pull data from RR then auto-generate the configiuration for their routers. Now here is the fun part. As a global player we have to create a list of objects ( AN, RT ) from all the RIRs and with any public peer (registered in one of the RIRs ) we have to create a list of rather private objects ( MT, PN, RO ). But it becomes too difficult to duplicate those private objects with up-to-date information, so the best way is to REFERENCE their LEGAL objects in any one of the RIRs ( of course if the AS itself agree us to do so ). This is where the GLOBALLY UNIQUE nic-hdl comes in and in a more generic sense, how about GLOBALLY UNIQUE maintainer name ? Does this sound like domain name system ? Sooner or later RR has to face the GLOBAL issue like DNS, IP address and E-MAIL did. We have already seen some of the global issues showed up in the RR domain ( referral, globally unique nic-hdl ) and there will be more and more name-collision in the future. So why not adopt a naming system like DNS or E-MAIL ? Here is my favorite quote from RFC2622 ----------------------------------------------------- is a uniquely assigned identifier word used by routing, address allocation, and other registries to unambiguously refer to contact information. Person and role classes map NIC handles to actual person names, and contact information. ----------------------------------------------------- Hmmm! So RPSL already specify the need to use information from OTHER REGISTRIES. I rest my case. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: SchmitzJo at aol.com [mailto:SchmitzJo at aol.com] > Sent: Monday, February 12, 2001 7:32 PM > To: andrei at ripe.net; reimp-mig-tf at ripe.net; db-wg at ripe.net; > routing-wg at ripe.net > Subject: Re: Migration issues: route creation > > > Dear Andrei, > > you wrote that there will be problems creating duplicates of > aut-nums and > routes in other registries if they do not formally belong > there due to the > authorization rules introduced with the RPSL transition at RIPE. You > suggested two solutions: > > > Possible solutions to this problem are: > > > > 1. Send such registration requests to the Database Administration > > (ripe-dbm) who will perform registration by overriding > security (and > > performing necessary checks before). This puts additional load on > > ripe-dbm and creates duplicate objects in the RIPE database and > > "foreign" IRR. > > > > 2. Do not allow such registrations. In this case some ISPs > will need to > > change their peering policy and accept routing information from a > > "foreign" IRR. > > > > Your comments and suggestions are highly appreciated. > > > I did not yet see an answer to your question. However, I > believe that your > first suggestion should *not* be followed. I definitely would > want to avoid > opening "side" paths to enter data into the RIPE database. > Using ripe-dbm > should be the exception for special requirements. For > everything else, the > robots should be used. > > Regarding duplication: this had originally been introduced to > help people > along while mirroring was not working. With RIPE having > transitioned to RPSL, > we will have compatible formats again, and do not need > duplication anymore - > under the prerequisite that you are properly coordinating > with RADB and any > other major IRR. I am inclined to say, that avoiding > duplication is the > purpose of the effort! > > Looking at your second proposal, I believe that you are > saying the right > thing, but phrased it a little different. Peering policy is > probably a term > which may be confused with routing policy - and nobody needs > to change its > routing policy by looking at several IRRs now. Actually, I > believe that there > is not much of an issue: Smaller ISPs have always registered > in only one IRR; > only bigger providers with international reach have entered > their information > into several IRRs and duplicated data, but then also using > data from all IRRs > they registered into. It should not be too much of a pain to use this > information to continue with this practice after the RPSL transition. > > Those parties who do not agree, speak up loudly now! > Thanks > Joachim > > --- JS395-RIPE -- standard disclaimer --- > From andrew.hilborne at uk.concentric.com Tue Feb 13 17:35:45 2001 From: andrew.hilborne at uk.concentric.com (Andrew Hilborne) Date: 13 Feb 2001 16:35:45 +0000 Subject: Migration issues: route creation In-Reply-To: "Lu, Ping"'s message of "Mon, 12 Feb 2001 22:27:21 -0500" References: Message-ID: "Lu, Ping" writes: > ... > We have already seen some of the global issues showed up in the RR domain ( > referral, globally unique nic-hdl ) and there will be more and more > name-collision in the future. > > So why not adopt a naming system like DNS or E-MAIL ? Or SNMP? Andrew Hilborne From plu at cw.net Wed Feb 14 15:25:17 2001 From: plu at cw.net (Lu, Ping) Date: Wed, 14 Feb 2001 09:25:17 -0500 Subject: Migration issues: route creation Message-ID: Further into the subject. About the new RIPE-DB software V3.X, is that a requirement when mirroring we have to import ALL the objects in order to satisfy the database referencial integerity ? For example, when we mirror with RIPE, if the route object point to a mntner object (thru mnt-by ) do we have to have that mntner object imported also ? If the answer is YES then does a mirroring agreement mean we have to share all the objects ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: Lu, Ping [mailto:plu at cw.net] > Sent: Monday, February 12, 2001 10:27 PM > To: 'SchmitzJo at aol.com'; andrei at ripe.net; reimp-mig-tf at ripe.net; > db-wg at ripe.net; routing-wg at ripe.net > Subject: RE: Migration issues: route creation > > > I think that's me :) Let's talk about the GLOBAL issues and > the practical > use of RR. > > For all RIRs like RIPE, ARIN, APNIC and so on. They are in a > regulartory > position so they OWN all the objects (AN, PN, MT) and they > seldom need to > CROSS-REFERENCE with other RIRs. So the self-contained assumption (all > references should be resloved locally ) is fine with RIR. > > But for the LIRs (especially the ISPs) RR has a more > practical use, like > auto-generated access-lists and as-path filters. Almost all > the major ISPs > have their own tools or use the public tool like RAToolSet to > pull data from > RR then auto-generate the configiuration for their routers. > > Now here is the fun part. > > As a global player we have to create a list of objects ( AN, > RT ) from all > the RIRs and with any public peer (registered in one of the > RIRs ) we have > to create a list of rather private objects ( MT, PN, RO ). > But it becomes > too difficult to duplicate those private objects with up-to-date > information, so the best way is to REFERENCE their LEGAL > objects in any one > of the RIRs ( of course if the AS itself agree us to do so ). > This is where > the GLOBALLY UNIQUE nic-hdl comes in and in a more generic > sense, how about > GLOBALLY UNIQUE maintainer name ? > > Does this sound like domain name system ? Sooner or later RR > has to face the > GLOBAL issue like DNS, IP address and E-MAIL did. > > We have already seen some of the global issues showed up in > the RR domain ( > referral, globally unique nic-hdl ) and there will be more and more > name-collision in the future. > > So why not adopt a naming system like DNS or E-MAIL ? > > Here is my favorite quote from RFC2622 > ----------------------------------------------------- > is a uniquely assigned identifier word used > by routing, > address allocation, and other registries to > unambiguously refer to > contact information. Person and role classes map NIC handles to > actual person names, and contact information. > ----------------------------------------------------- > > Hmmm! So RPSL already specify the need to use information from OTHER > REGISTRIES. > > I rest my case. > > Ping Lu > Cable & Wireless USA > Network Tools and Analysis Group > W: +1-703-292-2359 > E: plu at cw.net > > > > -----Original Message----- > > From: SchmitzJo at aol.com [mailto:SchmitzJo at aol.com] > > Sent: Monday, February 12, 2001 7:32 PM > > To: andrei at ripe.net; reimp-mig-tf at ripe.net; db-wg at ripe.net; > > routing-wg at ripe.net > > Subject: Re: Migration issues: route creation > > > > > > Dear Andrei, > > > > you wrote that there will be problems creating duplicates of > > aut-nums and > > routes in other registries if they do not formally belong > > there due to the > > authorization rules introduced with the RPSL transition at > RIPE. You > > suggested two solutions: > > > > > Possible solutions to this problem are: > > > > > > 1. Send such registration requests to the Database Administration > > > (ripe-dbm) who will perform registration by overriding > > security (and > > > performing necessary checks before). This puts additional load on > > > ripe-dbm and creates duplicate objects in the RIPE database and > > > "foreign" IRR. > > > > > > 2. Do not allow such registrations. In this case some ISPs > > will need to > > > change their peering policy and accept routing information from a > > > "foreign" IRR. > > > > > > Your comments and suggestions are highly appreciated. > > > > > I did not yet see an answer to your question. However, I > > believe that your > > first suggestion should *not* be followed. I definitely would > > want to avoid > > opening "side" paths to enter data into the RIPE database. > > Using ripe-dbm > > should be the exception for special requirements. For > > everything else, the > > robots should be used. > > > > Regarding duplication: this had originally been introduced to > > help people > > along while mirroring was not working. With RIPE having > > transitioned to RPSL, > > we will have compatible formats again, and do not need > > duplication anymore - > > under the prerequisite that you are properly coordinating > > with RADB and any > > other major IRR. I am inclined to say, that avoiding > > duplication is the > > purpose of the effort! > > > > Looking at your second proposal, I believe that you are > > saying the right > > thing, but phrased it a little different. Peering policy is > > probably a term > > which may be confused with routing policy - and nobody needs > > to change its > > routing policy by looking at several IRRs now. Actually, I > > believe that there > > is not much of an issue: Smaller ISPs have always registered > > in only one IRR; > > only bigger providers with international reach have entered > > their information > > into several IRRs and duplicated data, but then also using > > data from all IRRs > > they registered into. It should not be too much of a pain > to use this > > information to continue with this practice after the RPSL > transition. > > > > Those parties who do not agree, speak up loudly now! > > Thanks > > Joachim > > > > --- JS395-RIPE -- standard disclaimer --- > > > From andrei at ripe.net Wed Feb 14 15:26:11 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 14 Feb 2001 15:26:11 +0100 Subject: Migration issues: route creation References: Message-ID: <3A8A9583.A37BAEDD@ripe.net> "Lu, Ping" wrote: > > Further into the subject. > > About the new RIPE-DB software V3.X, is that a requirement when mirroring we > have to import > ALL the objects in order to satisfy the database referencial integerity ? > > For example, when we mirror with RIPE, if the route object point to a mntner > object (thru mnt-by ) do we have to have that mntner object imported also ? > You can configure the software to resolve these references internally (by creating "dummy" objects). However, you cannot request "selective mirroring" for a particular types of objects. > If the answer is YES then does a mirroring agreement mean we have to share > all the objects ? > Referential integrity needs to be satisfied only within a single source. That is TEST1-MNT with RADB source and TEST1-MNT with the RIPE one are in fact different objects. > Ping Lu > Cable & Wireless USA > Network Tools and Analysis Group > W: +1-703-292-2359 > E: plu at cw.net > Regards, Andrei Robachevsky DB Group Manager RIPE NCC From plu at cw.net Wed Feb 14 16:04:30 2001 From: plu at cw.net (Lu, Ping) Date: Wed, 14 Feb 2001 10:04:30 -0500 Subject: Migration issues: route creation Message-ID: Comment followed. > > You can configure the software to resolve these references internally > (by creating "dummy" objects). However, you cannot request "selective > mirroring" for a particular types of objects. > What happen if you don't want to share some of the person objects ? At least, I believe APNIC has a policy to guard private information so they may not want to mirror the maintainer and person objects. > Referential integrity needs to be satisfied only within a > single source. > That is TEST1-MNT with RADB source and TEST1-MNT with the RIPE one are > in fact different objects. > How about AS3561 in RIPE, ARIN and APNIC ? In reality this is the same AS ( assigned by ARIN but need to be present in RIPE and APNIC as well ) And this will be a route creation problem, we will need to register some route objects in RIPE that originates from AS3561 very soon. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From andrei at ripe.net Thu Feb 15 17:24:33 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 15 Feb 2001 17:24:33 +0100 Subject: Migration issues: route creation References: Message-ID: <3A8C02C1.39186A8E@ripe.net> "Lu, Ping" wrote: > > Comment followed. > > > > > You can configure the software to resolve these references internally > > (by creating "dummy" objects). However, you cannot request "selective > > mirroring" for a particular types of objects. > > > > What happen if you don't want to share some of the person objects ? > At least, I believe APNIC has a policy to guard private information so they > may not want > to mirror the maintainer and person objects. I think one can filter out these objects from the mirroring stream while maintaining the correct sequence of serials. > > > Referential integrity needs to be satisfied only within a > > single source. > > That is TEST1-MNT with RADB source and TEST1-MNT with the RIPE one are > > in fact different objects. > > > > How about AS3561 in RIPE, ARIN and APNIC ? In reality this is the same AS > ( assigned by ARIN but need to be present in RIPE and APNIC as well ) > And this will be a route creation problem, we will need to register some > route > objects in RIPE that originates from AS3561 very soon. > In current version of the database you also need to register the aut-num referenced by the origin attribute of a route object in order to register the object. Which leads to duplication of data for those ISPs that have address space and aut-num registered in different registries. Not perfect, I agree. But the problem with route creation in the new version of the database is that if we maintain the same level of security for the whole database (which means protecting the whole ASN space with as-block objects and IP space with corresponding inetnum objects) it will be _impossible_ to register respective aut-num or inetnum object in a normal way to authorize route creation (RFC2725). Another option could be that in order to allow "foreign" registrations we will maintain different levels of security (no as-block for ARIN ASNs, for example). Only routes from the RIPE address space and RIPE ASN will be properly authenticated and authorised. > Ping Lu > Cable & Wireless USA > Network Tools and Analysis Group > W: +1-703-292-2359 > E: plu at cw.net Regards, Andrei Robachevsky DB Group Manager RIPE NCC