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 ---