- routing-wg - mailman.ripe.net

The Cidr Report
by Tony Bates 22 Feb '99

22 Feb '99

This is an auto-generated mail on Fri Feb 19 12:00:00 PST 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 19Feb99 0) General Status Table History ------------- Date Prefixes 120299 55713 130299 55907 140299 55818 150299 55997 160299 56035 170299 56178 180299 56403 190299 56528 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: 4569 Number of ASes announcing only one prefix: 2279 (1216 cidr, 1063 classful) Largest number of cidr routes: 353 announced by AS701 Largest number of classful routes: 850 announced by AS701 1) Gains by aggregating at the origin AS level --- 19Feb99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 353 138 215 60.9% BCnet Backbone AS2493 273 155 118 43.2% iSTAR Internet, Inc. AS174 652 536 116 17.8% Performance Systems International AS11305 116 8 108 93.1% UNKNOWN AS3749 149 65 84 56.4% TECNET AS1267 107 29 78 72.9% IUNET-AS AS4293 222 148 74 33.3% IMCI AS4755 151 80 71 47.0% Videsh Sanchar Nigam Ltd. India AS7046 280 215 65 23.2% UUNET-CUSTOMER AS4200 161 98 63 39.1% AGIS (Apex Global Information Ser AS4740 386 325 61 15.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS1239 521 464 57 10.9% SprintLink Backbone AS1221 407 351 56 13.8% AARNET-AS AS7545 110 55 55 50.0% TPG Internet Pty Ltd AS7657 142 90 52 36.6% The Internet Group Limited AS72 89 37 52 58.4% Schlumberger Information Network AS10928 104 53 51 49.0% UNKNOWN AS577 222 172 50 22.5% Bell Canada Backbone AS7496 76 27 49 64.5% Power Up AS719 456 410 46 10.1% LANLINK autonomous system AS852 173 135 38 22.0% AGT Advance Communication AS5674 64 27 37 57.8% PBI-NET-BLK AS803 72 36 36 50.0% SaskNet Backbone AS701 850 814 36 4.2% Alternet AS6897 63 27 36 57.1% Global-One Spain AS7122 112 77 35 31.2% MTS ADVANCED Network Policy AS1785 249 217 32 12.9% NYSERNet Backbone AS6332 97 66 31 32.0% TELNOR AS4307 32 1 31 96.9% SVINET-1 AS2707 63 32 31 49.2% WEC 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 12 Feb '99

12 Feb '99

This is an auto-generated mail on Fri Feb 12 12:00:00 PST 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 12Feb99 0) General Status Table History ------------- Date Prefixes 050299 55641 060299 56070 070299 55738 080299 55776 090299 55763 100299 55822 110299 55912 120299 55713 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: 3332 Number of ASes announcing only one prefix: 1055 (0 cidr, 1055 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 816 announced by AS701 1) Gains by aggregating at the origin AS level --- 12Feb99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 385 139 246 63.9% BCnet Backbone AS2493 275 157 118 42.9% iSTAR Internet, Inc. AS174 656 540 116 17.7% Performance Systems International AS11305 116 8 108 93.1% UNKNOWN AS3749 158 66 92 58.2% TECNET AS4755 156 74 82 52.6% Videsh Sanchar Nigam Ltd. India AS1267 111 30 81 73.0% IUNET-AS AS4293 222 148 74 33.3% IMCI AS7046 274 211 63 23.0% UUNET-CUSTOMER AS4740 387 325 62 16.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS4200 161 99 62 38.5% AGIS (Apex Global Information Ser AS1221 409 347 62 15.2% AARNET-AS AS1239 508 454 54 10.6% SprintLink Backbone AS72 89 37 52 58.4% Schlumberger Information Network AS7545 109 58 51 46.8% TPG Internet Pty Ltd AS10928 100 50 50 50.0% UNKNOWN AS7496 77 28 49 63.6% Power Up AS577 221 172 49 22.2% Bell Canada Backbone AS7657 141 94 47 33.3% The Internet Group Limited AS719 453 408 45 9.9% LANLINK autonomous system AS3221 84 42 42 50.0% EENet Autonomous System AS852 172 136 36 20.9% AGT Advance Communication AS803 72 36 36 50.0% SaskNet Backbone AS6897 63 27 36 57.1% Global-One Spain AS7745 39 4 35 89.7% BIGSKY-AS AS7122 112 77 35 31.2% MTS ADVANCED Network Policy AS701 816 783 33 4.0% Alternet AS1785 250 218 32 12.8% NYSERNet Backbone AS4307 32 1 31 96.9% SVINET-1 AS2707 63 32 31 49.2% WEC 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 05 Feb '99

05 Feb '99

This is an auto-generated mail on Fri Feb 5 12:00:00 PST 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 05Feb99 0) General Status Table History ------------- Date Prefixes 290199 55694 300199 55734 310199 55712 010299 55847 020299 55793 030299 55899 040299 55881 050299 55641 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: 4500 Number of ASes announcing only one prefix: 2232 (1187 cidr, 1045 classful) Largest number of cidr routes: 353 announced by AS701 Largest number of classful routes: 881 announced by AS701 1) Gains by aggregating at the origin AS level --- 05Feb99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 386 140 246 63.7% BCnet Backbone AS2493 315 169 146 46.3% iSTAR Internet, Inc. AS174 656 541 115 17.5% Performance Systems International AS11305 115 13 102 88.7% UNKNOWN AS3749 158 66 92 58.2% TECNET AS1267 111 30 81 73.0% IUNET-AS AS4755 152 72 80 52.6% Videsh Sanchar Nigam Ltd. India AS4293 211 140 71 33.6% IMCI AS7046 273 207 66 24.2% UUNET-CUSTOMER AS4200 161 99 62 38.5% AGIS (Apex Global Information Ser AS4740 389 328 61 15.7% Ozemail Pty Ltd (ASN-OZEMAIL) AS1221 405 345 60 14.8% AARNET-AS AS701 881 825 56 6.4% Alternet AS1239 529 474 55 10.4% SprintLink Backbone AS7657 142 90 52 36.6% The Internet Group Limited AS72 89 37 52 58.4% Schlumberger Information Network AS7545 109 58 51 46.8% TPG Internet Pty Ltd AS10928 100 50 50 50.0% UNKNOWN AS7496 77 28 49 63.6% Power Up AS577 221 172 49 22.2% Bell Canada Backbone AS719 452 407 45 10.0% LANLINK autonomous system AS3221 84 42 42 50.0% EENet Autonomous System AS852 173 135 38 22.0% AGT Advance Communication AS803 72 36 36 50.0% SaskNet Backbone AS6897 64 28 36 56.2% Global-One Spain AS7745 39 4 35 89.7% BIGSKY-AS AS7122 112 77 35 31.2% MTS ADVANCED Network Policy AS6332 98 64 34 34.7% TELNOR AS2764 334 301 33 9.9% connect.com.au pty ltd AS4307 32 1 31 96.9% SVINET-1 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 29 Jan '99

29 Jan '99

This is an auto-generated mail on Fri Jan 29 12:00:00 PST 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 29Jan99 0) General Status Table History ------------- Date Prefixes 220199 55393 230199 55423 240199 55417 250199 55453 260199 55539 270199 55623 280199 55634 290199 55694 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: 4470 Number of ASes announcing only one prefix: 2208 (1180 cidr, 1028 classful) Largest number of cidr routes: 350 announced by AS3561 Largest number of classful routes: 1028 announced by AS701 1) Gains by aggregating at the origin AS level --- 29Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 387 140 247 63.8% BCnet Backbone AS701 1028 870 158 15.4% Alternet AS2493 323 174 149 46.1% iSTAR Internet, Inc. AS174 645 533 112 17.4% Performance Systems International AS11305 116 8 108 93.1% UNKNOWN AS3749 149 67 82 55.0% TECNET AS4755 156 75 81 51.9% Videsh Sanchar Nigam Ltd. India AS1267 111 30 81 73.0% IUNET-AS AS4293 211 140 71 33.6% IMCI AS549 218 152 66 30.3% ONet Backbone AS4200 160 98 62 38.8% AGIS (Apex Global Information Ser AS7046 269 208 61 22.7% UUNET-CUSTOMER AS1221 396 336 60 15.2% AARNET-AS AS4740 378 320 58 15.3% Ozemail Pty Ltd (ASN-OZEMAIL) AS1239 527 473 54 10.2% SprintLink Backbone AS72 89 37 52 58.4% Schlumberger Information Network AS7657 141 90 51 36.2% The Internet Group Limited AS7545 109 58 51 46.8% TPG Internet Pty Ltd AS7496 77 28 49 63.6% Power Up AS577 221 172 49 22.2% Bell Canada Backbone AS10928 99 50 49 49.5% UNKNOWN AS719 452 408 44 9.7% LANLINK autonomous system AS3221 84 42 42 50.0% EENet Autonomous System AS852 173 135 38 22.0% AGT Advance Communication AS3561 723 685 38 5.3% MCI AS803 72 36 36 50.0% SaskNet Backbone AS6897 64 28 36 56.2% Global-One Spain AS7122 110 76 34 30.9% MTS ADVANCED Network Policy AS2764 330 297 33 10.0% connect.com.au pty ltd AS6332 101 70 31 30.7% TELNOR 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 22 Jan '99

22 Jan '99

This is an auto-generated mail on Fri Jan 22 12:00:00 PST 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 22Jan99 0) General Status Table History ------------- Date Prefixes 150199 55155 160199 55240 170199 55247 180199 55241 190199 55868 200199 55938 210199 55534 220199 55393 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: 4442 Number of ASes announcing only one prefix: 2186 (1168 cidr, 1018 classful) Largest number of cidr routes: 355 announced by AS3561 Largest number of classful routes: 1012 announced by AS701 1) Gains by aggregating at the origin AS level --- 22Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 387 143 244 63.0% UNKNOWN AS701 1012 859 153 15.1% UNKNOWN AS2493 319 173 146 45.8% UNKNOWN AS174 655 541 114 17.4% UNKNOWN AS11305 115 7 108 93.9% UNKNOWN AS4200 189 97 92 48.7% UNKNOWN AS3749 158 66 92 58.2% UNKNOWN AS1267 111 30 81 73.0% UNKNOWN AS4755 147 72 75 51.0% UNKNOWN AS4293 208 137 71 34.1% UNKNOWN AS549 218 152 66 30.3% UNKNOWN AS4740 387 325 62 16.0% UNKNOWN AS1221 399 339 60 15.0% UNKNOWN AS7046 253 196 57 22.5% UNKNOWN AS1239 540 486 54 10.0% UNKNOWN AS72 89 37 52 58.4% UNKNOWN AS7657 140 89 51 36.4% UNKNOWN AS7545 110 59 51 46.4% UNKNOWN AS577 221 172 49 22.2% UNKNOWN AS10928 98 49 49 50.0% UNKNOWN AS7496 76 28 48 63.2% UNKNOWN AS852 177 134 43 24.3% UNKNOWN AS719 452 409 43 9.5% UNKNOWN AS3221 84 42 42 50.0% UNKNOWN AS803 72 36 36 50.0% UNKNOWN AS6897 64 28 36 56.2% UNKNOWN AS3561 723 687 36 5.0% UNKNOWN AS7122 110 76 34 30.9% UNKNOWN AS2764 324 291 33 10.2% UNKNOWN AS6332 101 70 31 30.7% 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

draft agenda RIPE 32 routing wg session
by SchmitzJo＠aol.com 22 Jan '99

22 Jan '99

Dear colleagues, please find enclosed the draft agenda for the session of the routing working group at RIPE 32, Amsterdam. The session will be held Wednesday, 27-January, 9:00am As usual comments, additions, welcome! --- 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. Internet Performance and Fault Tolerance (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 --- Regards Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

draft minutes of RIPE 31 routing wg session
by SchmitzJo＠aol.com 21 Jan '99

21 Jan '99

Draft Minutes: Routing Working Group. RIPE 31 --------------------------------------------- Chair: Joachim Schmitz (JS395-RIPE) Minutes: Miriam Kuehne (MK16-RIPE), Julia Edwards (JE316-RIPE) Attenders: 99 A. Preliminaries (Joachim Schmitz) Joachim Schmitz opened the working group session, passed the attenders' list around, and asked for a volunteer scribe. Miriam Kuehne volunteered as scribe. During the session Julia Edwards took over. The working group agreed upon the minutes of the previous meeting, and accepted the draft agenda earlier circulated on the mailing list. Review of actions RIPE 30 o 29.R1 G.Winters, J.Schmitz, RIPE NCC Definition of the IRR and an AUP -in progress- Gerald Winters is giving a presentation in this session on work done so far on this topic o 29.R3: RIPE NCC, JLS Damas Implementation of PGP -to be closed- The action may be considered closed because it will be moved to beta in the next two weeks o 30.R1: RIPE NCC, JLS Damas Implementation of autnum authorization -postponed- Implementation has been postponed because this is one special feature within the more general scope of the RPS Authorization draft o 30.R2: RIPE NCC, J. Schmitz, W. Woeber Organize RPSL tutorials for RIPE 31 -done- The RPSL tutorial has been held. B. Report from the RPSL Tutorial - (Joachim Schmitz) RPSL is the "Routing Policy Specification Language" developed by the IETF RPS Working Group. For those who are not familiar with this topic the following pointers may be of interest: http://www.ietf.org/html.charters/rps-charter.html http://www.isi.edu/ra RPSL is in the stage of deployment phase 2 with the final transition phase from RIPE-181 in sight. Part of the transition is education to make it easier for users to apply RPSL. After some tutorials in the US we had the first RPSL tutorial in Europe just prior to this RIPE meeting. There were approximately 90 participants. The training materials are available electronically at http://www.isi.edu/ra/rps/training Future tutorials will be held at the next RIPE meeting, and plans to offer them as part of the LIR tutorials are currently considered. Joachim Schmitz then thanked the trainers Cengiz Allaetinoglu, David Kessens, and the RIPE NCC, for preparing and performing this tutorial. C. Report from the RIPE NCC (Joao Luis Silva Damas) (http://www.ripe.net/meetings/ripe/ripe-31/pres/ncc-upd/index.html) The report included a general update on NCC activities. In the database software, cross notification was added, making use of the two tags "cross-nfy" and "cross-mnt". The functionality follows the specifications developed by the Routing WG in earlier sessions, both regarding the notification in relation to "autnum" and "route" objects. In addition, PGP authentication will also become available in approximately two weeks for production after this RIPE meeting. This method is supplied in parallel to "none", "e-mail address", "UNIX style password", but offers significantly better security. This method may currently be tested at queries: beta-whois.ripe.net submissions: auto-beta(a)ripe.net in beta status. The implementation follows the Internet draft http://www.ietf.org/internet-drafts/draft-ietf-rps-dbsec-pgp-authent-00.txt developed in the RIPE Database Security Taskforce, and written up by its members Janos Zsako. D. Reports on RPSL Deployment at Registries o RIPE NCC (Joao Luis Silva Damas) (http://www.ripe.net/meetings/ripe/ripe-31/pres/routing-wg- rpsl/index.html) Phase II of the transition has been completed, meaning that a mirror of the production database is installed and running. The mirror according to definition of transition phases is one-way only (RIPE-181 -> RPSL). The phase II database is accessible at - rpslII.ripe.net - auto-rpsl(a)ripe.net Submissions in RIPE 181 format are still possible and will be translated into RPSL. At the same time straight RPSL submissions are possible. Only autnum objects are currently handled in RPSL format. The database is running using ISI's code written by David Kessens. The usage is still low (which is no wonder because the server just became available). In the future, as part of the database reimplementation, the RPSL capable database will support the full set of RPSL features, and also support the RAToolSet. o ISI (David Kessens) There are three phases proposed in the transition from RIPE-181 to RPSL: phase 1: software development done phase 2: tool development, testing, training real time mirror of IRR in RPSL format special RPSL update path for "autnum" objects *status of today* phase 3: switch over incoming RIPE-181 objects are automatically converted to RPSL during 1999 RIPE, ANS, and Merit are currently in phase 2. MCI and CANET are testing RPSL software. Telstra moved to RPSL, and Connect (AU) is already configuring their routers using the alpha RAToolSet for RPSL. A set of others is know to evaluate. Regarding training and education the following tutorials were held so far - Jun 1998, NANOG in Detroit - Sep 1998, Ripe-31 Edinburgh - Mar 1999, APNIC, Apricot (planned) To make use of RPSL, the following software is available: - RAToolSet - RIPE database with RPSL extensions which is compatible to RIPE db 2.1.3. The full RPSL support will move to beta soon. - R181 to RPSL database objects converter The software is available at http://www.isi.edu/ra/rps/transition o RADB (Gerald Winters) Merit offers a public RPSL server rpsl.merit.edu 43 since spring/summer 1998. Usage is on the rise, and comments from users are focusing on two items - why is the system rejecting my AS object - here is a bug I see In Gerald's personal opinion, a large number of RADB users has not yet logged on to the RPSL server because - the old software works and still seems to satisfy their needs - a steady influx of users exist who do not know RPSL - there is a group of "regular" registry users who think the ISP will do it all Therefore, Gerald lists the following suggestions: - continue the current education strategy - include informative footer messages in email transaction responses - I do not see things as bleak - registry admin's will certainly be putting in extra email consulting hours. Usage and involvement by ISPs at this time is not much. Most of it comes from specialists, or users already interested having discovered the potential in RPSL. Usage outside the US, especially in Europe is still low. It is obvious that more training is needed, and work to make it more useful. Users will definitely change their attitude if usability is better. E. Do we need a Routing Registry for IPV6? (Joachim Schmitz) (http://www.ripe.net/meetings/ripe/ripe-31/pres/ to come soon) In the introduction, a short review was given of what currently is part of the IPv4(!) routing registries, and what benefits its users have from it. It is obvious that today no IPv6 registry exists, and the question was raised whether on is needed. Then the current situation regarding IPv6 was described, and the expected development of IPv6 "Inter6net" with its interaction towards IPv4 listed. Looking at the benefits the IPv4(!) IRR offers, it seemed obvious that they are also applicable to an IPv6 routing registry. Consequently, the conclusion was drawn that a need for an IPv6 routing registry exists, which may even add more value by easing the coexistence of IPv4 and IPv6, and may help in transition to IPv6. The time to raise the topic is not too early because during the 1st quarter of 1999 the IPv6 address allocation is likely to begin. The presentation was finished with a call for participation to explore the idea and to define the requirements. F. An AUP for the IRR (Gerald Winters, Pierre Thibaudeau, Joachim Schmitz) The authors feel that a need exists to build an acceptable use policy for the IRR. To start with the question was discussed what an AUP is. It may simply be defined as a document which lists acceptable IRR practices and data, covering topics for the users like - what purposes should the IRR be used for? - what types of data would I register? - Are there important relationships between objects I should be aware of? - Can I find suggestions for maint. my data? The goals of the AUP may be summarized as - add value to the IRR - address the concerns of (the user and db admin) - provide an easy to understand single point of reference - prevent abuse The AUP may then be used - as reference point, especially for new users - by registry admins signing the AUP to declare the data as conformant with it - by users (eg, comparable to the implied consent from the RIPE copyright in the RIPE.db) The AUP is still under development. The work on it is not yet complete, and some of the suggestions require further detailed discussion. The talk was given to make the community aware of the AUP, to solicit feedback, and to ask for support. The IRR AUP will definitely acknowledge other efforts. Others are currently defining relevant policy rules or have already done so - RPS (rps-auth) - RIPE NCC - Merit Some of the ideas to follow overlap or duplicate existing policies. This is not a bad thing, and it shows consistency with out goal to provide a single point of reference. In the following part of the presentation, a starting framework for an AUP was shown: - Contact information should be kept up to date "Contact information is important data which facilitates communication between network parties. Therefore it is encouraged to keep role and person object data up to date as well as all tech-c and admin-c references." - Commercial uses of the IRR "All commercial uses are stricly forbidden. Contact information must not be used for commercial purposes, advertising purposes, or any other purpose beyond the scope of activities relating to the successful operation of the Internet." - Old objects Old objects are a matter of concern. They are not necessarily invalid. However, current does not imply up to date. So aging out objects based on a "changed:" time stamp (even machine generated) is a probably a bad idea. Using global routing data with IRR information is a better solution. A suggestion may build on read time stamps, because it shows that even old data is still accessed, and therefore most likely still valid. Yet, it must be explored whether this approach is practical. Obviously, there is a series of items which needs further discussion. This includes the concept of cross notification and whether it is recommendable or not. The following discussion did not very much enter this area but focused on the abuse of data in the registry, including contact information by spammers, reluctance of service providers to disclose their policies (company policy and possible business impact), and security of data in the database. G. Routing Policy System Security (Cengiz Allaettinoglu) Due to time constraints the presentation on this topic was moved to the Database Working Group session. Joachim Schmitz apologized to the Cengiz, and thanked Wilfried Woeber for accepting the transfer. Y. I/O with other WGs The presentation on whether a Routing Registry for IPv6 is needed was also given as input at the IPv6 Working Group. Z. AOB There were no additional comments or issues. Agenda ------ R I P E 3 1 E D I N B U R G H Routing Working Group Session 23-September-98 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 30 minutes - actions from earlier meetings B. Recent Developments (Joachim Schmitz) - RPSL tutorial C. Report from the RIPE NCC (Joao Luis Silva Damas) D. Report on RPSL Deployment at the Registries - ISI (David Kessens) - RIPE NCC (Joao Luis Silva Damas) - RADB (Gerald Winters) E. Do we need a Routing Registry for IPv6? (Joachim Schmitz) F. An AUP for the IRR (Gerald Winters) G. Routing Policy System Security (David Kessens, Cengiz Allaettinoglu) Y. General Input from Other WGs Z. AOB Summary of Actions ------------------ Action 29.R1: G. Winters, J. Schmitz Definition of the IRR and an AUP Action 31.R1: RIPE NCC, J. Schmitz, D. Kessens Basic Design for an IPv6 IRR Miriam Kuehne, Julia Edwards, Joachim Schmitz, 21 January 1999

1 0

RIPE NCC PGP license distribution
by Joao Luis Silva Damas 20 Jan '99

20 Jan '99

Dear all, as you may be aware from past presentations at RIPE meetings and discussions in the lists, the RIPE Database now supports PGP authentication as a stronger way of protecting your database objects. This use of PGP with the RIPE Database is seen by PGP Inc as a commercial use of their software that therefore requires a commercial license. To enable users to take advantage of the new feature, the RIPE NCC will distribute PGP licenses to Database users according to the policy and procedures described in a new RIPE Document: RIPE 190, available now at the RIPE NCC's website. http://www.ripe.net/docs/ripe-190.html To obtain more information on how to use PGP with the RIPE Database, please refer to the recently release RIPE 189 document, also available at the RIPE NCC's website. http://www.ripe.net/docs/ripe-189.html Please direct any questions/comments to ripe-dbm(a)ripe.net Best regards, Joao Damas Database Group RIPE NCC

1 0

Re: AW: Agenda item suggestions
by SchmitzJo＠aol.com 18 Jan '99

18 Jan '99

Dear colleagues, there were two proposals to discuss multicast issues in the Routing WG. Christian Panigl wrote: > How about integrating the multicast routing issues into the Routing-WG > agenda ? And still, if there's some specific action item on multicast > routing and/or Mbone coordination we could establish a task-force within > the Routing-WG. And as Tiziana wrote, multicast routing should become a > natural service in the european backbones, at least very soon. and then Thomas Telkamp added: > Integrating these routing issues in the Routing-WG might help to keep > focus. I absolutely think the interest of the community in this is still > there. > > Kurt, at least we have an agenda topic for next meeting ;-) > I do not have any objections to discuss multicast routing in the Routing-WG. As far as I see from current planning (not yet on RIPE web site) the MBone session comes after the Routing WG session. So we will not have a clash if we share the topic. However, I would like to suggest that in order to properly deal with the topic that we take this as input to the Routing WG. I would then require a short presentation from you - if someone is interested to give a sketch of the ideas (no solutions yet; they still need to be developed, obviously ;-) I greatly appreciate it. Please write back to me for proposals. Thanks a lot Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

Re: AW: Agenda item suggestions
by Christian Panigl, ACOnet/UniVie 16 Jan '99

16 Jan '99

>Date: Fri, 15 Jan 1999 13:14:09 +0100 (MET) >From: heiligers(a)noc.dfn.de > >i think there is the need for european multicast coordination. For >example questions regarding pruning or administrativly scoped >boundaries, .... >I would suggest to keep at least the mailing list as a european forum >for discussing problems regarding multicast deployment and operation. How about integrating the multicast routing issues into the Routing-WG agenda ? And still, if there's some specific action item on multicast routing and/or Mbone coordination we could establish a task-force within the Routing-WG. And as Tiziana wrote, multicast routing should become a natural service in the european backbones, at least very soon. See you CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

2 1