- routing-wg - mailman.ripe.net

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

The Cidr Report
by Tony Bates 15 Jan '99

15 Jan '99

This is an auto-generated mail on Fri Jan 15 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 15Jan99 0) General Status Table History ------------- Date Prefixes 080199 54976 090199 54679 100199 54744 110199 54918 120199 54860 130199 54884 140199 55099 150199 55155 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: 4408 Number of ASes announcing only one prefix: 2168 (1156 cidr, 1012 classful) Largest number of cidr routes: 355 announced by AS3561 Largest number of classful routes: 1013 announced by AS701 1) Gains by aggregating at the origin AS level --- 15Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 389 144 245 63.0% UNKNOWN AS701 1013 860 153 15.1% UNKNOWN AS2493 319 173 146 45.8% UNKNOWN AS174 650 536 114 17.5% UNKNOWN AS5668 129 35 94 72.9% UNKNOWN AS3749 157 65 92 58.6% UNKNOWN AS4200 178 91 87 48.9% UNKNOWN AS1267 111 30 81 73.0% UNKNOWN AS4755 147 74 73 49.7% UNKNOWN AS4293 208 137 71 34.1% UNKNOWN AS549 218 152 66 30.3% UNKNOWN AS4740 388 326 62 16.0% UNKNOWN AS8517 134 75 59 44.0% UNKNOWN AS1221 395 336 59 14.9% UNKNOWN AS7657 142 87 55 38.7% UNKNOWN AS7545 111 58 53 47.7% UNKNOWN AS72 89 37 52 58.4% UNKNOWN AS3493 252 200 52 20.6% UNKNOWN AS7046 238 187 51 21.4% UNKNOWN AS1239 531 484 47 8.9% UNKNOWN AS10928 96 49 47 49.0% UNKNOWN AS7496 74 28 46 62.2% UNKNOWN AS577 210 164 46 21.9% UNKNOWN AS852 175 132 43 24.6% UNKNOWN AS719 452 409 43 9.5% UNKNOWN AS3221 84 42 42 50.0% UNKNOWN AS803 71 35 36 50.7% UNKNOWN AS6897 62 27 35 56.5% UNKNOWN AS7122 109 75 34 31.2% UNKNOWN AS2764 327 294 33 10.1% 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: EIX WG at RIPE 32
by Christian Panigl, ACOnet/UniVie 14 Jan '99

14 Jan '99

>Date: Thu, 14 Jan 1999 10:14:16 +0000 >From: Fearghas McKay <fm(a)mids.org> >To: <eix-wg(a)ripe.net> > >Request for Presentations at RIPE 32 > >Sorry for the delay in getting this out. > >We have been allocated two slots on the Wednesday morning session at RIPE 32 > >Wednesday 27 > > Room 1 Room 2 Room 3 >9:00 +----------+----------+-----------+ >10:30 | LIR | Routing | EIX | > +----------+----------+-----------+ >11:00 +----------+----------+-----------+ > | LIR | MBone | EIX | >12:30 +----------+----------+-----------+ > >Please can you let me know if you would like to make a presentation, and >provide a short synopsis & equipment requirements. Hi Fearghas, imho it's not a good idea to place Routing/EIX (nor Mbone/EIX) in parallel. Anyway, in principle I'm ready to give a short update for the VIX. Regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

1 0

New RIPE doc + new RIPE Database release
by Joao Luis Silva Damas 14 Jan '99

14 Jan '99

Dear colleagues, we are happy to announce a new RIPE document together with a new maintenance release of the RIPE Database code. New RIPE Document RIPE 189 - RIPE NCC Database documentation update to support RIPE DB ver. 2.2.1 A new RIPE document to supplement RIPE 157 as reference material on the use of the RIPE Database. Describes new or modified functionality since RIPE 157 was issued. Covers DB releases up to the 2.2.1 release (see below). New RIPE Database release Version 2.2.1 is mostly a maintenance release. There are very little user visible changes from version 2.2. For more details please read the release notes available at ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-2.2.1 This version will go into production at whois.ripe.net next Monday. It is available for download now from ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.2.1.tar.gz Best regards, Joao Damas & all the Database Group RIPE NCC

1 0

The Cidr Report
by Tony Bates 08 Jan '99

08 Jan '99

This is an auto-generated mail on Fri Jan 8 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 08Jan99 0) General Status Table History ------------- Date Prefixes 010199 55011 020199 55001 030199 54615 040199 54770 050199 54954 060199 54958 070199 55003 080199 54976 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: 4389 Number of ASes announcing only one prefix: 2167 (1158 cidr, 1009 classful) Largest number of cidr routes: 351 announced by AS3561 Largest number of classful routes: 1010 announced by AS701 1) Gains by aggregating at the origin AS level --- 08Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 391 145 246 62.9% UNKNOWN AS3749 231 71 160 69.3% UNKNOWN AS701 1010 861 149 14.8% UNKNOWN AS2493 326 179 147 45.1% UNKNOWN AS174 669 546 123 18.4% UNKNOWN AS5668 131 35 96 73.3% UNKNOWN AS4200 188 97 91 48.4% UNKNOWN AS4755 150 68 82 54.7% UNKNOWN AS1267 111 30 81 73.0% UNKNOWN AS4293 207 135 72 34.8% UNKNOWN AS549 220 154 66 30.0% UNKNOWN AS4740 393 329 64 16.3% UNKNOWN AS8517 133 74 59 44.4% UNKNOWN AS1221 381 323 58 15.2% UNKNOWN AS7046 251 195 56 22.3% UNKNOWN AS72 89 37 52 58.4% UNKNOWN AS7657 140 89 51 36.4% UNKNOWN AS3493 248 197 51 20.6% UNKNOWN AS7545 114 64 50 43.9% UNKNOWN AS1239 530 483 47 8.9% UNKNOWN AS10928 95 48 47 49.5% UNKNOWN AS7496 74 28 46 62.2% UNKNOWN AS577 205 160 45 22.0% UNKNOWN AS852 175 133 42 24.0% UNKNOWN AS719 452 410 42 9.3% UNKNOWN AS3221 84 42 42 50.0% UNKNOWN AS803 71 35 36 50.7% UNKNOWN AS7122 109 75 34 31.2% UNKNOWN AS1 503 470 33 6.6% UNKNOWN AS6897 46 14 32 69.6% 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 01 Jan '99

01 Jan '99

This is an auto-generated mail on Fri Jan 1 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 01Jan99 0) General Status Table History ------------- Date Prefixes 251298 54839 261298 54849 271298 54731 281298 54848 291298 54977 301298 55085 311298 55006 010199 55011 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: 4378 Number of ASes announcing only one prefix: 2165 (1152 cidr, 1013 classful) Largest number of cidr routes: 351 announced by AS3561 Largest number of classful routes: 1008 announced by AS701 1) Gains by aggregating at the origin AS level --- 01Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 392 146 246 62.8% BCnet Backbone AS3749 228 75 153 67.1% TECNET AS2493 327 180 147 45.0% iSTAR Internet, Inc. AS701 1008 864 144 14.3% Alternet AS1785 541 403 138 25.5% NYSERNet Backbone AS174 671 548 123 18.3% Performance Systems International AS5668 132 36 96 72.7% Century Telephone Inc. AS4200 190 97 93 48.9% AGIS (Apex Global Information Ser AS4755 148 66 82 55.4% Videsh Sanchar Nigam Ltd. India AS1267 107 29 78 72.9% IUNET-AS AS4293 208 136 72 34.6% IMCI AS549 220 154 66 30.0% ONet Backbone AS4740 382 321 61 16.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS8517 129 72 57 44.2% UNKNOWN AS1221 378 321 57 15.1% AARNET-AS AS7046 248 192 56 22.6% UUNET-CUSTOMER AS7545 115 65 50 43.5% TPG Internet Pty Ltd AS1239 533 484 49 9.2% SprintLink Backbone AS10928 93 44 49 52.7% UNKNOWN AS72 88 40 48 54.5% Schlumberger Information Network AS7657 138 93 45 32.6% The Internet Group Limited AS7496 73 28 45 61.6% Power Up AS577 208 163 45 21.6% Bell Canada Backbone AS852 174 132 42 24.1% AGT Advance Communication AS719 450 408 42 9.3% LANLINK-AS AS3221 84 42 42 50.0% RIPE-ASNBLOCK4 AS803 71 35 36 50.7% SaskNet Backbone AS7122 109 75 34 31.2% MTS ADVANCED Network Policy AS6897 46 14 32 69.6% RIPE-ASNBLOCK6 AS6332 100 69 31 31.0% 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