- db-wg - mailman.ripe.net

Re: Migration issues: route creation
by Andrew Hilborne 13 Feb '01

13 Feb '01

"Lu, Ping" <plu(a)cw.net> 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

1 0

1. draft minutes of joint Routing/DB wg session RIPE38
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

R I P E 3 8 A M S T E R D A M Joint Session DB and Routing 24-Jan-2001 Draft Minutes Chairs: Joachim Schmitz, Wilfried Woeber Scribe: Engin Gunduz Participants: 97 Joint Session of Routing and Database Working Groups Due to the importance of the subject, and the overlap in topic, the chairmen of Routing and Database WG (Wilfried Woeber) decided to have a joint session of both WGs. Joachim introduced the audience to the session, and chaired it together with Wilfried. E. Migration to the new RIPE database (Andrei Robachevsky, RIPE NCC) (20min) [ The presentatino is available at http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/r38-reimp-a… ei/index.html ] Andrei gave an overview of what to expect for the migration to the new RIPE database. He began with asking who would be affected by the migration, and the answer is: everybody. Reasons are - RPSL format - new access control - new database format - new version mirroring protocol He supported this by a set of examples, and made suggestions on how to prepare for the migration, depending on which usage group a database user belongs to - query users - update users - adaptation of scripts - near real time mirroring Following that a schedule was presented which summarized the proposed final transition dates - 23-Apr-2001: switching to the RPSL database Queries return RPSL only Mirroring follows new format and rules at whois.ripe.net, port 4444 RPSL updates go to auto-rpsl(a)ripe.net RIPE-181 updates are still possible and still go to auto-dbm(a)ripe.net, but are autmatically converted to RPSL - 14-May-2001: exchanging mail addresses 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 - 15-Oct-2001: RIPE-181 updates are no longer possible The crucial date is the first one. It will not be possible to go back after that date. The RIPE NCC has prepared a vast set of aides to assist in the transition, and to get used to RPSL format. All details are available at the RIPE-181 to RPSL transition web page http://www.ripe.net/rpsl The presentation led to a vivid discussion, in particular whether the first transition date is too early or too late. Ping Lu was suggesting to move the dates further into the future because - they are using a lot of off-line tools - the downstreams need to be educated He later explains that he himself would transition rather earlier than later but he is worried about their vast customer base. Joachim pointed out that the transition should not be delayed because RADB is already running RPSL since quite some time, making it more complicated for people using both RADB and RIPE. Moreover, he thought that someone had written some tool to perform at least in part some back conversion from RPSL to RIPE-181, which as Wilfried Woeber pointed out would only be possible for a limited number of objects. However, such tool never was available. Christan Panigl reminded the audience that the idea had come up to supply a RAToolSet tutorial at the next RIPE meeting. He suggested to run it before the transition to the RPSL database, essentially before 23-Apr. The audience wants to have this tutorial parallel to the next RIPE meeting. However, this would delay the first transition date into May. A quick poll showed that 10 people in the audience knew RAToolSet, and that actually 2 were using it in conjunction with RADB. It obviously makes sense to have a tutorial -> action 38.R1 on Wilfried Woeber and Joachim Schmitz to organize a RAToolSet tutorial at the RIPE39 meeting Ruediger Volk points out that a transition very shortly after the tutorial does not make much sense. He also stresses that he objects against postponing the transition, because other transition projects within his company have already been delayed due to the not yet factual transition with RIPE. Jake Khuon agrees with Ruediger. He also points out that many of the objects are doubly registered both in RADB and RIPE. Joachim asked the audience who of them are actually using any kind of automated tools in conjunction with the database, and it turned out that these were more or less the same people who also knew RAToolSet. Accordingly, most of the people requesting a tutorial on RAToolSet do not need it right now and are thus also not affected for automation. This decouples the dates of when the tutorial will be held, and the transition to RPSL. Consequently, even though these are only proposed dates, Wilfried suggests to stick to these dates, and people who think that they have real technical problems must speak up to the community to have those reviewed. -> action 38.R2 on Wilfried Woeber and Joachim Schmitz to send around the transition dates, get input from the community, with a following decision on the dates Ping Lu thinking of interaction of databases then brings up the topic of global NIC handles. Wilfried explains that globally unique NIC handles are not related to RPSL, or the transition to RPSL. He has it on his agenda for the Database WG session tomorrow (25-Jan). F. Report from the DB migration task force (Wilfried Woeber, Andrei Robachevsky) Wilfried reported that the DB migration task force did a review and besides a set of questions identified by some active members of the user community, the following open issues were identified - Outreach The RIPE NCC has taken every effort to notify all parties repeatedly who will be affected by the transition. Disappointingly, the feedback on these efforts has been small. - Other items are * broken PGP keys * unprotected aut-num objects * object names not compliant with RPSL which were discussed in a short presentation by Andrei Andrei gave a few statistics on those items, first on their efforts to contact parties which need to be involved, and then on the open issues where Joao Damas explained the proposed solutions. - Broken PGP keys The old PGP programs generated non-compliant PGP keys. Those keys will be refused by version 3 software. It turns out that 7 out of 409 PGP keys are broken. The proposed solution is to delete the key certificates. This does not affect security for a simple reason: If someone wants to apply a change to objects protected that way, the software does not find the corresponding key certificate, and thus rejects the update. The party who wants to submit the change will then be required to contact the RIPE NCC. It was general consensus in the audience to follow that approach. - Unprotected aut-num objects In the past, it had become mandatory to have aut-num objects protected by a maintainer. However, 119 out of 4008 aut-num objects still today do not have a mnt-by attribute. So far, they enjoy a "special" protection: Only ripe-dbm can modify them. Surprisingly, none of them was ever touched in all the time since the original change of requirements. It is still mandatory to have a maintainer with each aut-num object in RPSL. The question is of how to proceed. The proposed solution is to add a special RIPE NCC maintainer. By that way, no security breach is opened, and no change compared to the situation today is introduced. If anybody ever wants to touch that aut-num object again, they still need to contact ripe-dbm. It was general consensus in the audience to follow that approach. - Reserved RPSL names Quite a lot of objects in the database have names which do not comply with RPSL rules. An example are 108 aut-num objects using the reserved prefix "AS-" in the AS-name attribute, or 7 maintainer objects with other reserved prefixes. The proposed solution is to change the names prior to transition in a way which still needs to be agreed upon. A suggestion is to contact all parties who own those objects, and also publish them on appropriate RIPE mailing lists. It was general consensus in the audience to follow that approach. Those results were taken to the Database WG. Ping Lu raised the question whether there was the intention to implement global maintainers. Andrei explained that so far all references must be resolved locally. Andrei also showed which OSs are currently supported for the database software o Solaris 2.8 (Intel & Sparc) o Linux (RedHat, SuSe). o FreeBSD The inquiry from Wilfried showed that this list is accepted by everybody, and no other OSs seem to be used by any company of registry, meaning from that side no problems are expected. Wilfried asked the NCC to release the database software for all platforms without putting too much effort into performance tweaking for each individual OS, just assuring its overall functionality. Anybody who wants to participate in the transition discussion is free to join the migration task force mailing list reimp-mig-tf(a)ripe.net Summary of Open Action Points from the Joint Session of DB and Routing 38.R1 on J.Schmitz, W.Woeber Organize RaToolSet tutorial at RIPE 39 status: new 38.R2 on J.Schmitz, W.Woeber Collect final community input on DB migration dates status: new Engin Gunduz, Joachim Schmitz, February 2001

3 3

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

13 Feb '01

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 --- >

1 0

Re: Migration issues: route creation
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

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 ---

1 0

problems with complex import/export attributes
by Frank Bohnsack 12 Feb '01

12 Feb '01

Hi, Yes, I know this is not a RPSL forum, but i think someone of you could help me ;-) I found a problem for RPSL parsers conform with RFC2622. In the RFC2622 (section 6.6) is an example of an import attribute: > import: from AS1 action pref = 1; accept as-foo; > except { > from AS2 action pref = 2; accept AS226; > except { > from AS3 action pref = 3; accept {128.9.0.0/16}; > } > } Appendix B "Grammar Rules" describes the syntax like below: > ... > import_attribute: ATTR_IMPORT > | ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor > > import_expression: import_term > | import_term KEYW_REFINE import_expression > | import_term KEYW_EXCEPT import_expression > > import_term: import_factor ';' > | '{' import_factor_list '}' > > import_factor_list: import_factor ';' > | import_factor_list import_factor ';' > > import_factor: import_peering_action_list KEYW_ACCEPT filter > > import_peering_action_list: KEYW_FROM peering opt_action > | import_peering_action_list KEYW_FROM peering opt_action > > ... I feel in import_attribute lakes a line like: | ATTR_IMPORT opt_protocol_from opt_protocol_into import_expression and a look into ftp://ftp.isi.edu/ra/RAToolSet/RAToolSet-4.6.3.tar.gz file src/rpsl/rpsl/rpsl.y agree with me: > ... > import_attribute: ATTR_IMPORT > opt_protocol_from opt_protocol_into > import_expr TKN_EOA { > $$ = changeCurrentAttr(new AttrImport($2, $3, $4)); > } > | ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor TKN_EOA { > PolicyTerm *term = new PolicyTerm; > term->append($4); > > $$ = changeCurrentAttr(new AttrImport($2, $3, term)); > } > | ATTR_IMPORT error TKN_EOA { > $$ = $1; > handle_error("Error: from <peering> expected.\n"); > yyerrok; > } > ; > .. OK as so far, but rpslcheck as well as my perl parser module breaks while parsing the example above ;-( > fb@sun5 1315> rpslcheck < example > ... > import: from AS1 action pref = 1; > accept as-foo; > except { > from AS2 action pref = 2; accept AS226; > except { > ^^^^^^ > ***Error: from <peering> expected. > from AS3 action pref = 3; accept {128.9.0.0/16}; > } > } > ... For me looks the grammar correct, but my knowledge about automata theory, languages and computation is worser than my english ;-) Has anybody a solution for this problem ? cheers frank

2 1

Re: Modifying 'person:' objects
by Carsten Schiefner 11 Feb '01

11 Feb '01

So, how to proceed here now? Can we agree on the follwoing: A 'force:' attribute for changing the 'person:' attribute itself shall be allowed if and only if the person or role object is maintained and the maintainer uses "strong" protection, such as 'password' or 'PGP'. Already appreciating your comments, Carsten -------- Original Message -------- Subject: Modifying 'person:' objects Date: Mon, 29 Jan 2001 14:02:47 +0100 From: Carsten Schiefner <carsten.schiefner(a)tcpip-gmbh.de> To: db-wg(a)ripe.net Colleagues, as a follow-up of the short discussion we have had last week during RIPE 38 I'd like to continue this discussion in the appropriate forum, the db-wg mailing list. What from time to time really annoys me is the fact that you cannot change a person's name (necessary due to misspellings etc.) that is already referenced because the person's name together with the NIC handle is the primary key. You cannot delete and re-enter it either because it's already referenced. The only way to go is to send an email to the human db processor ;-) 'ripe-dbm(a)ripe.net' to get the data changed manually. I consider this as not very efficient. During the meeting we were told by Joao and/or Andrej that basically there is no further need to have person's name _AND_ NIC handle as the primary key, only the NIC handle would be enough. Anyhow, I wouldn't like to touch this pragma. What I would like to propose is a second "pseudo" attribute in addition to 'delete:' - having no documentation purpose but functionality: the "I really know what I am doing right at the moment" attribute ('irkwiadratm:' ;-). This second "pseudo" attribute overruns the above mentioned db pragma and forces a change in a person's name (so 'force:' migt be better...). Where I haven't made up my mind yet is the question whether this always should apply or only in thoses cases when a person object is maintainer protected. There might be further cases I have not in mind at all at the moment - so... Any comments will be appreciated. Best regards, -C.

1 0

Software engineer position at RIPE NCC
by Andrei Robachevsky 08 Feb '01

08 Feb '01

Dear Colleagues, This is to inform you that the RIPE NCC has a vacancy for a Database Software Engineer. If you are interested, please visit our web site for more information: http://www.ripe.net/ripencc/employment/db-softeng-feb01.html. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Performance slowdown of whois server
by RIPE Database Administration 08 Feb '01

08 Feb '01

Dear colleagues, Currently we are experiencing a performance slowdown on our whois server, thus, the server takes more time than usual to reply queries. We are investigating the issue and will take appropriate measures ASAP. We are sorry for any inconvenience. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Planned maintenance
by RIPE Database Administration 07 Feb '01

07 Feb '01

Dear colleagues, To improve the quality of our service, we decided to report on reindexing of our database, and other maintenance issues. We will continue to do this if the community thinks this is a good idea. Next weekend, 10-11 February 2001, RIPE NCC will reindex the person objects in RIPE whois database. This is a usual maintenance practice, performed once every three weeks. The reindexing will start at 2:00am Saturday, and is expected to last around 40 hours, due to the very high number of person objects in our database. During the reindexing, it won't be possible to update, delete, or create person objects. The messages containing person objects will be queued. Any person object in an update message to <auto-dbm(a)ripe.net> will cause the whole update message to be blocked until the reindexing process finishes. Thus, we suggest our users not to put person objects in a message that contains other types of objects. Reindexing will not be needed in version 3 of our database software. You can see a schedule for this and other maintainance issues at: http://www.ripe.net/ripencc/pub-services/db/DBstatus.html This page will be updated regularly. We apologize for any inconvenience the maintenance may cause. If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Modifying 'person:' objects
by Carsten Schiefner 05 Feb '01

05 Feb '01

Colleagues, as a follow-up of the short discussion we have had last week during RIPE 38 I'd like to continue this discussion in the appropriate forum, the db-wg mailing list. What from time to time really annoys me is the fact that you cannot change a person's name (necessary due to misspellings etc.) that is already referenced because the person's name together with the NIC handle is the primary key. You cannot delete and re-enter it either because it's already referenced. The only way to go is to send an email to the human db processor ;-) 'ripe-dbm(a)ripe.net' to get the data changed manually. I consider this as not very efficient. During the meeting we were told by Joao and/or Andrej that basically there is no further need to have person's name _AND_ NIC handle as the primary key, only the NIC handle would be enough. Anyhow, I wouldn't like to touch this pragma. What I would like to propose is a second "pseudo" attribute in addition to 'delete:' - having no documentation purpose but functionality: the "I really know what I am doing right at the moment" attribute ('irkwiadratm:' ;-). This second "pseudo" attribute overruns the above mentioned db pragma and forces a change in a person's name (so 'force:' migt be better...). Where I haven't made up my mind yet is the question whether this always should apply or only in thoses cases when a person object is maintainer protected. There might be further cases I have not in mind at all at the moment - so... Any comments will be appreciated. Best regards, -C.

3 3