September 1999 - routing-wg - mailman.ripe.net

Top 100 maintainers list
by RIPE Database Administration 22 Sep '99

22 Sep '99

1 0

draft minutes of the RIPE33 Routing WG session
by SchmitzJo＠aol.com 19 Sep '99

19 Sep '99

Dear colleagues, please find enclosed the *draft* minutes of the RIPE33 Routing WG session. I apologize for late distribution which was caused on my side due to not finding any allocatable time slots lately... If you have comments, corrections, or additions, please bring them to the WG session on Wednesday the latest. Thanks Joachim --- JS395-RIPE -- standard disclaimer --- Draft Minutes of Routing WG session - RIPE 33, 5 May 1999 --------------------------------------------------------- Chair: Joachim Schmitz (JS395-RIPE) Scribe: Roman Karpiuk (RK-RIPE), Ambrose Maggee (AMRM-RIPE) Attenders: around 80 A. Preliminaries (Joachim Schmitz) Joachim welcomed the participants, passed around the participants' list, and asked for a volunteer scribe. Roman Karpiuk volunteered to take the minutes. The working group agreed upon the minutes of the previous meeting, and accepted the agenda circulated earlier on the mailing list. Review of previous actions: o 29.R1 G.Winters, J.Schmitz, RIPE NCC Definition of the IRR and an AUP -in progress- Work is ongoing. Action still open. o 31.R1 RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR -in progress- Work is ongoing. Action still open o 32.R1 RIPE NCC, JLS.Damas Prepare draft document on RIPE-181 -> RPSL transition issues -in progress- We will have a presentation from the RIPE NCC on this topic Work is ongoing. Action still open o 32.R2 J.Schmitz Write project definition for Routing Registry reality checking -in progress- B. Status Report: RPS Standards & Drafts (Cengiz Allaettinoglu) http://www.ripe.net/meetings/ripe/ripe-33/pres/rps-status.ps Joachim welcomed the chairmain of the IETF RPS working group Cengiz Allaettinoglu. He gave a status report on the RPS standards and drafts. The report is also available at the RIPE web server. He first gave an overview of current work items. The most important news was that RPSL (Routing Policy Specification Language) is now a proposed standard. A series of tutorials had been held at various Internet meetings around the world, and RPSL has been implemented at several registries or is currently worked on. Cengiz then talked in more detail about two more topics, the RPS WG deals with - Routing Policy System Security - Distributed Routing Policy System which were then discussed in more detail. * Routing Policy System Security Again and again, there are occurrences that someone on the Internet leaks someone else's prefix, in most cases accidentally due to errors in configurations. To establish means to improve stability and integrity of Internet routing, a security model has been developed within the scope of the RPS WG. It includes - authentication essentially based on the work of the RIPE DBsec taskforce which has developed a model using PGP (draft-ietf-rps-dbsec-pgp-authent-01) as an example for authentication - authorization ongoing work of the RPS WG which is already pretty mature and discussed in draft-ietf-rps-auth-03 A set of simple exmaples was given illustrating where questions arise who has authority over a set of prefixes. Accordingly, as set of rules had been developed, to create, update, or delete objects. At the registries this may be achieved by introducing a set of new keywords in the respective objects. Since this is still ongoing work, further input from the community was requested. * Distributed Routing Policy System The current status of this topic is summarized in draft-ietf-rps-dist-01. There are two main issues, finding - a protocol for replication of data - rules to ensure correctness of data The first of the two is relatively easy and commercially available, based on a flooding mechanism including pull and push with automatic discovery. For simple copies of the data a light-weight option will be available. The second issue is much more difficult to deal with. The correctness of data must be ensured in all copies. This can only be achieved by proper delegation while maintaining true authorization throughout. In addition, changes must propagate correctly to maintain overall consistency. Finally, a method must be found for grand fathering legacy objects. C. Report from the RIPE NCC (JLS Damas) http://www.ripe.net/meetings/ripe/ripe-33/pres/routing-wg-report/index.html The report gave a brief overview of the RIPE database. More details and numbers were included in the extended review of the Database WG. However, some interesting numbers were given. The database currently contains 17,000 route objects, where 8,000 are not announced. One quarter of those which are announced, are announced by another AS than they have been registered for. The database software has now reached version 2.2.2. In the old code only bug-fixing is done. The re-implementation of the database software has highest priority, and makes good progress. At this RIPE meeting, again an RPSL training course has been held. There were 40 participants. In the future, RPSL training courses will be offered together with the LIR courses as an extension on a separate day. Regarding the new strong authentication method by PGP: the number of key certificates has now reached 50, and 55 maintainers use PGP (even though 15 of them still have weaker authentication methods active at the same time) Thus, even though the PGP implemenation currently is the only secure method of authentication, only a minority is using it. D. RPSL transition: Issues and progress (JLS Damas) http://www.ripe.net/meetings/ripe/ripe-33/pres/rpsl/index.html The RIPE NCC has been dealing with a number of issues around transition from RIPE-181 to RPSL like how to * align modifications to data between both formats * maintain data availability throughout * continue with deployment In particular, Joao summarized again which modification occur to the presentation of data when moving from the RIPE-181 format to the RPSL format. As a consequence of the transition process, while all routing registries so far have used RIPE-181, from now on, some registries will no longer support RIPE-181 and instead use RPSL only, as all new registries will do in the future. Therefore, the community was again pointed to the fact, that if automatic procedures or programs are used today to process routing registry data, everybody must start thinking today of changing these procedures. Due to the focus on re-implementation of the database software, at RIPE we are still in phase II of the transition (for a description of phases see discussions and presentations in earlier sessions of the Routing WG). Other registries are already close to have reached phase III, the final migration to RPSL. This is shown in the following presentations. Actually, the only native RPSL server is that written by David Kessens. E. Reports from other registries - Overview (D.Kessens) http://www.isi.edu/ra/rps/transition David went through the description of transition phases which can also be found on the given web pages. This included the software which has been developed so far. Much emphasis was on the RIPE-181 to RPSL converter tool which plays a crucial role in the transition. David and ISI were also deeply involved in the education of RPSL and its usage. They held a series of tutorials during NANOG and Apricot meetings. The registry maintained by David is currently in phase II status as well, but ready for phase III. This is still the old style software and is not built on the re-implementation of the RIPE database software which has not yet been finished. - RADB (A.Ahuja) http://www.ripe.net/meetings/ripe/ripe-33/pres/radb-status/index.html At the RADB there are currently three production servers, two for RIPE-181 format, and one for RPSL format. However, the RPSL style database may only be queried. All three support the IRRd software, which in its gamma release now also supports RPSL queries. Thus, RADB is currently in pahse II of the transition. Some development is still ongoing, and phase III is expected to be reached towards autumn. The most important issue which then remains to be solved, is to combine all individual routing registries in a true authentication/security environment. Work on this has already started. After these presentations a few questions were discussed, being related to transition issues. People were worried about a smooth transition. While submissions in RIPE-181 format will automatically be converted to RPSL, reading data from the database with whois is not obvious. There was a suggestion to use a different port for RPSL whois queries which is not easy to get. Others proposed an additional switch, flag, or option to the whois client to deal with RIPE-181 vs RPSL issues, or suggested that RIPE-181 support could be done with a separate program, excluding RIPE-181 support from the whois interface. There was no final conclusion. The topic will be included in the transition document to be provided by the NCC, and also be discussed in the Database WG. F. Why the Internet does not scale (Abha Ahuja) http://www.ripe.net/meetings/ripe/ripe-33/pres/internet-dev/index.html The title of the presentation was changed to "Some Interesting Internet Developments". In general, we are still seeing the "standard" Internet behaviour of exponential growth, e.g. with amount of traffic flows. Accordingly, the imminent collapse of the Internet is predicted since years e.g. address space, bandwidth, etc. However, new solutions are developed as well (IPv6 address space, DWDM on fiber, etc). One important topic in this discussion also is topology. Abha presented some data on the global topological state of the Internet. Orginally, only one major backbone existed, the NSFnet, showing some strong hierarchy in the network. This was given up in favor of a few exchange points. In the meantime, the number of exchange points and probably more prominent the number of individual connections has led to a dense mesh of links. This is clearly visible if looking at the default-less Internet routing table. While the number of prefixes has reached a more or less stable level below 45,000 the number of routes has continued to increase at a steady rate (around 80,000 in Jan-99). Most of this is due to multihoming and more paths introduced by more meshs in the network, leading to a steeper growth than would be expected from the rising number of ASs in the global routing table (from around 1,000 in Jan-96 to about 4,000 in Jan-99). In this time interval the average AS-path length has first increased from 2.75 up to 3.25 (around early spring '98) and since then decreased again to values about 3.15, meaning that on average only 3 ASs must be traversed to reach a destination. At the same time, the average prefix length has very slightly decreased and now has a value around 22 bit. This is the only visible effect of CIDR, which originally was introduced to reduce the number of routes on the Internet. CIDR definitely has its advantages but due to changes in Internet topology, it was not able to noticably affect the size of the globabl routing table. This is nowadays called the "myth of CIDR". In a whole the changes lead to problems due to constraints at various points, especially the increased volume describing the topological state, and the frequency of changes impacts backbone routers. This leads to higher end-to-end loss and latency, introducing convergence problems. In addition, the network management complexity makes dealing with problems in the network much more difficult. G. MBone Developments (K.Kayser) Kurt Kayser gave a very brief overview of MBone developments. As it turns out there is not much traffic on the corresponding RIPE mailing list. In general, development is slowing down because industry does not support it. On their side, real media seems to be of more interest. Thus, MBone is more dealt with on the academic side. Projects currently deal with comparison of unicast multimedia vs multicast, and questions of stability. Otherwise, news on MBone had already been discussed at the EOF session. Y. General I/O with Other WGs There was no input from, and no output to bring to other WGs. Z. AOB Since there were no additional comments or issues, Joachim closed the WG session. --- Agenda ------ R I P E 3 3 V I E N N A Routing Working Group Session 5-May-1999 2nd Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 32 minutes - actions from earlier meetings B. Status Report: RPS Standards & Drafts (Cengiz Allaettinoglu) C. Report from the RIPE NCC (JLS Damas) D. RPSL transition: Issues and progress (JLS Damas) E. Reports from other registries - RADB (Abha Ahuja) - Overview (David Kessens) F. Why the Internet does not scale (Abha Ahuja) G. MBone Developments (Kurt Kayser) - to be confirmed - Y. General I/O with Other WGs Z. AOB Summary of open Action Points ----------------------------- 29.R1 G.Winters, J.Schmitz, RIPE NCC Definition of the IRR and an AUP 31.R1 RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR 32.R1 RIPE NCC, JLS.Damas Prepare draft document on RIPE-181 -> RPSL transition issues 32.R2 J.Schmitz Write project definition for Routing Registry reality checking Ambrose Maggee, Roman Karpiuk, Joachim Schmitz, 18-Sep-1999 ---

1 0

1st draft agenda for the Routing WG
by SchmitzJo＠aol.com 17 Sep '99

17 Sep '99

Dear colleagues, please find enclosed the first draft of the agenda for the session of the routing working group at RIPE 34, Amsterdam. The session will be held Wednesday, 22-September, 14:00 As usual comments, additions, welcome! Please watch out for changes in this draft agenda up to the session itself. --- R I P E 3 4 A M S T E R D A M Routing Working Group Session 22-September-1999 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 33 minutes - actions from earlier meetings B. Report from the RIPE NCC (JLS Damas) C. Updates to RIPE-178 (C.Panigl) - input from the audience on route flap damping D. Multicast Routing - MBone Developments (N.N., to be confirmed) input from the audience - Multicast Routing Projects Introduction (J.Schmitz) LINX (G.Besch) Input from the audience E. Routing between Europe and Asia - An Issue? - A quick glance (J.Schmitz) - input from the audience F. Routing Information Service RIS (A.Antony) G. Reality Checking of the IRR (JLS Damas) Y. General I/O with Other WGs Z. AOB --- Regards Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

Re: Yet another update to ripe-178
by SchmitzJo＠aol.com 15 Sep '99

15 Sep '99

Dear Christian, you wrote: > Joachim, please add a formal Routing-WG agenda item next week > for the "approval" of any suggested updates. Done... Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

RE: Yet another update to ripe-178
by Christian Panigl, ACOnet/UniVie 15 Sep '99

15 Sep '99

>Date: Tue, 14 Sep 1999 17:00:11 +0200 >From: Fredrik Rosenbecker <fredrik.rosenbecker(a)ip-only.net> > >while we're at it, perhaps the IOS-instructions in ripe-178 should be >changed to use prefix-lists instead. It's somewhat more intuitive. Thanks for your detailed input for an update of our "Route Flap Damping Recommendation" ! Any other input is welcome and as I'm the editor of the original paper I'm volunteering to incorporate any WG approved updates/changes. Joachim, please add a formal Routing-WG agenda item next week for the "approval" of any suggested updates. CU in AMS CP

1 0

Yet another update to ripe-178
by Fredrik Rosenbecker 14 Sep '99

14 Sep '99

Hi again, while we're at it, perhaps the IOS-instructions in ripe-178 should be changed to use prefix-lists instead. It's somewhat more intuitive. Kind regards, -- Fredrik Rosenbecker IP-Only AB -- Example configuration below -- router bgp 65500 bgp dampening route-map FLAP ! ip prefix-list max23 description Control dampening of /23 and shorter prefixes. ip prefix-list max23 seq 5 permit 0.0.0.0/0 le 23 ! ip prefix-list min24 description Control dampening of /24 and longer prefixes. ip prefix-list min24 seq 5 permit 0.0.0.0/24 le 32 ! ip prefix-list rootns description Root-nameserver networks. ip prefix-list rootns seq 5 permit 198.41.0.0/24 ip prefix-list rootns seq 10 permit 128.9.0.0/16 ip prefix-list rootns seq 15 permit 192.33.4.0/24 ip prefix-list rootns seq 20 permit 128.8.0.0/16 ip prefix-list rootns seq 25 permit 192.203.230.0/24 ip prefix-list rootns seq 30 permit 192.5.4.0/23 ip prefix-list rootns seq 35 permit 192.112.36.0/24 ip prefix-list rootns seq 40 permit 128.63.0.0/16 ip prefix-list rootns seq 45 permit 192.36.148.0/24 ip prefix-list rootns seq 50 permit 193.0.14.0/24 ip prefix-list rootns seq 55 permit 198.32.64.0/24 ip prefix-list rootns seq 60 permit 202.12.27.0/24 ! route-map FLAP deny 10 match ip address prefix-list rootns ! route-map FLAP permit 20 match ip address prefix-list min24 set dampening 30 750 3000 60 ! route-map FLAP permit 30 match ip address prefix-list max23 set dampening 15 750 3000 45 ! route-map FLAP permit 40 set dampening 10 1500 3000 30 !

1 0

Update to ripe-178
by Fredrik Rosenbecker 13 Sep '99

13 Sep '99

Hi, I was just looking at ripe-178 and I realize that the document needs som updates. ACL 181 in the IOS-example should be changed to access-list 180 permit ip 198.41.0.0 0.0.0.0 255.255.255.0 0.0.0.0 access-list 180 permit ip 128.9.0.0 0.0.0.0 255.255.0.0 0.0.0.0 access-list 180 permit ip 192.33.4.0 0.0.0.0 255.255.255.0 0.0.0.0 access-list 180 permit ip 128.8.0.0 0.0.0.0 255.255.0.0 0.0.0.0 access-list 180 permit ip 192.203.230.0 0.0.0.0 255.255.255.0 0.0.0.0 access-list 180 permit ip 192.5.4.0 0.0.0.0 255.255.254.0 0.0.0.0 access-list 180 permit ip 192.112.36.0 0.0.0.0 255.255.255.0 0.0.0.0 access-list 180 permit ip 128.63.0.0 0.0.0.0 255.255.0.0 0.0.0.0 access-list 180 permit ip 192.36.148.0 0.0.0.0 255.255.255.0 0.0.0.0 access-list 180 permit ip 193.0.14.0 0.0.0.0 255.255.255.0 0.0.0.0 access-list 180 permit ip 198.32.64.0 0.0.0.0 255.255.255.0 0.0.0.0 access-list 180 permit ip 202.12.27.0 0.0.0.0 255.255.255.0 0.0.0.0 There are some minor changes to the wildcard masks and I have also updated the last row to reflect the current location of M.ROOT-SERVERS.NET. Kind regards, -- Fredrik Rosenbecker IP-Only AB

1 0

Re: Top 100 Maintainers List
by Joao Luis Silva Damas 06 Sep '99

06 Sep '99

Hi, depends on what you consider wrong. Response time is definitely wrong. The system is, however, working. The system has on some occcasions, for the last two weeks, received messages at a rate that is faster than the system can handle. This is partly due to the fact that a number of huge messages (containing in the order of 10^4 objects) have been received and they request updates of objects of which there are a big number in the database. The current software hits severe scalability problems when this happens. We have during the last days, devoted a lot of attention to solving these problems by specifically hacking the software to optimize this type of updates. We have tuned the system parameters to the limit. We are currently in the process of trying out an update to the disk system (which to add to all of the above, has suffered an unusual amount of physical problems). We have also contacted the senders of the updates to try to have the messages split and give a chance to everyone else. We are looking at a front end for the database that will do some kind of batch queue handling enabling control over how resources are distributed to users, so that no single user can hog the machine. Also, this is impacting the efforts of the reimplementation project which is the ultimate solution for this problem. Hope this gives you a bit of an overview of the situation. I apologize for the incovenience this is generating for everyone but I assure you, we are doing our best to get this thing to work as fast as possible. Best regards, Joao Damas RIPE DB Group manager RIPE NCC At 17:52 +0200 6/9/99, Hank Nussbacher wrote: >On Mon, 6 Sep 1999, RIPE Database Administration wrote: > >Is something wrong with auto-dbm(a)ripe.net? I have not received any reply >from that id for the past 48 hours. > >-Hank

1 0

Top 100 Maintainers List
by RIPE Database Administration 06 Sep '99

06 Sep '99

2 1

The Cidr Report
by Tony Bates 03 Sep '99

03 Sep '99

This is an auto-generated mail on Fri Sep 3 12:00:00 PDT 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 03Sep99 0) General Status Table History ------------- Date Prefixes 270899 63124 280899 62963 290899 63479 300899 63490 310899 63472 010999 63419 020999 63310 030999 63155 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: 4055 Number of ASes announcing only one prefix: 1630 (346 cidr, 1284 classful) Largest number of cidr routes: 181 announced by AS701 Largest number of classful routes: 835 announced by AS701 1) Gains by aggregating at the origin AS level --- 03Sep99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS99 2 1 1 50.0% INTEL-IWARP AS9536 2 1 1 50.0% Sony Corporation of Hong Kong Ltd AS9511 2 1 1 50.0% Wilson and Horton AS9468 2 1 1 50.0% Timber Hill Honk Kong Ltd. AS9447 2 1 1 50.0% Ford Motors AS9428 2 1 1 50.0% The Net Effect Pty Ltd. AS9175 2 1 1 50.0% VHB-DE AS9084 2 1 1 50.0% Goldman Sachs International AS8963 2 1 1 50.0% INTRASOFT Autonomous System AS8898 2 1 1 50.0% Roche Diagnostics GmbH AS8673 2 1 1 50.0% BusinessOnline AG, German ISP AS8672 2 1 1 50.0% Orbitel Ltd. Autonomous system Nu AS8141 2 1 1 50.0% TBAINFORMATICA AS7912 2 1 1 50.0% STATEFARMINSCO AS7267 2 1 1 50.0% GLOBALCOMMERCE AS6979 2 1 1 50.0% SAP AS6830 2 1 1 50.0% chello broadband AS6575 2 1 1 50.0% Wilmington Internet Service Enter AS6434 2 1 1 50.0% OpNet Inc AS6242 2 1 1 50.0% TELEMAIL AS6234 2 1 1 50.0% ETAK-NET2 AS5839 2 1 1 50.0% DDN-ASNBLK AS5647 2 1 1 50.0% ASN-KODAK AS4939 2 1 1 50.0% ASN-SOLECT AS3346 2 1 1 50.0% HUNGARNET-GODOLLO AS2472 2 1 1 50.0% FR-DOM-GUYANE AS1725 2 1 1 50.0% FR-RENATER-CHAMPAITRE AS1665 2 1 1 50.0% IBM Watson #2, Yorktown Heights, AS13425 2 1 1 50.0% UNKNOWN AS13366 3 2 1 33.3% 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