Dear colleagues, please find below the first draft of the minutes of our working group session at RIPE 37 in Amsterdam. My thanks go to Marek Bukowy who prepared the minutes, which took me then just too long to review them and send them out... As usual: comments, corrections, additions are very much appreciated. Thanks Joachim --- JS395-RIPE -- standard disclaimer --- R I P E 3 7 A M S T E R D A M Routing Working Group Session 14-Sep-2000 Draft Minutes Chair: Joachim Schmitz (JS395-RIPE) Minutes: Mark Bukowy Participants: 97 A. Preliminaries Joachim chaired the meeting, gave a brief introduction, and passed around the participants' list. Asking for a scribe to take the minutes of the session lead to the usual panic in the audience that one of them may be chosen deliberately by the chair, but to general relief Marek Bukowy volunteered, and took the minutes you are reading now. The agenda for the session was accepted without changes. The minutes of last RIPE meeting (RIPE36) distributed earlier on the mailing list were accepted by the audience, and thus are declared final. Remaining actions from earlier meetings were: 31.R1 on RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR -done- This has become part of the RIPE NCC activity plan for 2001, allocating resources for this project; also a part on multicast has been added. From the point of view of that this has been initiated, the action is considered closed. Both the IPv6 and the Routing WG will continue to follow the development. 32.R1 on RIPE NCC, JLS.Damas Prepare draft document on issues of RIPE-181 to RPSL transition -done- The draft document has been prepared and is available at the URL http://www.ripe.net/ripencc/pub-services/db/reimp/new-transition-v3.ps 34.R1 on C.Panigl Provide updates to RIPE-178 -done- Christian has provided the updates which are available as RIPE document RIPE-210. However, the contents has triggered additional dicussion; accordingly, we will have some short presentations and input from the audience later during the session 36.R1 on RIPE NCC During the transition phase to the RPSL software - verify with RADB on their test suites for RPSL implementations - coordinate with RADB on consistent mirroring of databases (NRTM) - coordinate with RADB on consistent whois interface of databases including irrd This action is still ongoing Multicast Workshop Report As part of the introduction, Joachim reported on the Multicast Application Workshop which had been held on Tuesday. It had been fully organized and prepared by Patrick de Muynck (BELNET). He himself gave some presentations and got additional contributions from Steve Simlo (Cisco), and Andreas Bogk (integrated media). Both BELNET and Cisco provided the hardware, making the practical presentations possible. Together with the RIPE NCC they built the demonstration network. Joachim thanked all people who worked to make the workshop a success, in particular Patrick who spent most of the time on that. The audience of 70 participants was definitely very pleased with the workshop which is considered to be a great success. C. RADB Update (Gerald Winters, Frontier Global Crossing) presentation available at http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/gerard_winte... / Gerald summarized status, development, and future projects around RADB. In particular * recent developments were - conversion to RPSL complete - Merit's maintainer fee program receives broad community support - additional features around interface like autoformatting and atomic transaction support - PGP key-cert object support - work is ongoing regarding "RPS Dist" * Relational DB backend Instead of using flat files, RADB now employs a relational database backend (TimesTen), allowing relational queries when using IRRd. For several features this has already proven its usefulness, but there are also concerns whether the software will meet the performance requirements. This is being tested. An important note is that the IRRd integration with the TimesTen backend will become available as open source code. * Scaling issues Due to the growth of the community, RADB is faced with various scaling issues. Work has been done to improve the situation but not all of it is easily tackled. * Future projects Gerald mentioned the following projects which will be dealt with in the future - RPS auth implementation - GPG support - IRRd v2.0 release - introducing software for bug tracking which will be open to the community The presentation was particularly interesting because it did not only show the status of RADB as one of the main registries in the world, but also the different development and focus due to differing boundary conditions and requests from the community compared to the RIPE database. E. RIS, Status and Plans (Henk Uijterwaal, RIPE NCC) presentation available at: http://www.ripe.net/ripencc/pub-services/np/Talks/0009_RIPE37/ Henk gave a brief overview of several items, glancing first at administrative stuff like more staff becoming available for the project, and announcing the PAM2001 workshop dealing with measuring data on the Internet. Details are available at the URL http://www.ripe.net/pam2001 The highlights of the past months were - upgrades of the database server to handle the increased load - introduction of a 2nd router collector, installed at the LINX - development of the new tool showing ASs in use, which can be tried at http://abcoude.ripe.net/ris/asinuse.cgi - generation of daily reports In the upcoming months, RIS development will be contined, in particular improving performance, and increasing data input. The intent is to move this to production during the course of 2001. In a question from the audience, it was referred to an observation of RIS during the previous RIPE meeting: RIS sees more prefixes in the union of all peers than what is generally known as the defaultless routing table. The question was whether this is now understood? Henk reported that no definite answer has yet been found. Discussions were held at SitCom, IETF, and some ideas on how to attack this problem have come up. However, this is still work in progress. F. The Routing Registry Consistency Project (Shane Kerr, RIPE NCC) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/rrc/ Shane gave an introduction to this new project initiated in the Routing WG. Essentially, it builds on - RIS, the Routing Information Service, where life data from the Internet is collected - and the RIPE IRR comparing both sets of data. The main goal of the project is to make the database more accurate, and thus more useful. Suggestions of user interfaces were presented, and what the current status of the project is: As this presentation was a introduction to new work, the project is still in the initial research phase, but they also start to build comparison tools. G. Study of BGP Convergence (Abha Ahuja, Internet Network Services) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE-37-conv... gence/ The title of the presentation had been changed to "Delayed Internet Routing Convergence", focussing on a very interesting facet of BGP convergence. Essentially, the question is how well the Internet infrastructure does tolerate faults. According to conventional wisdom fault toleration seems to be high and problems are resolved fast. This has been put to the test with a simple failure analysis: To this end, a route is inserted or withdrawn at one point on the Internet, and its visibility is measured at other places on the Internet. There were quite some surprises found in the analysis of the results. In particular, the idea that "bad information travels fast" is actually wrong. It was shown that in 60% of the cases, complete withdrawal of an invalid route takes more than 2 minutes. The reason for that lies in the fact that all possible paths must be explored and then individually invalidated. This becomes a problem which grows as the factorial of the number of BGP speakers, and results from avoidance of loops. Essentially, this means that in the extreme, BGP may not converge at all. So far, we are saved by BGP policies, and several BGP timers which put a bound on some of the behaviour. However, with an ever growing Internet, this becomes more and more of a problem. The presentation caused a vivid discussion, in detail: Q: What was the path length between the point of injection of the withdrawal and the measuring point ? A: variable (different ISPs were used in the measurement). Conclusion is that it has no influence. Q: Does route flap dampening help achieve better convergence ? A: Yes, it would bound some of the announcements. However, the worst case scenarios don't really occur in real life. Q: The effectiveness of dampening is though determined by its settings? A: Definitely. Some people in the room have been affected by wrongly set dampening parameters. Injected announcements alternated with withdrawals will be dampened if they are "oscillating" faster than the flap dampening timers allow. Q: This was also the reason for ripe-178. Have you been able to reproduce this effect in the following situation: 2 AS's connected in 4 places, a withdrawal would travel 4 times between the AS's. In effect, one route flap would appear 4 times, and consequently the BGP neighbours would damp the route immediately. A: There was no real conclusion on that question; however, it is obvious that complex situations are generated easily. Christian Panigl who described this example, will discuss this in detail with Abha for further real life studies. Q: On internet exchange points all peers are directly connected to each other. Would that be a potential for similar effects? A: Ideally, these peers are not exchanging full routing tables, but only their internal and their customers' routes. The theoretical worst case scenario shown here can happen if you provide mutual transit. Q: Does it also apply to IGP meshes as they are growing bigger ? A: There is obviously some impact, but details are not known, because Abha and her colleagues have not yet looked at it. However, it will be taken up H. Routing Table Analysis (Philip Smith, Cisco) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE37-sept2... 0-Smith.pdf The studies of Abha were nicely complemented by the routing table analysis, Philip does and has recently started sending to the Routing WG mailing list. He described the work he is doing there in his presentation, thanking APNIC for their support, also showing some interesting findings and developments. Essentially, Philip analyzes the full defaultless Internet routing table, taken in daily snapshots. An important part is the correlation to the three regional registries and IANA definitions. Important findings are in the global summary - routing tables again growing exponentially, in particular 100k prefixes will be reached by end Dec 2000 (6 months ago predicted to be Sep 2001) same applies to ASs (10k will be reached Dec 2000) - origin AS rising very significantly - average AS path length more or less stable somewhere 5...6 - max path length 15 also quite stable (removing prepends) - worried in particular about exploding /24 announcements - and longer prefixes (why should they be announced?) An interesting observation is that - only 62% of address space allocated is actually announced - less than half of 17000 assigned ASs are actually announced This presentation also triggered some discussion: Q: Do you strip out duplicate ASN's (to compensate for providers with funny routing policies) A: I think I do. I am certainly stripping out any ASpath pre-paths. Q: Assigned and not announced ASN's: some might not wish to exchange traffic. A: Looking at the ASN's < 10000 there are clusters of not announced ASN's, most notably US military, but also others. Q: Is there an effect of prefix filtering and who is doing it? A: This would most likely become real apparent only when looking at several sources of routing information because it is difficult to determine where more specifics disappear I. RIPE-210 - Updates with contributions from the audience (Philip Smith, Cisco, & Christian Panigl, Vienna IX) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/dampening.pd... First, Philip gave a presentation discussing issues he has seen in the RIPE-210 document. He found that RIPE-210 and RIPE-178 have different network lists which leads to confusion. Moreover, the damping parameters as described do not work. However, the discussion showed that the effect of the parameters depend on the Cisco IOS version, which seems to indicate a Cisco implementation bug, which would need further study. There was no information available about other implementations. Philip then showed some pages from Cisco teaching materials explaining route flap damping, especially the definition of the parameters involved, and how to properly combine them. There was general consensus that it makes sense to incorporate something like this in the document, but also try to get input about how to configure flap damping for other platforms. Philip also found some open questions like whether we would want to suppress slowly oscillating prefixes, or whether we may want to make damping dependent on prefixes, AS paths, or communities. From the audience, the question arose whether any data exists on route oscillations on the Internet, and whether any studies were done. Philip was not aware of any research effort. He had started gathering some flap statistics in Australia, but thinks that doing this at a more central place on the Internet would be much more useful. Abha reported that Merit did a study on announcements/withdrawals a couple of years ago at some US exchange points, measuring oscillations rates etc (for reports about this experiment please contact Abha Ahuja). However, currently no measurements are done. Abha indicated that she is interested to take it up again in her measurements, and data is collected at the RIPE RIS project anyway - it just needs to be analyzed (which is an additional input for RIS development). Nonetheless, in a whole it is interesting to see that damping methods exist but no studies on their effect or efficiency on route flaps on the Internet. Finally, Christian had a few more comments. He explained that he had come up with a list of "golden networks" to exclude from route flap damping due to an incident on a network: routes to the TLD/root nameservers became dampened and those unreachable for more than two hours. The reason for that was insufficient connection to the global Internet, so flapping on the upstream backbone (single connection to the global Internet) can cause exactly this problem. However, keeping the list of networks uptodate is difficult, and we want to avoid having different versions of the same document around. One suggestion was to explicitely flag it as an example which should not be implemented as is. However, experience shows that exactly those examples are most often just copied without crosschecking. Therefore, the idea was to remove the explicite list in its entirety from the document. Instead, Daniel Karrenberg offered to write a script and make it available, which generates a list of the "golden networks", essentially the networks of the TLD/root nameservers (using "dig" on one of the root nameservers). J. Promoting IP Multicast deployment in Europe (Tony Ballardie <ballardie@ngn-ltd.co.uk>) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE37-sept2... 0-Ballardie/ Tony is anticipating a large demand for multicast, and thus introduced the European IP Multicast Initiative (EuMI). He wants to assess sources of problems with multicast deployment, and pro-actively promote it by proposing a "one-stop shop" with - free consulting (limited in time to about a day) - free forum for exchanging ideas - gather input and (re)write documents, explain RFC's, etc to provide for clear, easy to use, documentation. Both sponsors and input is needed for this project. Details can be found at http://www.eumi.net. With those presentations the session had significantly run overtime into the coffee break but thanks to meeting management, there was still enough coffee available for the participants who then came to visit the joint session of the routing and database working groups. The joint session was introduced because of the overlap on the topic of transitioning from the old RIPE-181 database to the RPSL style database. B. Status of the transition to the RPSL database (Andrei Robachevsky, RIPE NCC) presentation available at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/r37-reimp/ The biggest question was discussed first: what is different in the new implementation. This was illustrated by a whole set of examples, where many of them are based on RPSL itself, and its impact on the various objects and attributes in the RIPE database. Moreover, Andrei pointed out that there will also be other differences, around working with the database (querying with a bunch of new options, submissions to the database now with MIME support extended PGP support), near realtime mirroring, and accounting and access control. Andrei then gave an overview about the status the project was in, regarding functionality and availability of test servers. The software is still in beta status and is still tested. Certain features are missing, in particular the overall server infrastructure (backup, cleanup, logging, etc). Others need further development, most notably MIME support, server configuration and administration, and portability of the code has room for improvements. The essential pointers for test usage and information are - near real time mirror of the RIPE database (contains current data in RPSL format): "whois -h rpsl.ripe.net" - test server for submissions: mail <auto-rip@ripe.net> for submissions and "whois -h rpsl.ripe.net -p 4343" for queries - mailing list db-beta@ripe.net - RIPE NCC development team reachable at dbrip@ripe.net - web page http://www.ripe.net/ripencc/pub-services/db/reimp/ Then, Andrei described the transition plan again briefly with its various phases, which had been agreed upon quite some time ago. The initial phases I and II have passed, and we are moving to phase III, which moves the authoritative source of the RIPE database to the new server, with RPSL format. All output would then be RPSL, submissions will be possible with RPSL style to an RPSL input, and with RIPE-181 style to the old existing standard address (mail <auto-dbm@ripe.net>). This move will only be done depending on confidence and consensus in the community. Only after a certain transition time, phase IV will start, still allowing RIPE-181 submissions, but to another mail address, while the standard mail interface at auto-dbm@ripe.net will only accept RPSL style. This will allow to slowly phase out RIPE-181, which in phase V will then no longer be accepted. Finally, Andrei listed a set of obvious transition issues. The list of issues is definitely not yet final, and any input from the community is welcome. To present a focus of concerns and to drive the transition, the Database Migration Task Force has been initiated. Y. Creation of the Database Migration Task Force. For the Database Migration Task Force, Ulf Kieber (UK41-RIPE) has agreed to be its chairman. For communication of the task force, the RIPE NCC will set up the mailing list reimp-mig-tf@ripe.net Everybody is encouraged to participate. Participation of people involved in: - mirroring the database (format and software will change) - parsing the routing registry output (format will change) is particularly welcome. Topics will also include the portability of the new db software. Summary of Open Action Points 36.R1 on RIPE NCC During the transition phase to the RPSL software - verify with RADB on their test suites for RPSL implementations - coordinate with RADB on consistent mirroring of databases (NRTM) - coordinate with RADB on consistent whois interface of databases including irrd 37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz Provide updates to RIPE-210 - general editing, review - explanation of damping parameters - examples by implementation - script to determine TLD/root nameservers for "golden network" list 37.R2 on RIS team, Henk Uijterwaal Implement route flap analysis from RIS data Marek Bukowy, Joachim Schmitz, January 2001 -----