- db-wg - mailman.ripe.net

Re: RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 02 Mar '01

02 Mar '01

Dear Ping Lu, you wrote: > We had a lively discussion about the RPSL transition during the RIPE-38 > meeting. This is correct, and I very much appreciate the input you provided during our joint working group session. > Well, if we can't fight them then the best thing to do is to join them. Do I need to be worried now? I never considered this to be a fight ;-) > With the company's support behind us, we (Cable & Wireless Global) as a > legacy LIR (used to be MCI) > would like to work with RIPE to help the RPSL transition. > > CW will adopt a similar schedule as RIPE's to transform our Routing Registry > into the new RPSL format. > This will probably make all the mirroring LIRs' job much easier and > hopefully all the downstream ISPs happier (only the RPSL format to deal > with). > > So GO FOR IT. I welcome your approval. I believe I do not exaggerate stating that you can count on the support from the RIPE community and the NCC in particular in the transition effort. Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

RE: RIPE: last call for comments RPSL transition
by Christian Panigl, ACOnet/VIX/UniVie 01 Mar '01

01 Mar '01

Hi Joachim, well I'd say go for it. But let me kindly ask for the following thingies: since the RIPE-NCC is now in charge of the maintenance of the RAtoolset please make sure that there's a release available (specifically RTconfig) which is fully compatible with the RIPE RPSL server by mid of March 2001 latest. It appears that this might be available already (since Feb20 ?), however, the link to "RtConfig Patch for the RAToolSet" of the "RPSL Migration" homepage is broken. In addition, any clear links to concise How2do documents on RAToolSet and RtConfig would be appreciated. Thanks and kind regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

2 1

RE: RIPE: last call for comments RPSL transition
by Lu, Ping 01 Mar '01

01 Mar '01

Hi, Joachim, We had a lively discussion about the RPSL transition during the RIPE-38 meeting. Well, if we can't fight them then the best thing to do is to join them. With the company's support behind us, we (Cable & Wireless Global) as a legacy LIR (used to be MCI) would like to work with RIPE to help the RPSL transition. CW will adopt a similar schedule as RIPE's to transform our Routing Registry into the new RPSL format. This will probably make all the mirroring LIRs' job much easier and hopefully all the downstream ISPs happier (only the RPSL format to deal with). So GO FOR IT. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: SchmitzJo(a)aol.com [mailto:SchmitzJo@aol.com] > Sent: Friday, February 16, 2001 6:46 PM > To: routing-wg(a)ripe.net; db-wg(a)ripe.net; lir-wg(a)ripe.net; > local-ir(a)ripe.net > Cc: andrei(a)ripe.net; joao(a)ripe.net; hph(a)a.sol.no; > woeber(a)cc.univie.ac.at; schmitzjo(a)aol.com > Subject: RIPE: last call for comments RPSL transition > Importance: Low > > > Hello all, > > as you are aware, we are preparing the migration of the RIPE database > software to support and deploy the new RPSL format. The required steps > have been discussed in depth on various occassions (for references, > see end of mail). > > We are now preparing the most important step, really > transitioning from > old > RIPE-181 to new RPSL format: > > proposed transition date is 23-Apr-2001. > > This step, once taken, will not be reversed. The majority of the user > community takes a neutral role, while some want an earlier, > and a few a > later > date for migration. During the joint session of Routing and DB WG at > RIPE38, > the chairmen of both WGs were tasked to file a last call for > comments on > that > date, in particular whether there are serious, unresolvable > technical or > operational problems which would benefit from a slightly > longer warning > period. > > According to consensus at the session: If you are convinced that the > transition date as proposed would lead to significant operational > problems, please explain and justify why within the next 2 weeks: > > deadline for transition comments: 1-Mar-2001 > > Only well founded reasoning (including an educated guess > about the time > and resources required to resolve the issue) shall be accepted by the > community in order to consider postponing the transition. > > With the discussion about the migration going on for quite > some time, and > information available from various places, we do not expect a > delay, but > we would want to give everybody a last opportunity to comment. > > To summarize the dates, we are looking at: > > o 23-Apr-2001: switching to the RPSL database > - All objects are automatically converted to RPSL format > - Queries return RPSL only > - Mirroring follows new format and rules at > whois.ripe.net, port 4444 > - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net > - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, > but are autmatically converted to RPSL > - RFC2725 (Routing Policy Security System) rules apply throughout > > o 14-May-2001: exchanging mail addresses for submitting > RIPE181 and RPSL- > formatted updates > - auto-dbm(a)ripe.net only accepts RPSL updates > - RIPE-181 updates are still possible but now go to > auto-181(a)ripe.net > and are automatically converted to RPSL (again, > RFC2725 rules apply > here as well) > > o 15-Oct-2001: RIPE-181 updates are no longer accepted > > For further reading, please refer to the migration web page > http://www.ripe.net/rpsl > or for the discussion during the joint session of the DB/Routing WGs > please review the minutes. > > For technical specifications of RPSL please refer to > - rfc2622: "Routing Policy Specification Language (RPSL)" > Status: PROPOSED STANDARD, > - rfc2650: "Using RPSL in Practice" > Status: INFORMATIONAL > - rfc2725: "Routing Policy System Security" > Status: PROPOSED STANDARD > > Thanks a lot - the RIPE NCC and the chairmen of > Routing: Joachim Schmitz > DB: Wilfried Woeber > LIR: Hans Peter Holen > >

2 1

Release of patch for ripe-dbase-3.0beta2 software.
by RIPE NCC Staff 01 Mar '01

01 Mar '01

Dear Colleagues, [Apologies for multiple, identical messages]. This mail is to notify you that today, we have released a patch for the ripe-dbase-3.0beta2 software. This patch has several bug fixes. Specifically, this patch includes, amongst other fixes: - TEMPORARY tables in MySQL 3.23 are supported; - a major memory leak on Solaris 8 has been fixed; - CLIENTADDRESS referral now properly passes addresses; - the "-m" queries work now; - memory allocation bug in dbupdate is fixed; - multiple notification problems have been fixed; - improved acknowledgement and notification message formats. You can download this patch at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta3.patch.gz We remind you that you can also test the functionality of this patch for the RIP whois server in 2 ways: - By querying the host reimp.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database. This mirror is in RPSL format. - By using the RIP Test Database. You can send test updates to this database at the address <auto-rip(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test the patch in both ways, and let us know your opinions. Please send your comments and bug reports to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your message. This is a moderated mailing list so some delays in subscription are possible. If you are interested in providing to the community tools and documentation supporting the RIPE-181 to RPSL migration, you are welcome to join the reimp-mig-tf mailing list. To subscribe to this list, follow the instructions given above for subscribing to the db-beta list (doing s/db\-beta/reimp\-mig\-tf/, of course :-). If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee ______________ Databse Group RIPE NCC

1 0

Release of patch for ripe-dbase-3.0beta2 software.
by RIPE Database Administration 01 Mar '01

01 Mar '01

Dear Colleagues, [Apologies for multiple mails]. This mail is to notify you that today, we have released a patch for the ripe-dbase-3.0beta2 software. This patch has several bug fixes. Specifically, this patch includes, amongst other fixes: - TEMPORARY tables in MySQL 3.23 are supported; - a major memory leak on Solaris 8 has been fixed; - CLIENTADDRESS referral now properly passes addresses; - the "-m" queries work now; - memory allocation bug in dbupdate is fixed; - multiple notification problems have been fixed; - improved acknowledgement and notification message formats. You can download this patch from the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta3.patch.gz We remind you that you can also test the functionality of this patch for the RIP whois server in 2 ways: - By querying the host reimp.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database. This mirror is in RPSL format. - By using the RIP Test Database. You can send test updates to this database at the address <auto-rip(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test the patch in both ways, and let us know your opinions. Please send your comments and bug reports to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list so some delays in subscription are possible. If you are interested in providing to the community tools and documentation supporting the RIPE-181 to RPSL migration, you are welcome to join the reimp-mig-tf mailing list. To subscribe to this list, follow the instructions given above for subscribing to the db-beta list (doing s/db\-beta/reimp\-mig\-tf/, of course :-). If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee ______________ Database Group RIPE NCC

1 0

RE: Local Copy of the Database
by Wilfried Woeber, UniVie/ACOnet 21 Feb '01

21 Feb '01

Tim, >I have been asked to investigate the possibility of maintaining a local >copy of the RIPE database. I guess the best source of information about operational requirements is the RIPE NCC, by way of ripe-dbm(a)ripe.net . You have to talk to them anyway (to get your mirror configured, and for (C) issues), so you could do it right at the beginning of your project, I suppose :-) Best regards, _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Local Copy of the Database
by Tim Pettman 21 Feb '01

21 Feb '01

Hi there, I have been asked to investigate the possibility of maintaining a local copy of the RIPE database. I have found the instructions in ripe-157 for setting up a secondary (either static or near real-time), but still have a couple of questions. What are the hardware and software requirements for doing this? How easy is this really to set up and maintain? Your help would be greatly appreciated. -- Tim Pettman VBCnet GB Ltd tjp(a)vbc.net www.vbc.net tel. +44 (0) 117 929 1316 fax. +44 (0) 117 927 2015

1 0

RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 19 Feb '01

19 Feb '01

Hello all, as you are aware, we are preparing the migration of the RIPE database software to support and deploy the new RPSL format. The required steps have been discussed in depth on various occassions (for references, see end of mail). We are now preparing the most important step, really transitioning from old RIPE-181 to new RPSL format: proposed transition date is 23-Apr-2001. This step, once taken, will not be reversed. The majority of the user community takes a neutral role, while some want an earlier, and a few a later date for migration. During the joint session of Routing and DB WG at RIPE38, the chairmen of both WGs were tasked to file a last call for comments on that date, in particular whether there are serious, unresolvable technical or operational problems which would benefit from a slightly longer warning period. According to consensus at the session: If you are convinced that the transition date as proposed would lead to significant operational problems, please explain and justify why within the next 2 weeks: deadline for transition comments: 1-Mar-2001 Only well founded reasoning (including an educated guess about the time and resources required to resolve the issue) shall be accepted by the community in order to consider postponing the transition. With the discussion about the migration going on for quite some time, and information available from various places, we do not expect a delay, but we would want to give everybody a last opportunity to comment. To summarize the dates, we are looking at: o 23-Apr-2001: switching to the RPSL database - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL- formatted updates - auto-dbm(a)ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl or for the discussion during the joint session of the DB/Routing WGs please review the minutes. For technical specifications of RPSL please refer to - rfc2622: "Routing Policy Specification Language (RPSL)" Status: PROPOSED STANDARD, - rfc2650: "Using RPSL in Practice" Status: INFORMATIONAL - rfc2725: "Routing Policy System Security" Status: PROPOSED STANDARD Thanks a lot - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen

1 1

RE: Migration issues: route creation
by Lu, Ping 15 Feb '01

15 Feb '01

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(a)cw.net

2 1

RE: Migration issues: route creation
by Lu, Ping 14 Feb '01

14 Feb '01

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(a)cw.net > -----Original Message----- > From: Lu, Ping [mailto:plu@cw.net] > Sent: Monday, February 12, 2001 10:27 PM > To: 'SchmitzJo(a)aol.com'; andrei(a)ripe.net; reimp-mig-tf(a)ripe.net; > db-wg(a)ripe.net; routing-wg(a)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 > ----------------------------------------------------- > <nic-handle> 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(a)cw.net > > > > -----Original Message----- > > From: SchmitzJo(a)aol.com [mailto:SchmitzJo@aol.com] > > Sent: Monday, February 12, 2001 7:32 PM > > To: andrei(a)ripe.net; reimp-mig-tf(a)ripe.net; db-wg(a)ripe.net; > > routing-wg(a)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 --- > > >

2 1