- routing-wg - mailman.ripe.net

PAM2001 registration opens (reminder)
by Henk Uijterwaal (RIPE-NCC) 14 Feb '01

14 Feb '01

---------- Forwarded message ---------- Date: Wed, 3 Jan 2001 14:53:19 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" <henk(a)ripe.net> To: Undisclosed recipients: ; Subject: PAM2001 registration opens Passive & Active Measurement: PAM-2001 Registration Opens A workshop on passive and active measurement techniques for high speed computer networks and the Internet Amsterdam, the Netherlands, April 23-24, 2001 As the Internet has grown over the last decade the need for precise measurement of network traffic has become steadily more apparent; most of today's Internet Service Providers and many of their large network customers are collecting and analysing traffic data for the purposes of performance monitoring, network engineering and cost recovery, but the engineering quality of these measurements vary. A steadily growing number of research groups have been working in the areas of: - Active Measurements, i.e. sending test packets and observing their progress through the Internet, - Passive Measurements, i.e. observing actual traffic on 'live' networks, - Performance Metrics, i.e. developing measures or indicators which can be used to characterise traffic behavior, - Traffic Statistics, i.e. attempting to understand and develop models of 'real' Internet traffic, and - Visualisation, i.e. finding effective ways to display what's happening in a network. After the successful workshop PAM2000 in Hamilton, New Zealand, in April 2000, the RIPE NCC will be organising another workshop on this topic in Amsterdam in April 2001. Registration for this workshop has now been opened. To register online, go to: http://www.ripe.net/cgi-bin/pamreg Also available on the web-site are the preliminary program: http://www.ripe.net/pam2001/program.html as well as general information on the workshop: http://www.ripe.net/pam2001/ and hotel information: http://www.ripe.net/pam2001/hotels.html Rooms are available at the conference hotel. The rate is 285 Euro/night (including taxes, approximately 255 US$). To reserve a room, call, fax or email the hotel. Contact details can be found on the web page. If you prefer to stay in another hotel, then there are rooms available in all price classes between 35 Euro/night and 1500 Euro/night within a 5 km radius of the conference site. A selection of hotels and links to reservation sites can be found on the webpage. There are still opportunities for participants to present measurement equipment and software. Proposals for demonstrations (about 500 words, plain ASCII) should be sent by email to the conference chair at pam2001(a)ripe.net by 5 March 2001. Contact information: * PAM 2001 c/o RIPE-NCC Singel 258 1016 AB Amsterdam The Netherlands * Phone: +31.20.5354444 * Fax: +31.20.5354445 * Email: pam2001(a)ripe.net * Webpage: http://www.ripe.net/pam2001 ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous)

1 0

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

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

1. draft minutes from the RIPE38 Routing WG session
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 Routing Working Group Session 24-Jan-2001 Draft Minutes Chair: Joachim Schmitz (JS395-RIPE) Scribe: Engin Gunduz Participants: 97 A. Preliminaries (Joachim Schmitz) The chair man welcomed the participants, and distributed the participants' list to sign in. Engin Gunduz volunteered to take the minutes. The WG agenda was accepted without changes. The minutes of the previous meeting at RIPE37 were accepted by the participants, and are thus declared final. B. The Hermes Project (Giuseppe di Battista, University of Rome) [ The presentation will become available shortly at the RIPE web server ] URL: http://www.dia.uniroma3.it/~hermes The idea of the Hermes project is the integration and visualisation of Routing Registries Information and BGP Routing Data. Consequently, major targets are to o explore the Internet interactions at AS level o visualise interactive maps o show inconsistencies Hermes is based upon a o 3-tier architecture o repository of routing information o mediator for the information integrity. o graph drawing module After presenting the general outline and functionality, Guiseppe showed a demo prerecorded with a screencam from a life example around AS137. This demo included - peering activities (neighbor ASs, and routes) supplemented with more info from the IRR database - in/out routing policies - paths to another AS with routes from that AS and description from the IRR supplemented by AS macros involvede, plus which ASs are part of them Another demo showed more details around routing policies, where the AS was initially selected by its name in the IRR - showing inconsistencies of registered policies of connected ASs The results can be viewed as text and in a graphical map. Guiseppe continued with more details on the internal structure of how Hermes works. In particular he described - three tier architecture - data integration - mediator for data processing - graph drawing around the difficulties introduced by locally sparse and extremely dense parts requiring complex algorithms Eventually, current and future work was summarized: - moving from RIPE-181 to RPSL format (March 2001) - adding new sources of information (RIS project?) - distinguishing between different sources of information (June 2001) - visualisation and animation of route flaps (June 2001) - looking inside an AS: traceoute (June 2001) - looking inside an AS: OSPF (June 2001) Finally, a brief distinction compared to other similar projects was given: o skitter (Caida) [global view of Internet] o ASExplorer (IPMA) [specific view of one single AS] o Hermes [in between] In the brief following discussion, the impression was that Hermes is a useful tool, comprising information from different sources. Q (chair): It is not entirely obvious which data comes from which source. Is this shown in the tool? A: It should be relatively easy, and is actually planned. Q (Ping Lu): What are the means of output? A: So far, the data can only be printed. Since this is a Java applet, it is difficult to produce output in many formats and save them to local disk As final summary, Guiseppe stressed that he welcomes suggestions like this, and asked for any additional input to be sent to him and his group (contact details on the web page http://www.dia.uniroma3.it/~hermes) C. RIS Report (Henk Uijterwaal, Thomas Franchetti, Antony Antony, RIPE NCC) [ Presentation is online at: http://www.ripe.net/ripencc/pub-services/np/Talks/0101_RIPE38_HU/ http://www.ripe.net/ripencc/pub-services/np/Talks/0101_RIPE38_AA/ http://www.ripe.net/ripencc/pub-services/np/Talks/0101_RIPE38_TF/ ] The RIS group gave three presentations 1. Henk Uijterwaal In the introduction, Henk listed a few administrative items - RIS has progressed that for that it will be turned into a regular operational service very soon - To support this move, they are now hiring a 2nd network engineer which will bring the headcount to 2.5 FTE's plus 1 student (from 1-Apr on) - Henk again announced the PAM-2001 workshop Then, a sumamry of the highlights in the past months was given - a new database was introduced to keep up with performance requirements - more powerful hardware was installed, and a scaling analysis will be done with it - currently there are 4 Remote Route Collectors (RRC) at RIPE NCC, LINX, AMS-IX, SFINX; anybody interested in peering to put data into RIS is welcome to contact Antony Antony - two more RRCs are planned, investigating where to place them - work has been done on the user interface, with output on: web, email - vanilla, strawberry, chocolate: which view of the routes do we have in the RIS? The flavors distinguish different amounts of routing info, ranging from filtered and restricted output (vanilla) to the full set of routes (chocolate); RIS prefers to see more - following several requests from different sources (ISMA project, Hermes, ASExplorer,...), the raw data is now available (announced yesterday), check out URL http://abcoude.ripe.net/ris/rawdata During the next months the RIS team plans to - move to production during 2001 - proceed with route collection and expand it - improve and extend the user interface - proceed with network research Henk stressed again that he very much welcomes welcomes input from the community on this project. Joachim reminded Henk of the action, the Routing WG has put on the RIS team, to also implement route flap statistics. Henk confirmed that this is on the list of topics to analyse. 2. Thomas Franchetti In the second part, Thomas presented some results from data collected by RIS - statistics of numbers of prefixes by length show a noticable increase of /24, and /32 - origin ASs announcing only one prefix - distribution of prefix lengths again shows the increase of /24, and /32 - statistics of how many ASs announce certain number of prefixes most ASs announce only very few prefixes, number of announcements per AS is on average decreasing The graphs shown will be made available on the web before RIPE39. Conclusion: - it is necessary to view larger periods to see trends more clearly. - there is a lot of data in RIS, and lots of potential ways to analyze it, but not easy to find ways of presentation; this definitely needs to be explored Joachim finds the parallels interesting between the RIS project results, and other analysis like the one by Philip Smith (distributed on the Routing WG mailing list), or the "standard" CIDR report by Tony Bates. Joachim is eager to see more results at RIPE39, and also welcomes any input from the community; after all these stats are just a glimpse at the wealth of data collected at RIS. 3. Antony Antony In the third part of the presentations on RIS, Antony presented some peculiar RIS observations: - regarding negligence in aggregation, it is amazing how big a number of more specifics is announced from small prefixes (up to several 1000s in a /8) - looking at AS path length, a path with 123 ASs was found, which is very peculiar; this causes several problems, e.g. Cisco actually resets because of missing buffer space; there is also a known Cisco bug where an empty AS path may appear, and thus care must be taken if filtering on AS path length - if AS numbers are considered as such, roughly 82% of RIPE NCC assigned AS numbers are visible by RIS, and the question arises: where are the others? Actually, the RIPE region is still in pretty good shape because the global average is 50%. Following up on this, Daniel Karrenberg added some observations and comments. He noted that the full feed they get from a neighbor consists of 81,272 prefixes, but the maximum number of prefixes from a peer is 100,461. In the beginning, the difference between the extremes was just a couple of thousands, but obviously has expanded tremendously. As Randy Bush has pointed out during the EOF session, it is possible to go down to around 80k prefixes without loosing connectivity. Possibly, people announce redundant data. RIS may be used to catch the source of those redundant data. Daniel was musing whether the NCC should suggest filter lists but would want more discussion on that. D. Routing Registry Consistency Checking (Shane Kerr, RIPE NCC) [ The presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/rrcc-ripe38… dex.html ] Shane reports that the RIPE IRR currently holds around 24k route objects and 4k AS objects. The quality of the contents varies widely, because there are people who really update their objects, and others who don't. To improve data quality, the data in the IRR is compared to what is found on the Internet. However, the goal is not just reporting, but help to improve the IRR and make it more useful. This is the idea behind the Routing Registry Consistency Checking (R2C2). The following slides gave an overview of the approach, the status, progress, and the plans of the project. Besides route objects and AS objects (routing policies), there are also supporting objects like AS macros which form a set of data to be compared to RIS data. Several reports and tools are in the make, like - summary report - specific report - router configuration checker - IRR correction wizard The project has reached a status where comparisons are possible, and mismatches may be identified. Prototype interfaces and a prototype correction wizard are available. A web page for the project exists with a practical example of the prototype interface. The next steps include polishing and finishing current software, publishing a summary of the project as RIPE-201 document, and seeking community input. Potential possible directions include - a view from specific route collector on request - checking aut-num policy with AS paths - a router configuration verification Additional suggestions include working together with other IRRs and on request from the community develop further applications. This was the last topic in the Routing WG session itself. The second slot was dedicated to a joint session of the Routing and Database WGs dealing with RPSL transition issues. Y. Input from other WGs There was no input from other WGs. Z. AOB There was no other business. Summary of Open Action Points from the Routing WG 36.R1 on RIPE NCC During the transition phase to the RPSL software - verify with RADB on their test suites for RPSL implementations - coordinate with RADB on consistent mirroring of databases (NRTM) - coordinate with RADB on consistent whois interface of databases including irrd status: ongoing 37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz Provide updates to RIPE-210 - general editing, review - explanation of damping parameters - examples by implementation - script to determine TLD/root nameservers for "golden network" list status: ongoing 37.R2 on RIS team, Henk Uijterwaal Implement route flap analysis from RIS data status: ongoing Engin Gunduz, Joachim Schmitz, February 2001

1 0

Re: The Cidr Report
by SchmitzJo＠aol.com 12 Feb '01

12 Feb '01

Dear Tony, you wrote: > [...] > 2) It seems folks don't use it as much as they can as I see very little > positive changes anymore. > > However, having said this I would like to understand from folks (reply > directly) if you think I should continue to generate this. > [...] > However, it is > worth having a quick look for config errors and would encourage providers > to do this periodically. > Well, I do include the mailing lists on purpose in my answer... I very much support that you continue to generate the CIDR reports, and distribute them. The reasons are manifold, and go far beyond sentimental feelings about one of the institutional reports on the Internet. Why did we start this in the first place? To put up a flag against exponential routing table growth. And it worked - growth was down to roughly linear for quite some time. However, newer analysis e.g. by Philip Smith or recently by the new RIS project at the RIPE NCC shows that the Internet has again embarked on exponential growth of the routing table (e.g. I still doubt that several *thousand* longer prefixes announced from one /8 make a lot of sense, or the tremendous increase of longer prefixes than /24). Today, the worries are most likely not that much CPU and memory problems of the routers any more, but convergence and stability of BGP tables. Craig Labovitz, Abha Ahuja, et al. show results from their work which are not exactly reassuring... Anybody may improve the situation e.g. by proper filtering (very efficient as proven e.g. by Randy Bush), or correct route flap damping (yes, RIPE-210 needs a brush up badly - it is on our action list). As important as this is: it only helps on symptoms generated by others on the Internet: too many unnecessary routes. I am convinced that it is ever more important today to have a close look at the status of the Internet routing table, and where it may be improved - and your CIDR report is one keystone in it. Thanks a lot for generating these reports during the past years, and please continue to generate them. A review of the prerequisites as you outlined in the first part of your mail does not change anything in the basic statement of the report. Thanks Joachim (chairman RIPE Routing WG) --- JS395-RIPE -- standard disclaimer ---

1 0

The Cidr Report
by Tony Bates 12 Feb '01

12 Feb '01

This is an auto-generated mail on Sun Feb 11 20:37:22 PST 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 11Feb01 0) General Status Table History ------------- Date Prefixes 040201 96815 050201 96681 060201 96726 070201 96978 080201 97041 090201 97137 100201 96880 110201 96509 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 *** Bogus 103.22.7.0/24 from AS9768 AS Summary ---------- Number of ASes in routing system: 9849 Number of ASes announcing only one prefix: 5760 (3266 cidr, 2494 classful) Largest number of cidr routes: 957 announced by AS701 Largest number of classful routes: 1642 announced by AS701 1) Gains by aggregating at the origin AS level --- 11Feb01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1623 1207 416 25.6% Telstra Pty Ltd AS701 1642 1451 191 11.6% UUNET Technologies, Inc. AS271 280 132 148 52.9% University of British Columbia AS7545 196 71 125 63.8% ASNBLK-APNIC-AS-2-BLOCK AS9269 162 46 116 71.6% ASNBLK-APNIC-AS-3-BLOCK AS6429 221 108 113 51.1% RdC Internet AS6595 163 62 101 62.0% DoD Education Activity Network As AS8013 434 336 98 22.6% PSINet Ltd. Canada AS13999 107 10 97 90.7% Mega Cable S.A. de C.V. AS4293 374 281 93 24.9% Cable & Wireless USA AS7496 104 23 81 77.9% ASNBLK-APNIC-AS-2-BLOCK AS4151 250 169 81 32.4% USDA AS705 312 234 78 25.0% UUNET Technologies, Inc. AS4755 209 137 72 34.4% Videsh Sanchar Nigam Ltd. Autonom AS1942 137 65 72 52.6% FR-CICG-GRENOBLE AS7018 615 544 71 11.5% AT&T AS7046 325 255 70 21.5% UUNET Technologies, Inc. AS577 236 167 69 29.2% Bell Advanced Communications Inc. AS174 499 431 68 13.6% PSINet Inc. AS1727 162 94 68 42.0% Commander Naval Surface force US AS9498 88 21 67 76.1% BHARTI BT INTERNET LTD. AS724 219 152 67 30.6% DLA Systems Automation Center AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS3464 153 92 61 39.9% Alabama SuperComputer Network AS7657 185 125 60 32.4% ASNBLK-APNIC-AS-2-BLOCK AS226 155 95 60 38.7% Los Nettos AS3749 115 57 58 50.4% Tennessee Board of Regents AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. AS376 131 75 56 42.7% Reseau Interordinateurs Scientiqu For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 1

The Cidr Report
by Tony Bates 09 Feb '01

09 Feb '01

This is an auto-generated mail on Fri Feb 9 12:00:00 PST 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 09Feb01 0) General Status Table History ------------- Date Prefixes 020201 96787 030201 96701 040201 96815 050201 96681 060201 96726 070201 96978 080201 97041 090201 97137 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 *** Bogus 103.22.7.0/24 from AS9768 AS Summary ---------- Number of ASes in routing system: 9841 Number of ASes announcing only one prefix: 5753 (3257 cidr, 2496 classful) Largest number of cidr routes: 954 announced by AS701 Largest number of classful routes: 1649 announced by AS701 1) Gains by aggregating at the origin AS level --- 09Feb01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0