- db-wg - mailman.ripe.net

Re: Plan of the migration to the new RIPE Database
by Andrei Robachevsky 02 Apr '01

02 Apr '01

Hi Rob, Rob Evans wrote: > > Hi Andrei, > > > Please find below a list of milestones related to the migration to the new > > version of the RIPE Database. > > Silly question; are the times UTC or CET? Sorry about this, all times are CEST (Central European Summer Time, UTC+2). > > Thanks, > Rob Regards, Andrei

1 0

Plan of the migration to the new RIPE Database
by Andrei Robachevsky 02 Apr '01

02 Apr '01

Dear Colleagues, [apologies for duplicate messages] Please find below a list of milestones related to the migration to the new version of the RIPE Database. Your comments and suggestions are welcome. Should you have any further question regarding the migration, please don't hesitate to contact me. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC ------------------------------------------------------------------ Date Actions ------------------------------------------------------------------ 4.04 Final release of the v3.0 DB software 12.04 Advised mirror's switchover to rpsl.ripe.net. - Reminder is sent to NRTM clients on 9.04 - Starting from this date NRTM clients that mirror the RIPE Database are advised to use the new server at rpsl.ripe.net, port 4444 for mirroring. 17-18.04 Migration of the TEST database to v3.0 (RPSL) - TEST Database becomes a RPSL database. Updates are accepted in RPSL format at <test-dbm(a)ripe.net>. - No RIPE-181 TEST database exists anymore. - Estimated downtime 6 hours. 22.04-23.04 Migration of the RIPE Database to v3.0 (RPSL) - New server becomes the official RIPE Database server at 00:00 23.04. - Updates received after 16:00, 22.04 are queued until the new server becomes operational. After that they are automatically converted to RPSL and processed by the new server. New syntax and authorization rules apply. - Downtime in queries will be deliberately introduced to mark the migration. Whois server downtime is planned from 18:00, 22.04 till 00:00 23.04. During this time a message explaining the migration process will be sent as a whois query reply. 23.04, 00:00 New server becomes the official RIPE Database server - Short (1-2 min) downtime is possible during final tests. 23.04, 02:00 New server starts processing updates - Two mail robots are available: <auto-dbm(a)ripe.net> - updates in RIPE-181 format (restrictions apply) <auto-rpsl(a)ripe.net> - updates in RPSL format (recommended).

1 0

RIPE Database Software V3.0 compliance test.
by DB-News 30 Mar '01

30 Mar '01

Dear Colleagues, If you have software that works with RIPE Database Software, then you should make sure that it works with Version 3.0, which will be put into production next month. Compliance tests are available at: http://www.ripe.net/ripencc/pub-services/db/rpsl/usercl.html More information about Version 3.0 of the RIPE Database Software and how it will affect you is available at: http://www.ripe.net/rpsl/ If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee -------------- Database Group RIPE NCC

1 0

RE: Another issue related to the migration
by Hallgren, Michael 29 Mar '01

29 Mar '01

Hi, > > > Dear Colleagues, [...] > > Our suggestion how to deal with these objects is: > > 1. Send a message to the maintainers of these objects asking > them to change the > name to avoid conflict with RPSL specification. > 2. Give two-week notice period after which ripe-dbm will > convert non compliant > as-names using the following mapping: AS-ASNAME -> AS_ASNAME. > > This is more a "cosmetic" change as as-name is not even a > lookup key in the RIPE > Database. Yes. Agree. Been hinting customers to trash/modify such names prior to migration date - not knowing whether or not such conflict would be treated auto-magically... Regards Michael > > Your comments and suggestions are appreciated. > > Best regards, > > > Andrei Robachevsky > DB Group Manager > RIPE NCC > -- Michael Hallgren, Eng., Teleglobe, MH2198-RIPE

1 0

Another issue related to the migration
by Andrei Robachevsky 29 Mar '01

29 Mar '01

Dear Colleagues, [Apologies for duplicate messages] One issue related to RIPE-181 to RPSL migration escaped our attention and has not been discussed. It is related to reserved prefixes that cannot appear in object names according to RPSL specification (RFC2622) which says: "Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names. Names starting with "rtrs-" are reserved for router set names. Names starting with "fltr-" are reserved for filter set names. Names starting with "prng-" are reserved for peering set names." Unfortunately "as-name:" attribute is an object name in RPSL and we have 133 aut-num objects with as-name starting with reserved 'AS-' prefix. Our suggestion how to deal with these objects is: 1. Send a message to the maintainers of these objects asking them to change the name to avoid conflict with RPSL specification. 2. Give two-week notice period after which ripe-dbm will convert non compliant as-names using the following mapping: AS-ASNAME -> AS_ASNAME. This is more a "cosmetic" change as as-name is not even a lookup key in the RIPE Database. Your comments and suggestions are appreciated. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

RE: Summary of the Migration issues
by Lu, Ping 21 Mar '01

21 Mar '01

Some questions followed. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net [snip] > ---------------------------------------- > 1. Route object creation (RFC2725 implications) > > In order to create route object in the RIPE DB, one needs to have > corresponding objects (inetnum or less specific route, and > aut-num) and > pass proper authorization from these objects. > > The problem occurs when someone needs to register route > object which has > either prefix, or origin, or the both from non RIPE IP/ASN space. > > Proposed solution: > 1.1 An as-block object(s) encompassing the non RIPE ASN space will be > created with "mnt-lower:" protected by mntner with NONE auth. > > 1.2 An encompassing inetnum object with "mnt-routes:" protected by > mntner with NONE auth will be created. This will eliminate need for > corresponding inetnum creation and will reduce amount of redundant > information. > > 1.3 In case origin of a route object being created is from non RIPE > space, users will need to create corresponding aut-num object in the > RIPE DB. > Does 1.3 means RIPE is going accept non-RIPE aut-num(AN) object thus a mntner(MT) object to protect that AN thus some person(PN) objects associated with that MT ? And is RIPE going to allow the NONE auth specified in 1.1 and 1.2 to be changed to a real MT once the rightful holder created them ? > > 2. Updates in RIPE-181 format > How about the ftp mirror ? Will RIPE-181 format text files still be available to download after April 23, 2001 or just the RPSL format text files ? [big cut for the rest]

2 1

Summary of the Migration issues
by Andrei Robachevsky 20 Mar '01

20 Mar '01

Dear Colleagues, Please let me summarize the migration issues that have been discussed already and highlight some issues that require more attention. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC ---------------------------------------- 1. Route object creation (RFC2725 implications) In order to create route object in the RIPE DB, one needs to have corresponding objects (inetnum or less specific route, and aut-num) and pass proper authorization from these objects. The problem occurs when someone needs to register route object which has either prefix, or origin, or the both from non RIPE IP/ASN space. Proposed solution: 1.1 An as-block object(s) encompassing the non RIPE ASN space will be created with "mnt-lower:" protected by mntner with NONE auth. 1.2 An encompassing inetnum object with "mnt-routes:" protected by mntner with NONE auth will be created. This will eliminate need for corresponding inetnum creation and will reduce amount of redundant information. 1.3 In case origin of a route object being created is from non RIPE space, users will need to create corresponding aut-num object in the RIPE DB. 2. Updates in RIPE-181 format Migration plan allows users to send updates in RIPE-181 format for some time (until May 14th to <auto-dbm(a)ripe.net>, from May 14th till October 15th to <auto-181(a)ripe.net>) after the migration. In such case objects are automatically converted to RPSL. However the switchover to the new version of the RIPE Database occurs on 23 of April, and since then the following constraints will apply: 2.1 PGP authentication PGP authorization scheme will not work with <auto-dbm(a)ripe.net> robot after 23 April. Updates requiring PGP auth should be sent directly to <auto-rpsl(a)ripe.net>. The problem occurs because after ripe181->RPSL transformation it is impossible to verify signature. For this reason, some updates requiring PGP auth may be rejected during migration. It advisable not to send such updates from 22 April, 9a.m. till 23 April 9a.m. 2.2 New syntax rules When processing an object after ripe181->RPSL conversion new v3.0 syntax rules apply. The results of this will be: - empty attributes (i.e. having no value) are not allowed; - some attributes that were optional before are now mandatory; Also some undocumented behaviour of the v2.x Database will not be supported, namely: - attribute aliases (please see list of aliases attached) are not allowed; - inetnum object cannot be specified in prefix notation. 2.3 New authorization rules New authorization rules defined by RFC2725 apply to creation of aut-num and route objects. See 1. 3. Objects with names containing reserved RPSL prefixes They will be renamed on 2 of April. All references will be updated accordingly. Currently there are 6 of them in the RIPE Database. mntner: AS-5532MNTB mntner: AS-NETLINK-MNT mntner: AS-THENET-MNT mntner: AS-NEW1-MNT mntner: RS-MNT mntner: AS-MNT 4. Broken PGP certificates. They will be deleted on 2 of April. ---------------------- v2.x attribute aliases (not supported in v3.0!): Alias Attrbute change -> changed email -> e-mail fax -> fax-no remark -> remarks deleted -> delete asname -> as-name rev-svr -> rev-srv network -> inetnum netnum -> inetnum

3 3

RFC2725
by Holger Muenx 15 Mar '01

15 Mar '01

Guten Tag, I hope this is the correct forum - if not please direct me to a more appropriate one. After following the discussion for a while I am still unsure about the exact consequences of the activation of RFC2725 on 23-Apr-2001. I will try to summarize my understanding: Please check this and correct me where necessary. You will find a list of open questions at the bottom of this mail. As Frank Bohnsack wrote in http://www.ripe.net/ripe/mail-archives/db-wg/current/msg00090.html AS numbers are allocated to regional registries as shown in http://www.isi.edu/in-notes/iana/assignments/as-numbers and the IPv4 address space allocated to various registries as shown in http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space RFC2725 states in section 9.9 that during addition of an inetnum the most specific matching inetnum is being searched to find the required authentication. During addition of a route the aut-num of the originating AS and either a most specific matching inetnum or a most specific matching route is being searched to find the required authentication. This leaves UUNET in a curious situation. For example, UUNET uses AS 702 which is in the range 1 - 1876 allocated by the ARIN and the inetnum 193.96.0.0/13 which is in 193.0.0.0/8 allocated by the RIPE. With RFC2725 in place UUNET would have its aut-num record in a different registry than its inetnum, rendering it impossible to add routes for the 193.0.0.0/8. There are probably more complications caused by moving data from one registry to another. For example, some people will continue to expect information at the original registry because they did not prepare for RFC2725, breaking mechanisms such as automatic prefix filter creation. Andrei Robachevsky presented two suggestions in http://www.ripe.net/ripe/mail-archives/db-wg/current/msg00095.html Suggestion 1 means that RIPE will implement changes so that RFC2725 will be in effect for AS numbers and IP address space allocated by RIPE only. No checks according to RFC2725 will be done for all other AS numbers and IP address space. Suggestion 2 means that there will be encompassing inetnum objects which contain the address ranges assigned to other registries than RIPE. These objects will have a maintainer with NONE authentication so that everybody can add routes within these inetnum which refer to their own aut-num records. No decision has been made on whether one of the suggestion and, if so, which of them will be implemented. So far my understanding. Please review - if it is completely wrong I hope that I at least amused you. ;-) Thank you for your help! Holger Münx EMEA Access & Backbone Networks UUNET Deutschland GmbH Tel. +49 231 972 0 Sebrathweg 20 Fax. +49 231 972 1111 44149 Dortmund, Germany Holger.Muenx(a)de.uu.net http://www.de.uu.net/

1 0

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

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