- routing-wg - mailman.ripe.net

The Cidr Report
by Tony Bates 14 May '99

14 May '99

This is an auto-generated mail on Fri May 14 12:00:01 PDT 1999 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 14May99 0) General Status Table History ------------- Date Prefixes 070599 58948 080599 58752 090599 58864 100599 58995 110599 58977 120599 59116 130599 58987 140599 59083 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 221.43.160.0/19 from AS12323 AS Summary ---------- Number of ASes in routing system: 4952 Number of ASes announcing only one prefix: 2526 (1378 cidr, 1148 classful) Largest number of cidr routes: 397 announced by AS701 Largest number of classful routes: 805 announced by AS701 1) Gains by aggregating at the origin AS level --- 14May99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 355 144 211 59.4% BCnet Backbone AS4293 282 176 106 37.6% IMCI AS174 565 474 91 16.1% Performance Systems International AS2493 210 125 85 40.5% iSTAR Internet, Inc. AS4755 174 90 84 48.3% Videsh Sanchar Nigam Ltd. India AS577 254 175 79 31.1% Bell Canada Backbone AS4200 175 99 76 43.4% AGIS (Apex Global Information Ser AS3749 137 61 76 55.5% TECNET AS1267 94 24 70 74.5% IUNET-AS AS7496 99 30 69 69.7% Power Up AS7545 111 47 64 57.7% TPG Internet Pty Ltd AS1785 384 321 63 16.4% NYSERNet Backbone AS9269 69 8 61 88.4% Hong Kong CTI AS1221 457 397 60 13.1% TELSTRA-AS AS7122 140 81 59 42.1% MTS ADVANCED Network Policy AS4740 333 276 57 17.1% Ozemail Pty Ltd (ASN-OZEMAIL) AS10928 110 53 57 51.8% UNKNOWN AS72 94 39 55 58.5% Schlumberger Information Network AS7657 164 110 54 32.9% The Internet Group Limited AS719 473 419 54 11.4% LANLINK autonomous system AS1239 519 466 53 10.2% SprintLink Backbone AS7046 252 206 46 18.3% UUNET-CUSTOMER AS3737 111 73 38 34.2% PenTeleData Inc. (ASN-PTD) AS803 72 36 36 50.0% SaskNet Backbone AS1 499 465 34 6.8% BBNPLANET AS6172 155 124 31 20.0% HOME-NET-1 AS4307 32 1 31 96.9% SVINET-1 AS3549 133 102 31 23.3% Frontier GlobalCenter AS2907 208 177 31 14.9% SINET AS11515 32 1 31 96.9% UNKNOWN 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

The Cidr Report
by Tony Bates 07 May '99

07 May '99

This is an auto-generated mail on Fri May 7 12:00:00 PDT 1999 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 07May99 0) General Status Table History ------------- Date Prefixes 300499 58568 010599 58452 020599 58475 030599 58545 040599 58645 050599 58720 060599 58883 070599 58948 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 71.0.2.0/24 from AS1239 *** Bogus 221.43.160.0/19 from AS12323 AS Summary ---------- Number of ASes in routing system: 4916 Number of ASes announcing only one prefix: 2500 (1358 cidr, 1142 classful) Largest number of cidr routes: 377 announced by AS701 Largest number of classful routes: 799 announced by AS701 1) Gains by aggregating at the origin AS level --- 07May99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 360 148 212 58.9% BCnet Backbone AS577 299 186 113 37.8% Bell Canada Backbone AS4293 289 182 107 37.0% IMCI AS174 598 497 101 16.9% Performance Systems International AS4755 176 85 91 51.7% Videsh Sanchar Nigam Ltd. India AS2493 211 126 85 40.3% iSTAR Internet, Inc. AS4200 177 101 76 42.9% AGIS (Apex Global Information Ser AS3749 136 63 73 53.7% TECNET AS1267 94 24 70 74.5% IUNET-AS AS7496 99 30 69 69.7% Power Up AS7545 111 47 64 57.7% TPG Internet Pty Ltd AS7046 270 206 64 23.7% UUNET-CUSTOMER AS1239 548 484 64 11.7% SprintLink Backbone AS1785 384 321 63 16.4% NYSERNet Backbone AS9269 69 8 61 88.4% Hong Kong CTI AS7122 140 81 59 42.1% MTS ADVANCED Network Policy AS1221 454 395 59 13.0% TELSTRA-AS AS4513 97 40 57 58.8% PFM Communications, Inc. AS10928 111 54 57 51.4% UNKNOWN AS719 475 421 54 11.4% LANLINK autonomous system AS4740 334 280 54 16.2% Ozemail Pty Ltd (ASN-OZEMAIL) AS7657 163 111 52 31.9% The Internet Group Limited AS72 93 41 52 55.9% Schlumberger Information Network AS803 78 34 44 56.4% SaskNet Backbone AS5674 80 36 44 55.0% PBI-NET-BLK AS3737 111 73 38 34.2% PenTeleData Inc. (ASN-PTD) AS1 499 465 34 6.8% BBNPLANET AS6172 154 123 31 20.1% HOME-NET-1 AS4307 32 1 31 96.9% SVINET-1 AS2907 210 179 31 14.8% SINET 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

*2nd* draft of routing wg agenda RIPE 33
by SchmitzJo＠aol.com 03 May '99

03 May '99

Dear colleagues, please find enclosed the 2nd draft of the agenda for the session of the routing working group at RIPE 33, Vienna. The session will be held Wednesday, 5-May, 11:00am As usual comments, additions, welcome! --- R I P E 3 3 V I E N N A Routing Working Group Session 5-May-1999 2nd Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 32 minutes - actions from earlier meetings B. Status Report: RPS Standards & Drafts (Cengiz Allaettinoglu) C. Report from the RIPE NCC (JLS Damas) D. RPSL transition: Issues and progress (JLS Damas) E. Reports from other registries - RADB (Abha Ahuja) - Overview (David Kessens) F. Why the Internet does not scale (Abha Ahuja) G. MBone Developments (Kurt Kayser) - to be confirmed - Y. General I/O with Other WGs Z. AOB --- Regards Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

The Cidr Report
by Tony Bates 30 Apr '99

30 Apr '99

This is an auto-generated mail on Fri Apr 30 12:00:00 PDT 1999 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 30Apr99 0) General Status Table History ------------- Date Prefixes 230499 58766 240499 58380 250499 58344 260499 58454 270499 58458 280499 58561 290499 58602 300499 58568 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 71.0.2.0/24 from AS1239 *** Bogus 221.43.160.0/19 from AS12323 AS Summary ---------- Number of ASes in routing system: 4878 Number of ASes announcing only one prefix: 2461 (1329 cidr, 1132 classful) Largest number of cidr routes: 376 announced by AS701 Largest number of classful routes: 799 announced by AS701 1) Gains by aggregating at the origin AS level --- 30Apr99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 360 148 212 58.9% BCnet Backbone AS577 292 182 110 37.7% Bell Canada Backbone AS4293 289 182 107 37.0% IMCI AS174 603 502 101 16.7% Performance Systems International AS4755 175 87 88 50.3% Videsh Sanchar Nigam Ltd. India AS2493 211 126 85 40.3% iSTAR Internet, Inc. AS4200 167 94 73 43.7% AGIS (Apex Global Information Ser AS3749 136 63 73 53.7% TECNET AS7657 193 121 72 37.3% The Internet Group Limited AS1267 94 24 70 74.5% IUNET-AS AS7496 98 29 69 70.4% Power Up AS1239 550 485 65 11.8% SprintLink Backbone AS7545 111 47 64 57.7% TPG Internet Pty Ltd AS1785 384 321 63 16.4% NYSERNet Backbone AS7046 264 202 62 23.5% UUNET-CUSTOMER AS10928 112 50 62 55.4% UNKNOWN AS1221 451 392 59 13.1% AARNET-AS AS4740 329 272 57 17.3% Ozemail Pty Ltd (ASN-OZEMAIL) AS9269 66 10 56 84.8% Hong Kong CTI AS3493 238 184 54 22.7% INTERLINK AS719 474 421 53 11.2% LANLINK autonomous system AS72 93 41 52 55.9% Schlumberger Information Network AS803 79 35 44 55.7% SaskNet Backbone AS5674 80 36 44 55.0% PBI-NET-BLK AS3737 109 71 38 34.9% PenTeleData Inc. (ASN-PTD) AS1 499 465 34 6.8% BBNPLANET AS7122 110 78 32 29.1% MTS ADVANCED Network Policy AS4307 32 1 31 96.9% SVINET-1 AS2907 209 178 31 14.8% SINET AS11515 32 1 31 96.9% UNKNOWN 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

1st draft of routing wg agenda, RIPE 33
by SchmitzJo＠aol.com 26 Apr '99

26 Apr '99

Dear colleagues, please find enclosed the first draft of the agenda for the session of the routing working group at RIPE 33, Vienna. The session will be held Wednesday, 5-May, 11:00am As usual comments, additions, welcome! --- R I P E 3 3 V I E N N A Routing Working Group Session 5-May-1999 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 32 minutes - actions from earlier meetings B. Status Report: RPS Standards & Drafts (C.Allaettinoglu) C. Report from the RIPE NCC (JLS Damas) D. RPSL transition: Issues and progress (JLS Damas) E. (presentation from Merit, title to be announced, Abha Ahuja) Y. General I/O with Other WGs Z. AOB --- Regards Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

The Cidr Report
by Tony Bates 23 Apr '99

23 Apr '99

This is an auto-generated mail on Fri Apr 23 12:00:00 PDT 1999 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 23Apr99 0) General Status Table History ------------- Date Prefixes 160499 58374 170499 58360 180499 58291 190499 58530 200499 58544 210499 58520 220499 58449 230499 58766 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 71.0.2.0/24 from AS1239 *** Bogus 221.43.160.0/19 from AS12323 AS Summary ---------- Number of ASes in routing system: 4930 Number of ASes announcing only one prefix: 2503 (1317 cidr, 1186 classful) Largest number of cidr routes: 375 announced by AS701 Largest number of classful routes: 801 announced by AS701 1) Gains by aggregating at the origin AS level --- 23Apr99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 360 148 212 58.9% BCnet Backbone AS577 291 181 110 37.8% Bell Canada Backbone AS4293 291 184 107 36.8% IMCI AS174 615 509 106 17.2% Performance Systems International AS4755 167 78 89 53.3% Videsh Sanchar Nigam Ltd. India AS2493 216 129 87 40.3% iSTAR Internet, Inc. AS3749 143 63 80 55.9% TECNET AS4200 175 100 75 42.9% AGIS (Apex Global Information Ser AS721 141 68 73 51.8% DLA-ASNBLOCK-AS AS1267 94 24 70 74.5% IUNET-AS AS7657 191 124 67 35.1% The Internet Group Limited AS7496 97 31 66 68.0% Power Up AS7545 110 46 64 58.2% TPG Internet Pty Ltd AS7046 261 198 63 24.1% UUNET-CUSTOMER AS1785 385 322 63 16.4% NYSERNet Backbone AS1221 449 387 62 13.8% AARNET-AS AS1239 527 467 60 11.4% SprintLink Backbone AS4740 331 274 57 17.2% Ozemail Pty Ltd (ASN-OZEMAIL) AS10928 110 53 57 51.8% UNKNOWN AS3493 238 184 54 22.7% INTERLINK AS719 470 417 53 11.3% LANLINK autonomous system AS72 92 40 52 56.5% Schlumberger Information Network AS803 79 35 44 55.7% SaskNet Backbone AS5674 80 36 44 55.0% PBI-NET-BLK AS3737 110 70 40 36.4% PenTeleData Inc. (ASN-PTD) AS1 508 473 35 6.9% BBNPLANET AS7122 109 77 32 29.4% MTS ADVANCED Network Policy AS9269 52 21 31 59.6% Hong Kong CTI AS4307 32 1 31 96.9% SVINET-1 AS11515 32 1 31 96.9% UNKNOWN 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

RIPE 32 routing wg draft minutes
by SchmitzJo＠aol.com 20 Apr '99

20 Apr '99

Dear colleagues, please find below the draft minutes of the routing wg session during RIPE 32. Comments, additions, corrections welcome. Thanks to Roman Karpiuk who wrote them up. Regards Joachim --- JS395-RIPE -- standard disclaimer --- Draft Minutes of Routing WG session - RIPE 32, 27 January 1999 -------------------------------------------------------------- Chair: Joachim Schmitz (JS395-RIPE) Scribe: Roman Karpiuk (RK-RIPE) Attenders: 74 A. Preliminaries (Joachim Schmitz) Joachim welcomed participants and mentioned 'slow start' feature (session started at 9.15) because of ongoing registration of RIPE meeting visitors. Joachim then passed the participants' list around, and asked for a volunteer scribe. Roman Karpiuk volunteered. The working group agreed upon the minutes of the previous meeting, and accepted the agenda circulated earlier on the mailing list. Review of previous actions: o 29.R1 G.Winters, J.Schmitz, RIPE NCC Definition of the IRR and an AUP -in progress- There was a presentation on this topic during RIPE31. Work is ongoing. Action still open. o 29.R3 RIPE NCC, JLS.Damas Implementation of PGP in the RR -done- Report will be given in the Database Working Group session. Documentation is already available in the RIPE-189 document (http://www.ripe.net/docs/ripe-189.html) o 31.R1 RIPE NCC, D.Kessens, J.Schmitz Basic Design for an IPv6 IRR -open- Work ongoing. B. Recent Developments (Joachim Schmitz) * RPSL Tutorial Report (Joachim) As agreed during earlier RIPE meetings tutorials on RPSL will be held. The first one in Europe was done prior to the last RIPE meeting. We now had a second one just before this RIPE meeting on 26-Jan-1999. It was the first one organized and given by the RIPE NCC alone. There were about 60 participants. The original presentations are available at the ISI web site http://www.isi.edu/ra/rps/training. The training effort will be continued. We will have yet another tutorial at RIPE33. For the future, as discussed before, the tutorials will become part of the present LIR courses. The corresponding course with the administrative boundaries is currently developed at the NCC. Plans currently include a separate tutorial day before or after the LIR training, This offers sufficient flexibility for participants to either just take one of the courses (LIR or RPSL, only), or to visit both. Joachim then thanked the trainers and the RIPE NCC for organizing and holding the tutorial. * Report from 43rd IETF Meeting in Orlando (Joachim) While as usual a multitude of topics was discussed Joachim focused on two topics directly related to the work of the Routing Working Group - RPS The RPS Working Group is progressing. There has been some additional work on the rps-auth and rps-dist drafts. A major concern was how the working group itself should proceed because their milestones set originally were achieved. Nonetheless, several new related topics had been discussed (especially the authorization and distribution issues). Accordingly in compliance with the IETF regulations for working groups a set of new milestones has been set up, and the charter is currently reworked. - IPv6 development Besides the usual development of IPv6 related Internet drafts and standards most notable probably at this time is draft-ietf-ipngwg-iana-tla-00.txt. This draft describes a proposal of how to distribute TLA space to the address registries. According to the proposal the sub-TLA space 0x00c0-0x00ff is suggested to be given to RIPE. With address space now beginning to be distributed, ESnet started an initiative called 6REN which is a native IPv6 Research and Educational network meant for production. Info is available from their web site at http://6ren.net/. David Kessens mentioned that a presentation on 6REN will be given at the IPv6 Working Group session. C. Report on RPSL Deployment at the Registries * General Overview (David Kessens) David outlined the RPSL transition process consisting of three phases. Phase 1 of the basic software development has been done. Phase 2 consisting of additional code developemtn, testing, education, real time mirrors, and implementation of an RPSL update path for autnum objects are more or less done. Phase 3 as final switch over is yet to come. Looking at Phase 2 in more detail David listed the resources available at ISI (http://www.isi.edu/ra/rps/transition) namely the RAToolSet, the running RIPE database with RPSL extensions, and the converter software for RIPE-181 objects to RPSL objects. David then acknowledged the IRRd development at Merit, which takes advantage of the new RPSL features. On the educational side they held tutorials June 98 NANOG Detroit Sep 98 RIPE31 Edinburgh Jan 99 RIPE32 Amsterdam (RIPE NCC) Mar 99 APNIC/APRICOT Singapore (planned) May 99 RIPE33 Vienna (RIPE NCC, planned) If there are suggestions for additional tutorials, David welcomes them. David's conclusion then was that the world is ready for Phase 3 where any incoming RIPE-181 object is automatically translated into RPSL, and RPSL is used throughout. An RPSL server is available, mirror servers are running at participants' sites, and potential participants are waiting (CONNECT in Australia already configures their routers with the RPSL capable RAToolSet). Accordingly, at the IETF meeting in Orlando, a session was held to discuss transition. Participants came from ANS, C&W (former MCI), RA (Merit), Telstra, Qwest, ARIN (they will start a routing registry of their own during February), APNIC, RIPE NCC, Connect. Among those it was agreed that all of them make their RPSL data files available for mutual download at 15-Feb-99 to present all registered routing data easily. The next meeting is planned for the IETF meeting at Minneapolis in March, where a final confirmation is meant to be achieved whether all parties are ready for RPSL and when they will switch over. * RIPE NCC (Joao Luis Silva Damas) RIPE NCC is in Phase 2 of the transition process, having a mirror server running for 10 months already, and having started to give tutorials. RPSL data files available on the ftp site: ftp://ftp.ripe.net/ripe/dbase/rpsl containing autnums, routes, communitiesa (route-sets) and as-macros (as-sets). Input is needed from potential users on how they use it and where they see problems. The RIPE NCC will not support RPSL fully until the new database code (of reimplementation) is in production. This extends the period for people who need to switch over, probably adapt scripts, etc until Dec-99, meaning that the RIPE NCC will maintain backward compatibility. After the transition only the RPSL files will be published, and the RIPE-181 files will no longer be available. This may occur already during 1999 for other registries (possibly C&W, ANS) which perform an earlier switch over. There was some discussion on this topic, especially when the new syntax will become available to RIPE database users. Joao explained that the production database will only accept RIPE-181 format, while the mirror has the RPSL translated format. A complete write is only possible to the production database using RIPE-181 format. Nonetheless, there is an update path for *autnum* objects in the RPSL mirror database (but not for other objects). Any update to the RIPE-181 database will be reflected in the RPSL database - except in the case that a mirrored autnum object has been updated in the RPSL mirror using RPSL syntax. In this specific case, the RIPE-181 autnum object will not overwrite the RPSL autnum object. However, the RPSL autnum object will not be reflected in the RIPE-181 production database because RPSL is a superset of RIPE-181. The RPSL mirror is not considered production by the RIPE NCC. This raised the question of how the transition to RPSL should occur. i.e. whether the old RIPE-181 objects or the new RPSL autnum objects should be used in the new upcoming RPSL database. Joao suggested to decide on this during the next RIPE meeting. Action (RIPE NCC, JLS Damas): Write-up draft document about transition issues of RIPE-181 to RPSL Joachim added that reimplementation of the RIPE database software has higher priority than moving to RPSL. RPSL will be natively supported in the new software meaning that RPSL transition and software reimplementation are coupled together. D. Report from the RIPE NCC (Joao Luis Silva Damas) This agenda point was skipped. The report will be given on the Database WG session. Slides are available at http://www.ripe.net/meetings/ripe/ripe-32/pres/db-ncc-report/index.html and http://www.ripe.net/meetings/ripe/ripe-32/pres/db-rpsl-upd/index.html E. Observations in Internet Routing (Abha Ahuja, Craig Labovitz) Abha gave the presentation about stability and measurements of Internet routing (IPMA project at Merit) as followup on Craig's earlier reports on Internet stability. Merit has established a measurement infrastructure with probe machines at many Internet Exchange points in US (Mae-East/West, Paix, PacBell, AADs). They collect default-free part of global routing table at the University of Michigan via EBGP multihop configurations. They have gathered data for the last 4 years. The tool used is called Route Tracker. Based on peering with ISP routers it logs all routing information over time to disk and generates statistics. Then, Abha gave a review of previously observed pathological routing observations. Actually, most route updates had been pathological (millions per day) with a disproportionate impact caused by small ISPs. These updates consisted of duplicate announcements, duplicate withdrawals, or private networks announcements. Most of it was caused by router software bugs (errors in implementing the BGP algorithm), and BGP misconfigurations. Many of those pathological updates have been fixed over time. As of August 1998 number of announcements exceeded number of withdrawals. Improvements are also visible in the frequency analysis of updates, where the 30 seconds component has been decreasing a lot. As a new topic, Merit has been looking in more detail at Internet failures. They analyzed longlived default free BGP announcements for multiple large providers and found that the Internet is significantly less available than telephony: 60% of the routes show availability below 99% where availability is defined as percentage of the time a route was present in the routing table, compared to the elapsed time. This covers all NLRIs meaning real reachability. At the same time the MTTR (mean time to repair) analysis showed that 80% of the problems were solved in less than 2 hours. Discussing failures with the participating ISPs showed that the three main reasons for network failures were - Maintenance related - Power outages - Fiber cuts Interesting enough, most of them were not related to router problems. As next steps in their analysis programs, Merit is now - looking for more peers in the US and in Europe - trying to find supporters for hosting route view machines in Europe Merit has FreeBSD desktop boxes to give away for this purpose. More information is available from ipma-support(a)merit.edu. F. Reality Checking of the RIPE Routing Registry (Joachim Schmitz) (http://www.ripe.net/meetings/ripe/ripe-32/pres/rcirr.html) As seen in the previous presentation there are ways of measuring the quality of Internet Routing. Do we have means to measure the quality of data in the Routing Registry, too? The RIPE database is used for: - documentation (IP addres allocation) - reference (contact information) - configuration (routes and AS filter information) Data submission is either mandatory or optional depending on data type. A database only makes sense when data is correct and up to date. Data stored in the RIPE database may be distinguished in - allocation data - routing data - both Joachim then looked at the various objects in the database and found that for controlled resources the data quality is good, namely for IP address allocation (inetnum), AS number allocation, and most likely the corresponding maintainers which are mandatory at RIPE for inetnum and autnum objects. Christian Panigl pointed out that inetnum objects do not only contain allocation data but also assignments which are probably not that well documented. Joachim also showed that domain objects registered are at best incomplete because RIPE is no domain registry. In addition, person and role objects are definitely an uncertain area where accuracy is impossible to fathom. Looking at routing policies and routes, it is found that there is no obligation to register them in the registry (except since some time a basic routing policy is requested intially from the RIPE NCC when distributing AS numbers). It is at least questionable whether these objects are uptodate. The question is whether we as the Internet community care at all. Actually, disregarding internal networks and private peering, routing information on the Internet is essentially public (traceroute, looking glass...). It must be public because otherwise networks would not be reachable. Ruediger Volk had objections and felt that the full policy of an ISP is not public. Nobody could figure out his full configurations from traceroute and such tools. As an example many networks are multihomed and still competing routes are not announced. Much of the routing information cannot be derived from just observing the life system. Joachim agreed to a certain point, e.g. for private agreements and peering among neighboring ISPs, or from the fact that certain BGP parameters do not propagate beyond the nearest peering neighbor. Nonetheless, at least the basics of routing policies must be publicly known because otherwise networks would not be reachable on the Internet. Publishing the routing policy and routes helps debugging. If things go wrong the IRR is a perfect reference as long as data are properly registered. Then, it may also be used for building configurations. Even though in general nobody is obliged to register routes and policies, many big providers demand that their peers properly register. This information is then actually used to install filters at least on the boundary routers. Obviously, there is a benefit in checking the accuracy and completeness of routing information in the Routing Registry. The best way to check probably is - read internet routing table - look at announcements/accept lists from registered policies - compare both Items which may be checked then are - routes * aggregation * origin * flap statistics (not in the RR) - autnums * AS paths * and more (BGP announcements, communities) To this end already a number of tools exists: - CIDR report on aggregation. There might be legitimate reasons why under certain circumstances routes are not fully aggregated (even though this is discouraged) - RAToolSet (roe, aoe, RtConfig) - PAIR: http://www.rsng.net/pair - Policy Analysis of Internet Routing. This requires RSNG (Route Servers Next Generation) though which is not deployed in Europe yet There are probably even more tools which might be used. With tools available, the question arises who should check. In principle, everybody could do it on its own. This should definitely be encouraged but there should also be more. Joachim actually proposes these checks as a service by the RIPE NCC because it - already maintains European Routing Registry - already provides a number of services - is an independent organisation Accordingly, a project is proposed with the following steps: - investigate about * route server vs. plain router * check need for own developments * access to routing information * scope of reality checks with respect to policies - develop parts as needed - install system and programs - offer as a service * on demand * on a regular basis as periodical report There was quite some input from the audience on this presentation. Ruediger Volk asked what the idea behind this proposal was: to help people who care, or to put pressure on those who do not care to fix their data or configuration? Joachim made clear that he does not want to force people into something they do not want, but due to the benefits the Routing Registry offers to the community it is best for all to properly register the public parts of their routing policy. Actually, big ISPs (especially those running backbones) still demand from their peers that the routing policies are registered. These ISPs use the RR to configure their routers. Anybody not registering will therefore not be reachable or supported by those big providers. There was some discussion on whether this is still valid, but general feeling and information confirmed this practice. Jake Khuon mentioned statistics from Merit show that approximately 50% of the routes in the RR were actually announced, and about 80% of those were uptodate. Francis Dupont indicated that with IPv6 the situation will be different because IPv6 has an internal topology built in. While this is definitely true, the discussion was on the IPv4 RR only. There was consensus on the usefulness of the project proposal. Joao Damas told that the current RIPE NCC Activity Plan for 1999 includes a Routing Information Project and the Database Consistency Project besides others. The new project should take this into account. Action (Joachim Schmitz): Write up the project proposal on reality checking of the RR, and submit it to the RIPE NCC. Y. General I/O with Other WG After the coffee break a final topic was discussed which had just emerged before this RIPE meeting. * Cooperation between Routing WG and MBone WG (Kurt Kayser) Kurt Kayser as chairman of the MBone Working Group reported about the latest (in)activities of the WG. No topics for discussions for the WG session at RIPE32 were proposed on the mailing list. Reasons for this may be - there are no MBONE related problems - people don't use MBONE - they don't care Therefore, the proposal was put forward to merge the MBone WG into the Routing WG. Joachim Schmitz as chairman of the Routing WG does not have objections. There was some discussion and input from the members of the MBone WG. Joachim and others pointed out that multicast routing at this time is pretty stable, and as a routing topic it should be possible to discuss issues around it for ISPs and the LIR area in Europe. Ruediger Volk thinks that it looks a bit suspicious that there is no feedback during the migration period from old technologies to BGP based multicast routing. It seems as if there is no demand from the RIPE community. Ruediger then asked who is really using MBone seriously for production or commercial use. There were a few like Brent Frere who said that 90% of their business runs on IP multicast. However, most of the activity seems to be still in the research network domain. Further questions revealed that half of the particpants in this session are using multicast routing in their network (enabled on their routers), while only a minority is running dvrmp or mrouted. Since there were no requests to keep the MBone WG separate, it was merged into the Routing WG. Wolfgang Nair made clear that he understands it as a merger, and if there is enough demand, it will be split again. There was general consensus on this approach. Bernard Tuy said that there is not much traffic on the MBone mailing list. There are other related mailing lists, e.g. at ISI. Nonetheless, general feeling was that the MBone mailing list is still useful, and it will be kept. In addition, the web page with the contact list will still be maintained by Kurt Kayser, who will also give an overview of MBone activities in the Routing WG from now on. There was no other input from other WGs, or output to them. Z. AOB The solutions of the excercises from the RPSL tutorial were circulated. Since there were no additional comments or issues, Joachim closed the WG session. Agenda ------ R I P E 3 2 A M S T E R D A M Routing Working Group Session 27-January-1999 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 31 minutes - actions from earlier meetings B. Recent Developments (Joachim Schmitz) - RPSL tutorial - IETF C. Report on RPSL Deployment at the Registries - General Overview (David Kessens) - RIPE NCC (Joao Luis Silva Damas) D. Report from the RIPE NCC (Joao Luis Silva Damas) E. Observations in Internet Routing (Abha Ahuja, Craig Labovitz) F. Reality Checking of the RIPE Routing Registry (Joachim Schmitz) Y. General I/O with Other WGs - Cooperation between Routing WG and MBone WG (Kurt Kayser) Z. AOB Summary of open Action Points ----------------------------- 29.R1 G.Winters, J.Schmitz, RIPE NCC Definition of the IRR and an AUP 31.R1 RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR 32.R1 RIPE NCC, JLS.Damas Prepare draft document on RIPE-181 -> RPSL transition issues 32.R2 J.Schmitz Write project definition for Routing Registry reality checking Roman Karpiuk, Joachim Schmitz, 4-Mar-1999 -----

1 0

The Cidr Report
by Tony Bates 16 Apr '99

16 Apr '99

This is an auto-generated mail on Fri Apr 16 12:00:00 PDT 1999 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 16Apr99 0) General Status Table History ------------- Date Prefixes 090499 58050 100499 58045 110499 58080 120499 58147 130499 58117 140499 58177 150499 58448 160499 58374 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3500 Number of ASes announcing only one prefix: 1134 (0 cidr, 1134 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 815 announced by AS701 1) Gains by aggregating at the origin AS level --- 16Apr99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 355 147 208 58.6% BCnet Backbone AS4293 290 183 107 36.9% IMCI AS226 206 100 106 51.5% USC/Information Sciences Institut AS174 586 492 94 16.0% Performance Systems International AS577 270 177 93 34.4% Bell Canada Backbone AS4755 168 78 90 53.6% Videsh Sanchar Nigam Ltd. India AS2493 219 131 88 40.2% iSTAR Internet, Inc. AS1785 457 369 88 19.3% NYSERNet Backbone AS3749 141 63 78 55.3% TECNET AS4200 167 96 71 42.5% AGIS (Apex Global Information Ser AS1267 94 24 70 74.5% IUNET-AS AS7496 96 30 66 68.8% Power Up AS7545 110 46 64 58.2% TPG Internet Pty Ltd AS1221 445 381 64 14.4% AARNET-AS AS7046 258 197 61 23.6% UUNET-CUSTOMER AS4740 339 278 61 18.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS7657 180 121 59 32.8% The Internet Group Limited AS1239 526 467 59 11.2% SprintLink Backbone AS10928 110 52 58 52.7% UNKNOWN AS72 92 40 52 56.5% Schlumberger Information Network AS719 464 412 52 11.2% LANLINK autonomous system AS3493 233 182 51 21.9% INTERLINK AS5674 80 36 44 55.0% PBI-NET-BLK AS3737 110 70 40 36.4% PenTeleData Inc. (ASN-PTD) AS803 74 38 36 48.6% SaskNet Backbone AS7745 39 4 35 89.7% BIGSKY-AS AS1 505 470 35 6.9% BBNPLANET AS7122 111 78 33 29.7% MTS ADVANCED Network Policy AS4307 32 1 31 96.9% SVINET-1 AS11515 32 1 31 96.9% UNKNOWN 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

Re: Objects to deprecate (OSI dom-prefix)
by Wilfried Woeber, UniVie/ACOnet 16 Apr '99

16 Apr '99

Wearing my plain DB user hat, >the RIPE NCC hereby requests from the RIPE community to consider NOT >to support the Domain-prefix object in the new RIPE DB code currently >under development. >This would mean not writing the code to support the object and dump the data >in the transition to the new code (still a few months away). I fully support this proposal. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

1 0

Objects to deprecate (OSI dom-prefix)
by Joao Luis Silva Damas 16 Apr '99

16 Apr '99

Dear all, the RIPE NCC hereby requests from the RIPE community to consider NOT to support the Domain-prefix object in the new RIPE DB code currently under development. This would mean not writing the code to support the object and dump the data in the transition to the new code (still a few months away). This object is intented to store OSI CLNS prefixes and has seen little use. Currently there are 6 objects of this type. The most current update took place in May 1994. The prefixes stored right now are: 39.528f.1100 39.756f.1111 39.756f 39.250f 39.250f.0000.02 39.276f.3100 in case the owners want to inspect them and check their use :-) Best regards, Joao Damas RIPE NCC

2 1