- routing-wg - mailman.ripe.net

draft agenda for the Routing WG session at RIPE 31
by SchmitzJo＠aol.com 16 Sep '98

16 Sep '98

Dear colleagues, please find enclosed the draft agenda for the session of the routing working group at RIPE 31, Edinburgh. The session will be held Wednesday, 23-September, 2:00pm As usual comments, additions, welcome! ---- 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 ---- Regards Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

Re: The Cidr Report
by John M. Brown 13 Sep '98

13 Sep '98

Why should they, there is no reason for them to. Personally I wonder what would happen if we (the rest of us) started filtering on /19's or /20's :) But then you take UUNET (Alternet) and for example 207.170.32.0 /19 is advertised as a /19 AND a stack of /24's all with the same AS path and from what I can tell no special routes, at least not via nitrous.digex.net But what do I know, I am a lonely little guy... :) At 01:19 PM 9/11/98 -0700, Tim Wolfe wrote: >Anyone care to comment on the fact that the top non-compliant companies never really seem >to make any significant changes? > >> --- 11Sep98 --- >> ASnum NetsNow NetsCIDR NetGain % Gain Description >> >> AS701 1185 956 229 19.3% Alternet >> AS271 349 152 197 56.4% BCnet Backbone >> AS4293 445 258 187 42.0% IMCI >> AS174 789 611 178 22.6% Performance Systems International >> AS3749 225 68 157 69.8% TECNET >> AS2493 373 217 156 41.8% iSTAR Internet, Inc. >> AS4200 192 100 92 47.9% AGIS (Apex Global Information Ser >> AS5668 128 41 87 68.0% Century Telephone Inc. >> AS2685 229 151 78 34.1% IBM Global Network - US >> AS4755 125 49 76 60.8% Videsh Sanchar Nigam Ltd. India >> AS3221 117 44 73 62.4% EENet Autonomous System >> AS4740 404 336 68 16.8% Ozemail Pty Ltd (ASN-OZEMAIL) >> AS3493 251 183 68 27.1% INTERLINK >> AS7046 239 172 67 28.0% UUNET-CUSTOMER >> AS3804 215 157 58 27.0% Bell Solutions >> AS10928 101 46 55 54.5% UNKNOWN >> AS549 204 151 53 26.0% ONet Backbone >> AS8517 123 71 52 42.3% ULAKNET-ASN >> AS6335 69 20 49 71.0% NTRNET >> AS72 87 39 48 55.2% Schlumberger Information Network >> AS1239 548 501 47 8.6% SprintLink Backbone >> AS803 78 34 44 56.4% SaskNet Backbone >> AS6181 66 26 40 60.6% FUSE-NET >> AS4539 67 27 40 59.7% NETROPOLIS >> AS852 159 120 39 24.5% AGT Advance Communication >> AS3403 159 120 39 24.5% TIAC >> AS7122 118 80 38 32.2% MTS ADVANCED Network Policy >> AS10459 45 10 35 77.8% WANSASN >> AS2707 64 31 33 51.6% WEC >> AS6332 89 58 31 34.8% TELNOR > >--------------------------------------------------- > Tim Wolfe, Network Administrator > ClipperNet Internet Access Services >tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax > ...Across the Desktop and around the World... >--------------------------------------------------- >

1 0

The Cidr Report
by Tony Bates 11 Sep '98

11 Sep '98

This is an auto-generated mail on Fri Sep 11 12:00:00 PDT 1998 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 11Sep98 0) General Status Table History ------------- Date Prefixes 040998 52828 050998 52652 060998 52614 070998 52667 080998 52746 090998 52823 100998 53697 110998 53238 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: 4054 Number of ASes announcing only one prefix: 1961 (1002 cidr, 959 classful) Largest number of cidr routes: 343 announced by AS3561 Largest number of classful routes: 1185 announced by AS701 1) Gains by aggregating at the origin AS level --- 11Sep98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1185 956 229 19.3% Alternet AS271 349 152 197 56.4% BCnet Backbone AS4293 445 258 187 42.0% IMCI AS174 789 611 178 22.6% Performance Systems International AS3749 225 68 157 69.8% TECNET AS2493 373 217 156 41.8% iSTAR Internet, Inc. AS4200 192 100 92 47.9% AGIS (Apex Global Information Ser AS5668 128 41 87 68.0% Century Telephone Inc. AS2685 229 151 78 34.1% IBM Global Network - US AS4755 125 49 76 60.8% Videsh Sanchar Nigam Ltd. India AS3221 117 44 73 62.4% EENet Autonomous System AS4740 404 336 68 16.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS3493 251 183 68 27.1% INTERLINK AS7046 239 172 67 28.0% UUNET-CUSTOMER AS3804 215 157 58 27.0% Bell Solutions AS10928 101 46 55 54.5% UNKNOWN AS549 204 151 53 26.0% ONet Backbone AS8517 123 71 52 42.3% ULAKNET-ASN AS6335 69 20 49 71.0% NTRNET AS72 87 39 48 55.2% Schlumberger Information Network AS1239 548 501 47 8.6% SprintLink Backbone AS803 78 34 44 56.4% SaskNet Backbone AS6181 66 26 40 60.6% FUSE-NET AS4539 67 27 40 59.7% NETROPOLIS AS852 159 120 39 24.5% AGT Advance Communication AS3403 159 120 39 24.5% TIAC AS7122 118 80 38 32.2% MTS ADVANCED Network Policy AS10459 45 10 35 77.8% WANSASN AS2707 64 31 33 51.6% WEC AS6332 89 58 31 34.8% 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

2 1

draft minutes from RIPE 30
by SchmitzJo＠aol.com 08 Sep '98

08 Sep '98

Dear all, please find enclosed the draft of the minutes of the Routing WG session at RIPE 30. Thanks to the detailed notes of Ambrose Magee, I am able to distribute them in such detail even at this late a time - the delay is entirely on me to blame. Comments, additions, corrections are welcome. The draft of the agenda for our session during RIPE 31 will be distributed shortly. Regards Joachim ----- Draft Minutes: Routing Working Group. RIPE 30 --------------------------------------------- Chair: Joachim Schmitz (JS395-RIPE) Minutes: Ambrose Magee (AMRM1-RIPE) Attenders: 96 A. Preliminaries (Joachim Schmitz) Joachim Schmitz opened the working group, passed the attenders' list around and asked for a volunteer scribe. Ambrose Magee volunteered as scribe. The working group agreed upon the minutes of the previous meeting, and accepted the draft agenda earlier circulated on the mailing list. Joachim Schmitz then told that Carol Orange has left the RIPE NCC and has returned to the US. She has been closely working together with the Routing WG. He thanked her for her continuous support, her valuable ideas, and her numerous contributions. Part of her work has been taken over by Joao Luis Silva Damas of the RIPE NCC who has already proven his interest in our work. Review of actions RIPE 29 o 29.R1 G.Winters, J.Schmitz, RIPE NCC Definition of the IRR and an AUP -open- The IRR up to now exists just for convenience, however a new role evolves with new developments. Some basics had been prepared, but not yet sufficient to be presented. Work will proceed during summer. o 29.R2 RIPE NCC, JLS Damas Implementation of cross notification and aut-num authorization -half done- Cross notification is implemented in the test database and expected to be moved to production phase in a few weeks. Work for autnum- authorisation is on hold because of the staffing situation. o 29.R3 RIPE NCC, JLS Damas Implementation of PGP -open- There has been work done on the specification. A draft will become available 2 weeks after this RIPE meeting. Implementation is planned to be finished around RIPE31 B. Recent Developments (Joachim Schmitz) o RPSL implementation RPSL is the Routing Policy Structured Language developed by the IETF RPS WG (http://www.ietf.org/html.charters/rps-charter.html) The definition of RPSL is Proposed Internet Standard now (RFC2280). It allows detailed description of routing policies. It is on the way of being implemented at the routing registries. Some of it was presented in the Database WG session. According to a recent announcement by JLS Damas, an implementation has also been installed at RIPE. David Kessens later on gave a presentation about progress on the transistion to RPSL (http://www.isi.edu/ra/rps/transition) o Routing Registry Security Approximately one year ago, the issue of database security led to the RIPE Database Security Task Force being founded. In the IETF RPS WG this topic has been taken up for the IRR. A draft is already available from them (http://www.ietf.org/internet-drafts/draft-ietf-rps-auth-01.txt) David Kessens summarized the most important items later in this session. o IRTF Routing Research Group founded There is not only the IETF with the focus on "E"ngineering but also the IRTF focusing on "R"esearch. A routing research group has recently been founded. They are just in the beginning and welcome input. Those who are interested may want to look at their web resources http://www.irtf.otg/irtf/charters/routing.html o BGP AS Origin Authentication with DNS A presentation was given later on during the session by Randy Bush, one of the authors of the corresponding draft http://www.ietf.org/internet-drafts/draft-bates-bgp4-nlri-orig- verif-00.txt C. Report from the RIPE NCC (Joao Luis Silva Damas) In general, the report from the RIPE NCC consisted of the comments given regarding status of the actions, and implementation of RPSL at RIPE. D. Progress report on the transition to RPSL (David Kessens) To implement RPSL at the IRR a transition occurs in three phases (for details also see http://www.ietf.org/internet-drafts/draft-ietf-rps-transition-02.txt) - development of server software - tool development and testing, education of users - switch over to RPSL These phases were then discussed in more detail. o Phase 1: The server software development is finished. The RIPE database software based on RPSL is ready for phase 2. o Phase 2: RADB and RIPE have moved to phase 2. The RPSL database can be tested at RIPE queries: whois -h rpslii.ripe.net (usual port) submissions: mailto:auto-rpsl@ripe.net ISI/RADB queries: whois -h whois1.avalon.rs.net submissions: mailto:auto-dbm@isi.edu The RAToolSet is developed to be compliant with RPSL needs. There are already some service providers who make use of RPSL (Telstra and Connect in Australia, several major ISPs in the US are also eager to start with RPSL). Due to questions from the audience the current state of phase 2 was then described in more detail: Phase 2 is experimental. Two sets of the database coexist now, one in the old RIPE-181 style, the other in RPSL style. Currently, only autnum objects are different. Queries to the standard whois host display the RIPE-181 style; queries to the RPSL host display RPSL style. If only RIPE-181 objects are present, queries to the RPSL host will result in display of the RIPE-181 object tranformed to RPSL style. Similarly, updates to the corresponding hosts only affect the related style. An RPSL update will not affect the RIPE-181 object and vice versa. o Phase 3: In phase 3 all RIPE-181 objects will be transformed to RPSL objects. A meeting was held where all registries participated to coordinate the transition to phase 3. There is no schedule yet for several reasons: - The RIPE NCC will need more time and documentation to run a stable production environment - The RPSL database software must be tested - The tools development is not yet finished, i.e. they are not yet capable of handling RPSL in full - People must be able to adapt Autumn is considered the earliest date when these preliminaries may be finished. However, it is more likely that phase 3 will start during winter. In order to facilitate the transition for all users of the IRR, tutorials are held. This is alrady done at Nanog meetings in the US. For Europe there will also be corresponding tutorials. One is planned for the next RIPE meeting. Details will be announced well in advance. E. Interdomain Routing Tools and Analysis (Craig Labovitz) (http://www.merit.edu/ipma/docs/presentations/ppt/RIPE30/index.htm) Craig Labovitz first introduced the IPMA project (Internet Performance Measurement and Analysis, http://www.merit.edu/ipma/) Probe machines are locatd at IXPs and throughout the backbone, providing real-time inter- domain problem diagnostics. A map with the locations was shown. Originally, the focus was on routing stability. Lately, more attention was on latency and losses. Most recently, issues related to visualization of the measured data are worked on. Then, Craig showed several graphs and results from earlier routing stability investigations. The most prominent ones were related to BGP updates (up to 60 million per day). The vast majority of the updates consisted of withdrawals, most of them being repeated and obsolete. It turned out that they resulted from implementation decisions of BGP by the vendors which had to be considered bugs. Besides these reasons problems in BGP result from - BGP/IGB misconfiguration - CSU/DSU oscillation (interaction of CSU/DSU with router interface which is not configured down) - SEP ("someone elses problem", i.e. blaming others) - self-synchronisation Due to corrected software the number of BGP updates has dropped by one order of magnitude. In addition, announcements and withdrawals are now approximately the same. Most announcements today result from oscillations in attributes. In addition there are still duplicates. It turns out that most of them are related related to MED and AS-path changes. These were investigated more closely for MICHnet which is a small network which is considered stable. It propagates only approximately 100 routes to the outside Internet. Surprisingly, there were still roughly 1000 BGP updates per day to the outside world. Looking for the reasons they did not only find those mentioned in the list above but were also able to identify a pattern related to certain periodic OSPF updates inside the network. Having those explained they are now investigating for causes of the remaining "noise". The IPMA tools used for the investigations described above are now leaving the alpha phase. They are now starting to work together with other ISPs. For further investigations and tests they need help from other ISPs, and kindly ask for support. References are information: http://www.merit.edu/ipma mailto: ipma-support(a)merit.edu The presentation was very interesting and Joachim Schmitz strongly recommended that the IPMA tools and analysis should be used to improve overall network stability. Several questions were triggered by the presentation. Randy Bush wanted to know whether it was common for ISPs to redistribute IGP to BGP. Craig replied that he is unaware of how common this is on the Internet. However, they found it with one of the small ISPs which is connected to their backbone. Actually, the more recent versions of the Cisco manuals contain a warning about it. Yakov Rekhter asked on the impact of different internal routing protocols. However, only OSPF was analyzed in detail. With most of the BGP instabilities resolved it makes now sense to also look at IGP instabilities. The BGP updates were measured at route servers. Probably not all updates are propagated beyond one peering AS because they are only important for the direct peering. Some could be captured by multihop sessions. It seems that most updates really result from pure usage and load. Nonetheless, maintenance windows with operator interference are visible. F. Comments on IRR Security (David Kessens) David Kessens showed transparencies from Curtis Villamizar who was not able to attend this RIPE meeting. He is one of the authors of two new RPS drafts - rps auth (http://www.ietf.org/internet-drafts/draft-ietf-rps-auth-01.txt) - rpsl dist (in preparation) The focus of the presentation was on RPS Security. The IRR is more than just a mapping of routing prefixes to AS numbers. It includes hierarchical address and route allocation. An authentication model is discussed which introduces various new objects and attributes to objects, in order to meet the desired objectives. As means for authorization/authentication PGP is suggested. The draft is subject to additional reviews. Nonetheless, deployment of the model is under consideration. The authors claim that changes to the database and operational procedures are simple. They also estimate that their proposal is sufficient to provide authorisation and authentication to secure the IRR. David Kessens urged the WG to supply comments on this document because implementation is planned soon. The most important question was related to PGP as secure mechanism. To use it for RPS Security commercial copies are needed, leading to the question of license costs. Actually, this is not a problem in the RIPE community due to the distribution license acquired by the RIPE NCC. Moreover, licences would only be needed for updates; read access to registry data does not require a PGP license. In addition, Open PGP is currently under development at IETF. It must also be noted that the proposal is not limited to PGP and does not exclude other means of authorization/authentication. PGP is just the method which currently is readily available. G. BGP AS Origin Authentication with DNS (Randy Bush) (http://psg.com/~randy/980519.ripe/ http://www.ietf.org/internet-drafts/draft-bates-bgp4-nlri-orig- verif-00.txt) As motivation for the work they have been doing, Randy Bush gave several examples of BGP disasters in the last months (e.g. the BGP to RIP to BGP reinjection killing all aggregates, or UUnet's 128/9 leak). The source of the problem is not that much that misconfigurations occur - of course this is a problem, but the real source behind it is that any AS may inject any prefix into worldwide routing tables. Not only misconfigurations cause problems but this may also be used maliciously. While the IRR is an "ideal" solution, the authors see several drawbacks which they propose to solve by a pragmatic solution. The approach is based upon encoding address space allocation in DNS by expanding the RR definition accordingly. The data included is prefix/length and AS for each route. BGP speakers could then look up received prefixes on nameservers. The possible results are - authenticated: found and AS matched This route is accepted as valid and preferred above unauthenticated routes - failed: found and AS does not match This route is withdrawn - unauthenticated: not found, unknown This route is accepted as long it is not superseded by an authenticated route. This situation is the same as today for all routes, and would also occur at startup before the routes could be verified. Several other issues had also been thought of. Nonetheless, the proposal led to a series of questions. An issue was the amount of DNS queries. It turns out that these can easily be several millions. Depending on the load on a nameserver reading this information may take in the order of magnitude of an hour. During this time most routes are still unauthenticated which is also the case if DNS was down. However, this is the situation today. Additional authentication improves the overall situation. Concerns regarding router performance are considered to be unimportant because the CPU power needed is negligible. Estimates also do not see a problem if a "routing bomb" with e.g. 200,000 routes is sent to the router. It just eats through the entries in its idle time. For presentation of classless IP routes the Jan de Groot / Eidnes DNS hack can be used. As Randy Bush pointed out there are still some open issues, e.g. usage of DNSSEC, or which namespace to use. Therefore, input to the proposal is welcome. H. General Input from Other WGs There was no input from other working groups at this time. I. AOB Randy Bush asked for a new version of the route flap damping paper. Christian Panigl as leading author answered that he is collecting additional input and welcomes contributions. Agenda ------ R I P E 3 0 S T O C K H O L M Routing Working Group Session 19-May-98 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 29 minutes - actions from earlier meetings B. Recent Developments (Joachim Schmitz) - Changes in RIPE NCC - RPSL implementation - Routing Registry Security - IRTF Routing Research Group founded - BGP AS Origin Authentication with DNS C. Report from the RIPE NCC (Joao Luis Silva Damas) D. Progress report on the transition to RPSL (David Kessens) E. Interdomain Routing Tools and Analysis (Craig Labovitz) - Research on Routing Instability - Routing Statistics and Measurements - Tools F. Comments on IRR Security (David Kessens) - Routing Policy System Security G. BGP AS Origin Authentication with DNS (Randy Bush) 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 29.R3: RIPE NCC, JLS Damas Implementation of PGP Action 30.R1: RIPE NCC, JLS Damas Implementation of autnum authorization Action 30.R2: RIPE NCC, J. Schmitz, W. Woeber Organize RPSL tutorials for RIPE 31 Ambrose Magee, Joachim Schmitz, 8 September 1998 -----

1 0

The Cidr Report
by Tony Bates 04 Sep '98

04 Sep '98

This is an auto-generated mail on Fri Sep 4 12:00:00 PDT 1998 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 04Sep98 0) General Status Table History ------------- Date Prefixes 280898 53151 290898 53143 300898 53149 310898 53251 010998 53157 020998 53162 030998 53176 040998 52828 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: 3962 Number of ASes announcing only one prefix: 1903 (997 cidr, 906 classful) Largest number of cidr routes: 350 announced by AS701 Largest number of classful routes: 1174 announced by AS701 1) Gains by aggregating at the origin AS level --- 04Sep98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1174 950 224 19.1% Alternet AS271 349 152 197 56.4% BCnet Backbone AS4293 445 260 185 41.6% IMCI AS3749 224 67 157 70.1% TECNET AS2493 374 219 155 41.4% iSTAR Internet, Inc. AS174 696 569 127 18.2% Performance Systems International AS4200 192 98 94 49.0% AGIS (Apex Global Information Ser AS5668 133 42 91 68.4% Century Telephone Inc. AS2685 234 154 80 34.2% IBM Global Network - US AS4755 124 47 77 62.1% Videsh Sanchar Nigam Ltd. India AS4740 419 344 75 17.9% Ozemail Pty Ltd (ASN-OZEMAIL) AS3221 116 45 71 61.2% EENet Autonomous System AS7046 236 171 65 27.5% UUNET-CUSTOMER AS3493 220 156 64 29.1% INTERLINK AS3804 215 157 58 27.0% Bell Solutions AS3403 182 127 55 30.2% TIAC AS549 203 150 53 26.1% ONet Backbone AS8517 123 71 52 42.3% ULAKNET-ASN AS10928 100 48 52 52.0% UNKNOWN AS719 469 418 51 10.9% LANLINK autonomous system AS6335 69 20 49 71.0% NTRNET AS72 87 39 48 55.2% Schlumberger Information Network AS1239 552 504 48 8.7% SprintLink Backbone AS803 78 34 44 56.4% SaskNet Backbone AS6181 66 26 40 60.6% FUSE-NET AS4539 67 27 40 59.7% NETROPOLIS AS852 158 119 39 24.7% AGT Advance Communication AS7122 119 80 39 32.8% MTS ADVANCED Network Policy AS10459 45 10 35 77.8% WANSASN AS4763 100 66 34 34.0% Telstra New Zealand 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 28 Aug '98

28 Aug '98

This is an auto-generated mail on Fri Aug 28 12:00:00 PDT 1998 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 28Aug98 0) General Status Table History ------------- Date Prefixes 210898 52842 220898 52964 230898 52773 240898 53047 250898 53127 260898 53242 270898 53089 280898 53151 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: 3922 Number of ASes announcing only one prefix: 1901 (987 cidr, 914 classful) Largest number of cidr routes: 346 announced by AS3561 Largest number of classful routes: 1175 announced by AS701 1) Gains by aggregating at the origin AS level --- 28Aug98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS3602 552 320 232 42.0% Sprint Canada Inc. AS701 1175 949 226 19.2% Alternet AS271 351 153 198 56.4% BCnet Backbone AS4293 444 258 186 41.9% IMCI AS2493 384 227 157 40.9% iSTAR Internet, Inc. AS3749 223 67 156 70.0% TECNET AS174 701 576 125 17.8% Performance Systems International AS4200 193 99 94 48.7% AGIS (Apex Global Information Ser AS5668 131 42 89 67.9% Century Telephone Inc. AS2685 242 161 81 33.5% IBM Global Network - US AS4755 124 47 77 62.1% Videsh Sanchar Nigam Ltd. India AS4740 421 346 75 17.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS3221 112 42 70 62.5% EENet Autonomous System AS7046 234 168 66 28.2% UUNET-CUSTOMER AS3493 242 176 66 27.3% INTERLINK AS3804 215 157 58 27.0% Bell Solutions AS3403 182 127 55 30.2% TIAC AS10928 101 46 55 54.5% UNKNOWN AS549 205 151 54 26.3% ONet Backbone AS8517 124 72 52 41.9% ULAKNET-ASN AS719 464 415 49 10.6% LANLINK autonomous system AS6335 69 20 49 71.0% NTRNET AS72 87 39 48 55.2% Schlumberger Information Network AS1239 551 503 48 8.7% SprintLink Backbone AS803 78 34 44 56.4% SaskNet Backbone AS4539 68 27 41 60.3% NETROPOLIS AS852 158 118 40 25.3% AGT Advance Communication AS6181 66 26 40 60.6% FUSE-NET AS7122 119 80 39 32.8% MTS ADVANCED Network Policy AS4614 68 32 36 52.9% Asiaonline Hong Kong 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 21 Aug '98

21 Aug '98

This is an auto-generated mail on Fri Aug 21 12:00:02 PDT 1998 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 21Aug98 0) General Status Table History ------------- Date Prefixes 130898 52878 150898 52681 160898 52695 170898 52882 180898 54822 190898 52846 200898 52926 210898 52842 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: 3903 Number of ASes announcing only one prefix: 1880 (974 cidr, 906 classful) Largest number of cidr routes: 351 announced by AS3561 Largest number of classful routes: 1189 announced by AS701 1) Gains by aggregating at the origin AS level --- 21Aug98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1189 955 234 19.7% Alternet AS3602 552 321 231 41.8% Sprint Canada Inc. AS271 337 146 191 56.7% BCnet Backbone AS4293 435 248 187 43.0% IMCI AS2493 387 229 158 40.8% iSTAR Internet, Inc. AS3749 224 67 157 70.1% TECNET AS174 717 583 134 18.7% Performance Systems International AS4200 195 100 95 48.7% AGIS (Apex Global Information Ser AS5668 130 44 86 66.2% Century Telephone Inc. AS2685 240 157 83 34.6% IBM Global Network - US AS4755 121 46 75 62.0% Videsh Sanchar Nigam Ltd. India AS4740 408 337 71 17.4% Ozemail Pty Ltd (ASN-OZEMAIL) AS3221 112 42 70 62.5% EENet Autonomous System AS7046 228 164 64 28.1% UUNET-CUSTOMER AS3804 214 156 58 27.1% Bell Solutions AS549 199 145 54 27.1% ONet Backbone AS3403 181 127 54 29.8% TIAC AS8517 124 72 52 41.9% ULAKNET-ASN AS10928 100 48 52 52.0% UNKNOWN AS719 462 413 49 10.6% LANLINK autonomous system AS6335 69 20 49 71.0% NTRNET AS72 87 39 48 55.2% Schlumberger Information Network AS1239 527 479 48 9.1% SprintLink Backbone AS4539 71 24 47 66.2% NETROPOLIS AS803 78 34 44 56.4% SaskNet Backbone AS1785 301 258 43 14.3% NYSERNet Backbone AS852 157 117 40 25.5% AGT Advance Communication AS6181 66 26 40 60.6% FUSE-NET AS7122 120 82 38 31.7% MTS ADVANCED Network Policy AS226 108 72 36 33.3% USC/Information Sciences Institut 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: The Cidr Report
by Sean M. Doran 19 Aug '98

19 Aug '98

| > B/ When we can easily do: | > | > "router bgp N | > proxy-aggregate route-map Lazy-Types | | I may be misunderstanding, but does this (proposed) config statement | automaticly suppress (aggregate) any prefixes that are exactly the | same as another prefix except in the length? For example given | | 128.8.0.0/16 | 128.8.0.0/24 | 128.8.1.0/24 | | the last two would not be propogated? That would be cool! Right, essentially. This is particularly easy if all the attributes are the same, notably the AS_Path. In IOS there is already a pretty good set of tools to choose what one proxy-aggregates -- and how -- that were developed several years ago; a tool to choose when to apply a set of these would also be useful. One policy that I think would be useful would be: "Does the origin AS announce more than N prefixes? If so, aggregate/drop more specifics as follows..." Sean.

1 0

Re: The Cidr Report
by Sean M. Doran 18 Aug '98

18 Aug '98

Tli asked: | Exercise for the reader: If prefixes of length F and longer are filtered, | and a domain has a prefix of length N, how many prefixes can they propagate | into the backbone? How many before people start proxy aggregating them? A/ (2 ** F) - 1. [assuming nobody imposes exact-match prefix filters] B/ When we can easily do: "router bgp N proxy-aggregate route-map Lazy-Types ! exceptions route-map Lazy-Types deny 10 match as-path 100 ! the rule route-map Lazy-Types permit 20 match originated-prefix-count 16" then the number 16 strikes me as a starting point, although I probably want to re-read Dennis's comments from a few years ago. Do I pass? Sean.

2 1

Re: The Cidr Report
by Tony Li 18 Aug '98

18 Aug '98

> > | AS762 118 81 37 31.4% WELLFLEET-AS > > Oddly enough, they are announcing the aggregate *and* the specifics: > > > brd1>sho ip bgp reg _762_ > *> 192.32.0.0/16 207.106.96.5 0 4969 6461 1673 > *> 192.32.2.0 207.106.96.5 0 4969 6461 1673 > *> 192.32.3.0 207.106.96.5 0 4969 6461 1673 > *> 192.32.4.0 207.106.96.5 0 4969 6461 1673 > *> 192.32.6.0 207.106.96.5 0 4969 6461 1673 If one were paranoid, one might imagine that they are doing so intentionally to see how many Cisco routers they can tank through prefix overload. The problem with this is that a) they aren't also announcing the /17's, /18's, ... /25's and b) overloading a Cisco seems to mean that someone buys a bigger Cisco, thereby enhancing Cisco's revenue stream. One is then left with the theory that they are advertising more specifics for optimality, but haven't discovered communities yet. Exercise for the reader: If prefixes of length F and longer are filtered, and a domain has a prefix of length N, how many prefixes can they propagate into the backbone? How many before people start proxy aggregating them? Tony

1 0