Minutes Routing-wg @ RIPE 35 Chair : Joachim Schmitz (JS395-RIPE) Scribe : Emil Gorter (EMIL-RIPE) Attenders: 92 A. Preliminaries (Joachim Schmitz) Joachim welcomed the participants, passed around the participants' list, and asked for a volunteer scribe. Emil Gorter 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 31.R1 RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR -postponed- Even though this topic is still considered important, there had been not enough input to continue o 32.R1 RIPE NCC, JLS.Damas Prepare draft document on RIPE-181 -> RPSL transition issues -in progress- The draft document is prepared, but not yet publicly available o 34.R1 C.Panigl Provide updates to RIPE-178 -to be closed- Needs to be published B. Report from the RIPE NCC (JLS Damas) The report consisted of two parts: - transition to RPSL - consistency checking of the IRR which were discussed in a combined presentation - Transition to RPSL RPSL will be implemented in the RIPE database software v3.0 which is nearly complete and beta code is available for downloading. The new db can be tested at reimp.ripe.net:43 It will accept no updates, only queries on an almost real time mirror of the current database. It will be tested for 2 months (already started), so testers are welcome to try. Any RPSL object stored in the test database will not be mirrored back into the RIPE-181 production database. Thus, we are still in step one of a three step process: 1. Mirror current db in RPSL 2. Accept updates in RPSL and RIPE-181, RIPE-181 will be converted to RPSL 3. Only accept updates in RPSL For details more information may be found at www.ripe.net/ripencc/pub-services/db/reimp/index.html If there are concerns about the procedures, RIPE NCC would appreciate input to be incorporated in the reimplementation document (action 32.R1). The question arose what happens with any RPSL update done today. They are definitely not visible on the current database. However, it is obvious that during the transition process any test objects in the RPSL part must not be moved into the new RPSL production database. - Consistency Checking of the IRR The goal of the project is to compare BGP data from life Internet to routing information stored in the RIPE IRR, and analyze the results. The input gathered so far will be incorporated in a draft document. This document is expected to become available around RIPE 36. However, it is important to note that the reimplementation effort and the transition to RPSL is run at a higher priority, and this project will only be worked on fully after the reimplementation has been finished. C. RADB/IRRd Update (Gerald Winters) http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/ripe35-radb-... /index.html Gerald gave an overview of the topics presented - recent developments - IRRj - scaling issues - on the horizon which were then discussed in detail. * Recent developments Probably the most important item with regard to the database was that Merit/RADB converted to RPSL which was completed in Nov-99. For two months, in parallel any RIPE-181 updates would overwrite existing RPSL objects. On 1-Jan-2000, RIPE-181 was discontinued, meaning that RADB is now fully and only accepting RPSL. The experience with RPSL is that most users are satisfied, but only very few users actually make use of advanced RPSL features. In a whole it seems that the community still becomes used to RPSL. The second very important topic relates to the organizational structure of RADB. In the past it has been fully subsidized by Merit. Now, Merit is completing the transition to a commercial funding model, which charges a yearly fee to all maintainers registered in RADB. The consequence is that maintainers who do not pay the yearly fee, in the end may be removed from RADB, including all their objects. However, RADB is important, and nobody shall be excluded. People, who do not want to pay fees are therefore encouraged by Merit to open and run their own registries, which is supported by Merit to publish the code of the db software. There is already some interest for this, and Merit will then mirror those who request it. Actually, Merit expects to reduce its role as a database administrator. This statement caused a lot of discussion. Concerns uttered covered - do ISPs need to register in all databases? the answer is no - "private" registries will be mirrored at RADB - how to avoid duplicates then, or correct references (Christian Panigl) this is likely to be a problem; there are some measures taken or under consideration. Merit will definitely start removing old duplicates themselves. It is strongly recommended that when a company starts its own mirrored registry, they should remove their object from RADB. - the existence of duplicates actually is not a new problem, but it will be more difficult to handle if the number of registries explodes? in principle this could be solved by prioritizing registries, which may be difficult thinking of which criteria to use. Therefore, clear criteria must be defined for the "private" registries where to query, and what to store - while prioritization probably solves the question of retrieving data, it does not solve the question of consistency; does the IRR consistency project help here? probably yes, at least as a supportive action; however, getting registry data is also a matter of completeness - who is allowed to open a registry, and who is then allowed to insert, delete, manipulate copies of objects in which registry? in principle, any body may open a registry; however, ownership of objects should not change in this process (AS, route objects). Actually, nobody should be allowed to delete or work on these objects. This may really become a problem if upstream providers decide to set up their own registries, even more for multihomed services. This would require multiple registrations, not necessarily transparent for downstreams. The general feeling was that this development should be very closely observed. - is Merit acting here a bit early with RPS Dist not yet in place? actually, we are currently on the move, starting to develop procedures. It is quite obvious, that someone running a registry being disjoint from the others, the data may not be used for configurations on the Internet, meaning that the corresponding networks will not or will only be reachable partly. This will generate peer pressure to at least mirror each other properly. Nonetheless, at least for small registries, there is a definite need for central support, and most likely also for a resolution authority in cases of dispute. As a general bottom line, it became very much obvious that the Internet is very much differently organized in the US compared to Europe. Much of the problem for Merit is posed by introducing its new funding model, where for RIPE it already exists and is accepted in the community. In the US, the community is much more heterogeneous than in Europe. * Scaling issues Funding is not the only issue, Merit has been working on. The demand of users of the database has risen that much, that scaling has become an issue. The load on the production server has increased that much, that a second one had been introduced, where requests are distributed applying a DNS round robin mechanism. Updates are only done on one machine, requests are handled by both. To handle slow connections, small pipes, or large queries, parts of the software have been adapted to speed up processing. * IRRj A new development is the routing registry tool IRRj, opening another interface to the database. It is programmed in Java, and connection based, in contrast to the usual e-mail interface. It allows fast updates and features a graphical interface, which works more efficiently than updates by e-mail. It is obvious that IRRj can not make use of the "mail from" authentication method, which should be eliminated anyway because it does not supply real authentication (easily forged). The idea is to move to PGP in general. * On the horizon With the projects running and new developments, a list of action items results. Most pressing is an implementation of RPS Dist, allowing distributed databases. Merit is working to get an RPS Dist prototype built which also depends on progress of the corresponding Internet draft. However, it have already been decided that for authentication between the distributed databases, PGP certificates will be used. Another demand from the community is strong authentication/authorization in the database. Accordingly, Merit is considering implementation of the RPS Auth draft. Depending on resources work may commence around mid-summer. Finally, there is some new development on the database software itself. With the help of Global Crossing, a relational database backend is developed, where the TimesTen relational database is used. The work will integrate IRRd in the backend. Resulting code from this project will be open source. The expected advantage of the project consists in higher performance (due to structures intrinsic to the relational database software), allowing relational queries, and better support for the allocation registry functions. D. Routing Information Service Status and Plans (Ripe NCC) Henk Uijterwaal http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/ripe35-ris-h... k/ Details of this report are available at the url specified above. In addition the RIS project has its own web pages at http://www.ripe.net/ripencc/pub-services/np/ris-index.html The goal of RIS is to collect default-free BGP data with timestamps, to give a current and historical view of the Internet routing table. The user interface will have the feel of a looking-glass "with memory". Once deployed, RIS will also be used for consistency checking of the routing registry. The setup consists of major data collectors at major exchange points, which transmit the data to a central collector and database at the RIPE NCC. Since Oct-99 the first test version is in use. However, there are still a few items which need to be taken care of like - open questions in the draft RIS document (RIPE-200) - the hardware for the final setup must still be ordered - consider process of data collection and storage, especially with regard to the high data volume The prototype currently implemented is available at http://abcoude.ripe.net/ris/risalpha.cgi A demonstration was available in the terminal room. The current setup consists of one collector at AMSIX, and one machine for storage and running the database. At AMSIX, currently 12 peering relationships are active. Data volume collected is around 40 MBytes per peer and per day. The total peering relationships are probably going to be increased to around 70. Collected are BGP IPv4 announcements and withdrawals with all BGP attributes. The collector sends updates to the central collector daily - this frequency may be increased in the future. Some results derived so far show - there is a very high number of updates per day, which seems to indicate a high level of instability; however at the same time the number of withdrawals is very low - the more peers we are looking at, the more prefixes are visible which is interesting because we expect that some upper limit of prefixes should be reached relatively fast (the full Internet routing table); since they do not appear on the Internet routing table, these addtl prefixes are called "dark prefixes"; the question is whether this effect results just from more specifics being visible which are otherwise simply aggregated - this statement is supported by the finding that more than 50% of the prefixes are /24 Besides these statistics, RIS will enable to find out who routes what when. On top of this, flap-statistics may be generated. Suggestions on additional usage is very much welcome from the audience. The development is on schedule, a demo is available. Plans are built on the actions indicated above, comprising implementation details, and including more peerings. The basic question in the end how to turn this into a regular service will be answered after these preliminaries are resolved. There was input from the audience, that similar things have already been done in other areas of the world (e.g. a project at Merit). Results and experience will be shared. With these presentations the first slot of the meeting was closed. E. Multicast Routing The second slot of the Routing WG meeting was dedicated to Multicast Routing, more precisely to show how providers have deployed it or are planning to do it. This includes both backbone and Internet service providers, and public exchange points. Not all of the presentations are available yet, but will become available on the RIPE NCC web server soon. * Reports from Backbones There are two prominent pan-European backbone providers: TEN-155 for the education/research community, and the commercial Ebone network. For both the current status, experience, and some plans were presented. The TEN-155 multicast setup was presented by Jan Nowak. Due to the different demands, levels of development, or specific implementations, the network structure is highly heterogeneous. Quite a lot of problems result from this. It was also recognized that some elements of multicast are very sensitive to frame/cell/packet loss (depending on the under lying carrier protocol). In contrast, Peter Lothberg showed that Ebone is using native multicast (avoiding any tunnels), only employing sparse mode, avoiding MHRSP which removes problems like ghosting issues. MSDP is very much favored. The result is a very clearly structured homogeneous network, which is easy to manage and configure. The design includes backup scenarios with redundant RPs to circumvent router failures. * Reports from Public Exchange Points Peter Lothberg immediately continued with his presentation on multicast routing on the Stockholm DGIX. He gave some general design rules, and shared his thoughts and experience. It was interesting to note that DPT rings based on dark fiber are used for both unicast and multicast. Niels den Otter followed with his presentation on the plans, AMSIX has to add multicast (Amsterdam Internet Exchange). They are still in the planning phase. According to Steve Walker, the LINX (London Internet Exchange) is already a step further down the road: even though they are still in the developing phase, they already have a testbed running with several multicast feeds. On the one hand, more multicast feeds are expected, and the LINX wants to switch to production sometime during year 2000. It is interesting to note that both AMSIX and LINX are deploying multicast on separate hardware, keeping it away from their unicast exchange infrastructure. However, on the Stockholm DGIX unicast and multicast are run on a common shared infrastructure. * Reports from Active ISP Networks Originally, there were reports planned from three networks. Unfortunately, Peter Heiligers on very short notice could not join the meeting, and thus the report from DFN was dropped. The two remaining reports from Renater by Bernard Tuy and on Surfnet by Niels den Otter showed the same situation like described for the backbone networks. Renater has started relatively early with the French Multicast Backbone (FMbone), and thus for historical reasons there are still various protocols in use, and the network has been running on dense mode. When the network grew, configuration with all the filters required became just too complex. Therefore, Renater is now moving to sparse mode, and will reduce the number of protocols used in their network. Surfnet has also tested a few protocols, but for final implemenation is adopting a model similar to Ebone, with PIM sparse mode throughout, MSDP with backup RPs etc. The Surfnet multicast backbone will be congruent to the unicast network, using the same routers. Y. General I/O with other WGs There has been no immediate I/O with other WGs. Z. AOB There was no AOB for this working group session. Joachim announced that there will be held a multicast tutorial during the next RIPE meeting in Budapest. --- Agenda ------ R I P E 3 5 A M S T E R D A M Routing Working Group Session 24-February-2000 Draft Agenda A. Preliminaries (Joachim Schmitz) (5min) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 34 minutes - actions from earlier meetings B. Report from the RIPE NCC (JLS Damas) - transition to RPSL (15min) - consistency checking of the IRR (5min) C. Report on the IRR at RADB (Gerald Winters) (20min) D. Report on RIS (RIPE NCC) (20min) E. Multicast Routing - reports from backbones * TEN-155 * Ebone - reports from exchange points (15min each) * Stockholm D-GIX * AMS-IX * LINX - reports from active networks (15min each) * Renater * DFN (skipped) * SURFnet Y. General I/O with Other WGs Z. AOB Summary of open Action Points ----------------------------- 31.R1 on RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR - postponed - 32.R1 on RIPE NCC, JLS.Damas Prepare draft document on issues of RIPE-181 to RPSL transition - in progress - 34.R1 on C.Panigl Provide update to RIPE-178 - in progress - Emil Gorter, Joachim Schmitz, May-2000