- db-wg - mailman.ripe.net

RE: RIPE DB transition and RFC2725
by Lu, Ping 09 Mar '01

09 Mar '01

Comments followed. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Cengiz Alaettinoglu [mailto:cengiz@packetdesign.com] > Sent: Friday, March 09, 2001 11:24 AM > To: Lu, Ping > Cc: 'Frank.Bohnsack(a)de.uu.net'; db-wg(a)ripe.net > Subject: RE: RIPE DB transition and RFC2725 > > > > Lu, Ping (plu(a)cw.net) on March 9: > > Finally somebody express the same concerns as ours. > > > > I have a discussion with the RIPE staff at the RIPE-38 > meeting about this. > > > > There are two seperate issues here: > > 1. The RFC doesn't say a implementation (like RIPE-DB v3.0) > should allow > > foreign references ( using objects from other RR database) or not. > > RFC does not prohibit foreign references. As a matter of fact, RIPE > has a workaround that does this. > > Please also see the companion RFC RFC 2769 for making RFC 2725 checks > across registries. RFC 2769 and 2725 together yield a global > distributed registry. Of course, it requires cooperation form other > (at lease regional) registries. > The wrokaround means DISABLE integrity checking. That's an option for RIPE-DB v2.x (RIPE-181) but we haven't tried RIPE-DB v3.x yet. Also the workaround raises another question: How do you authorize the route creation from a foreign AS ? That's exactly the issue from Andrei's previous email (subject: Migration issues: route creation). And the solution to this needs to be discussed further. ( Hi, Andrei, any more suggestions from the community yet ?) > > 2. The assumption of RIPE-DB v3.0 is that all object > references have to be > > resloved locally( ie. with source: RIPE). > > > > The 2nd issue means if any ISP with ARIN's AS number want > to register a > > route with RIPE you have to register your PN(person) then > your MT(mntner) > > then your AN(aut-num) with RIPE first. > > > > So each ISP has to maintain a different set of objects with each RR. > > AS123(in RIPE) -> MNT-AS123-RIPE -> NIC456-RIPE > > AS123(in ARIN) -> MNT-AS123-ARIN -> NIC456-ARIN > > AS123(in APNIC) -> MNT-AS123-APNIC -> NIC456-APNIC > > AS123(in JP) -> MNT-AS123-JP -> NIC456-JP > > AS123(in DE) -> MNT-AS123-DE -> NIC456-DE > > .... > > > > Just to remember to update all these information everytime > there is a little > > tiny change. > > It is fun, isn't it ? > > > > And NO you can't get all route information from just one RR > unless we all > > sit down and seriously > > talking about the GLOBAL issues. > > > > Ping Lu > > Cable & Wireless Global > > Network Tools and Analysis Group, USA > > W: +1-703-292-2359 > > E: plu(a)cw.net > > > > > > > -----Original Message----- > > > From: Frank Bohnsack [mailto:Frank.Bohnsack@de.uu.net] > > > Sent: Friday, March 09, 2001 7:43 AM > > > To: db-wg(a)ripe.net > > > Subject: RIPE DB transition and RFC2725 > > > > > > > > > Dear colleagues, > > > > > > Yes, I know the deadline for transition comments is over, but > > > after studying RFC2725 we need a confirmation for our > understanding. > > > > > > RFC2725 defined the need for an "as-block" object for each related > > > "aut-num" object and an "inetnum" object for each related > > > "route" object. > > > > > > The assignment of AS blocks and IP space is managed by IANA. > > > * http://www.isi.edu/in-notes/iana/assignments/as-numbers > > > * http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space > > > > > > Does the new RIPE DB manage only "as-blocks" and > "inetnums" which are > > > assigned to RIPE ? > > > > > > 1/ And if I'm right, is it true that we can't store our ASes > > > 702, 1270 > > > and a lot of routes (assigned to ARIN) in the new > RIPE database ? > > > > > > 2/ And is it true that we therefore can't set our route > > > (assigned to RIPE) > > > objects origin to our ASes ? > > > > > > The solution for 1/ is moving to ARIN, but what might be the > > > solution for 2/ > > > ? > > > > > > You say a big ISP is anyway talking to multiple IRRs, but I > > > think customers > > > who want to peer with these can't get complete information > > > while using RIPE > > > DB only. > > > > > > > > > Cheers > > > Frank > > > > > > -- > > > Frank Bohnsack email fb(a)de.uu.net > > > UUNET, A Worldcom Company phone +49 (0)231 972-1495 > > > EMEA Access & Backbone Networks fax +49 (0)231 972-1188 > > > Team Dortmund web www.de.uu.net > > > > > > Cengiz > > -- > Cengiz Alaettinoglu Packet Design >

2 1

RE: RIPE DB transition and RFC2725
by Lu, Ping 09 Mar '01

09 Mar '01

Finally somebody express the same concerns as ours. I have a discussion with the RIPE staff at the RIPE-38 meeting about this. There are two seperate issues here: 1. The RFC doesn't say a implementation (like RIPE-DB v3.0) should allow foreign references ( using objects from other RR database) or not. 2. The assumption of RIPE-DB v3.0 is that all object references have to be resloved locally( ie. with source: RIPE). The 2nd issue means if any ISP with ARIN's AS number want to register a route with RIPE you have to register your PN(person) then your MT(mntner) then your AN(aut-num) with RIPE first. So each ISP has to maintain a different set of objects with each RR. AS123(in RIPE) -> MNT-AS123-RIPE -> NIC456-RIPE AS123(in ARIN) -> MNT-AS123-ARIN -> NIC456-ARIN AS123(in APNIC) -> MNT-AS123-APNIC -> NIC456-APNIC AS123(in JP) -> MNT-AS123-JP -> NIC456-JP AS123(in DE) -> MNT-AS123-DE -> NIC456-DE .... Just to remember to update all these information everytime there is a little tiny change. It is fun, isn't it ? And NO you can't get all route information from just one RR unless we all sit down and seriously talking about the GLOBAL issues. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Frank Bohnsack [mailto:Frank.Bohnsack@de.uu.net] > Sent: Friday, March 09, 2001 7:43 AM > To: db-wg(a)ripe.net > Subject: RIPE DB transition and RFC2725 > > > Dear colleagues, > > Yes, I know the deadline for transition comments is over, but > after studying RFC2725 we need a confirmation for our understanding. > > RFC2725 defined the need for an "as-block" object for each related > "aut-num" object and an "inetnum" object for each related > "route" object. > > The assignment of AS blocks and IP space is managed by IANA. > * http://www.isi.edu/in-notes/iana/assignments/as-numbers > * http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space > > Does the new RIPE DB manage only "as-blocks" and "inetnums" which are > assigned to RIPE ? > > 1/ And if I'm right, is it true that we can't store our ASes > 702, 1270 > and a lot of routes (assigned to ARIN) in the new RIPE database ? > > 2/ And is it true that we therefore can't set our route > (assigned to RIPE) > objects origin to our ASes ? > > The solution for 1/ is moving to ARIN, but what might be the > solution for 2/ > ? > > You say a big ISP is anyway talking to multiple IRRs, but I > think customers > who want to peer with these can't get complete information > while using RIPE > DB only. > > > Cheers > Frank > > -- > Frank Bohnsack email fb(a)de.uu.net > UUNET, A Worldcom Company phone +49 (0)231 972-1495 > EMEA Access & Backbone Networks fax +49 (0)231 972-1188 > Team Dortmund web www.de.uu.net >

3 2

RIPE DB transition and RFC2725
by Frank Bohnsack 09 Mar '01

09 Mar '01

Dear colleagues, Yes, I know the deadline for transition comments is over, but after studying RFC2725 we need a confirmation for our understanding. RFC2725 defined the need for an "as-block" object for each related "aut-num" object and an "inetnum" object for each related "route" object. The assignment of AS blocks and IP space is managed by IANA. * http://www.isi.edu/in-notes/iana/assignments/as-numbers * http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space Does the new RIPE DB manage only "as-blocks" and "inetnums" which are assigned to RIPE ? 1/ And if I'm right, is it true that we can't store our ASes 702, 1270 and a lot of routes (assigned to ARIN) in the new RIPE database ? 2/ And is it true that we therefore can't set our route (assigned to RIPE) objects origin to our ASes ? The solution for 1/ is moving to ARIN, but what might be the solution for 2/ ? You say a big ISP is anyway talking to multiple IRRs, but I think customers who want to peer with these can't get complete information while using RIPE DB only. Cheers Frank -- Frank Bohnsack email fb(a)de.uu.net UUNET, A Worldcom Company phone +49 (0)231 972-1495 EMEA Access & Backbone Networks fax +49 (0)231 972-1188 Team Dortmund web www.de.uu.net

1 0

Re: Announcement: Hardware upgrade of whois server
by Stephen Burley 07 Mar '01

07 Mar '01

Sorry for any duplication > Dear colleagues, > > After experiencing performance slow-down on our whois service, we > decided > to upgrade the hardware of our primary whois server. > > The upgrade will take place on 9 March, 2001, Friday. It will start at > 8:00am CET and planned to last approximately 2 hours. Just a quick quaestion, Why Friday and why during working hours? All our maint slots have to be out of hours and not preceding a weekend. Curious -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------

2 1

Announcement: Hardware upgrade of whois server
by RIPE Database Administration 07 Mar '01

07 Mar '01

Dear colleagues, After experiencing performance slow-down on our whois service, we decided to upgrade the hardware of our primary whois server. The upgrade will take place on 9 March, 2001, Friday. It will start at 8:00am CET and planned to last approximately 2 hours. During the operation, whois queries will be directed to our secondary server and the incoming update messages will be queued, to be processed later. We apologize for any inconvenience this may cause. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

2 1

RIPE RPSL transition date set!
by SchmitzJo＠aol.com 05 Mar '01

05 Mar '01

Hello all, following up on our last call for comments on the RPSL transition for the RIPE database, we did not receive any mails or information which may have delayed the transition. In contrast, we received a set of supportive mails. Accordingly, the transition to RPSL will now follow the outlined dates: o 23-Apr-2001: switching to the RPSL database *** now set *** - 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 We will continue to update you prior to the dates detailed above. Thanks - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen

1 2

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

02 Mar '01

Dear Christian, you wrote: > well I'd say go for it. Thank you for your support. > 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. I believe that this request is more than legitimate, and that the NCC is hearing you very well - after all it is in all our interest to have this running. > > 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. This is currently worked on, as I hear. > > In addition, any clear links to concise How2do documents on RAToolSet > and RtConfig would be appreciated. On the one hand, I think the best source for that still is http://www.isi.edu/ra/RAToolSet/ On the other hand, we will have a tutorial on the RAToolSet during RIPE39. This has been confirmed by now, and I believe that additional documentation will become available around it. Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

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