Dear colleagues, please find below the draft minutes of the Routing WG session at RIPE 36 in Budapest. My thanks go to Marek Bukowy of the NCC for taking the minutes. As usual, comments, additions, corrections very much welcome. Thanks Joachim --- JS395-RIPE -- standard disclaimer --- R I P E 3 6 B U D A P E S T Routing Working Group Session 17-May-2000 Draft Minutes chair: Joachim Schmitz (JS395-RIPE) scribe: Marek Bukowy, RIPE NCC 70 participants A. Preliminaries Due to some cancellations, less time was needed than originally anticipated, and the first slot was not used, freeing up space for other Working Groups (LIR overflow ;-) and reducing overlap with parallel sessions. The shortened agenda then looked like: A. Preliminaries B. Update to RIPE-178 (Christian Panigl) C. Tnsition to RPSL (Andrei Robachevski, Joao Luis Silva Damas) D. RIS, Status and Plans (Antony Antony, Henk Uijterwaal) Y. General I/O with Other WGs Z. AOB Joachim welcomed the participants, passed around the participants' list, and asked for a volunteer scribe. Marek Bukowy volunteered to take the minutes. There were no objections to the minutes of the RIPE 35 Routing WG circulated just prior to the meeting. Joachim apologized for the very late distribution and announced a period of one week after the meeting to allow for possible amendments or changes to the minutes. In that time there was one addition, but otherwise, the minutes were accepted. Then the status of 3 old action points was reviewed: o 31.R1 RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR -postponed- This action is sitting around for quite some time without much progress. To give this a chance to continue, we considere to define a project out of this and make it part of the NCC activity plan o 32.R1 RIPE NCC, JLS.Damas Prepare draft document on RIPE-181 -> RPSL transition issues -in progress- The draft document is still being worked on, but not yet publicly available, even though done for the most part. A presentation during this WG session will provide an update o 34.R1 C.Panigl Provide updates to RIPE-178 -to be closed- This is ready to be published as a RIPE document. Details will be presented by Christian Panigl during this WG session Before starting with the individual reports, Joachim gave a short overview of the full day Multicast Routing Tutorial which had been held on the previous day. There were 30 participants, who were not only following the presentations, but encouraged by the great way of presentation, also discussed quite a lot of issues around multicast routing. The thanks go to Stefano Previdi of Cisco, who took the work on him to present and discuss this topic at the RIPE meeting. For those interested in reading back on the slides, look at ftp://ftpeng.cisco.com/ipmulticast. B. Update to RIPE-178 (Christian Panigl) The document was updated and will be assigned a new number. Changes can be summarised as follows: - access-list has been changed to prefix-list (supported in IOS for quite some time now) - list of root nameserver networks has been updated - recommendations have been added to combine no bgp fast-external-fallover with per-neighbor keep-alive for networks that need faster convergence than available through default bgp timeout - there also was a hint about BGP route refresh capability a.k.a. triggered soft which is part of a set of enhancements (IOS 12.0.7 T&S) * Discussion A question was asked why "golden networks" which are recommended to be excluded from route flap damping, are still needed, and why DNS fallover to secondary nameservers was considered insufficient renundancy. The answer is, that at least in Europe, many ISPs still have only one upstream link. In such a case, if this network's border router operates with flap damping enabled, route flapping caused by instability up the stream prevents the network from accessing the whole Internet, including all root server networks. C. Transition to RPSL (Andrei Robachevsky, RIPE NCC) The presentation is available from: http://www.ripe.net/ripe/meetings/archive/ripe-36/index.html The history of the project was presented starting 1998, going together with a complete reimplementation of the database software. Motivation included performance enhancement, new functionality and maintainability. A decision was taken to do a full rewrite after modifying the old code to support the referral mechanism and referential integrity. The Alpha version has been online since 31 Dec 1999. Next beta version including almost all queries, NRTM server (Near-real-time mirroring, using the old protocol but serving RPSL objects) is online since 12 May 2000. It is kept up to date with the primary whois database by means of NRTM. The development is still focused on adding functionality. Portability issues are not yet addressed; currently the development environment is Solaris 6 and 7 on Sparc/intel and Mysql as the backend. Next steps are documentation, testing and porting. General differences between RPSL and ripe-181 were briefly discussed. Some RPSL modifications will affect all objects, not only routing-related. Those changes include: - line continuation - preservation of the line order and - invalidity of empty attributes In the data migration process, a remarks line "This object is automatically converted from the RIPE181 registry" will be added to all routing registry objects transferred from the current RIPE database. Some features of RPSL with regard to the routing registry specific objects were presented (route, autnum, as-set). Regarding the related implementation of rps-auth, several issues were discussed on how to use member-of and member-by-ref in as-sets and autnum objects, together with which update paths are included, and the "bilateral" nature of the member specification. Members-by-ref of the as-set specifies the mntners which are allowed to claim membership of an autnum object by listing the as-set name in the member-of attribute of the aut-num object. The old style specification using "members" is still valid, but no searches on this attribute are possible, rendering it nearly equivalent to a "remarks" line. A comment was made that the irrd has such searches for RADB and this should also be the case in RIPE. This discussion in conjunction with other items discussed later on led to an action on the NCC (see below) The same membership specification applies to route-set (present as community in ripe-181). Both sides must specify/allow membership, otherwise it is not effective. An update of an aut-num object with member-of attribute will be rejected if the as-set does not allow this membership. Two attributes of the mntner object enable control over mntner objects that are outdated and forgotten: referral-by - pointing to the maintainer that created the mntner, and auth-override - allowing deletion of the slack mntner by the mntner listed in the referral-by attribute. New query switches were also presented, which were implemented to enable all queries needed by RAtoolset: general: -q version - displays version of the server -q sources - displays available sources as well as expansions of the collection of switches devoted to address space related objects: -l one level less specific lookup -l / -L / -m / -M also available for in-addr domains now -x exact match only (default is exact or less specific) A request for active beta testing was expressed towards the community. Query functionality of the new software can be tested with an instance of the database holding real data, available at reimp.ripe.net port 43 (where peering sets and route sets could not yet be queried at the time the presentation was given). Updates in RPSL can be sent to a new test database at auto-rip@ripe.net. This database can be queried at reimp.ripe.net port 4343. The PGP authentication is not functional as of yet, though. Phase II of the transition will start end of June 2000 (current schedule), Phase III depends on testing and consensus on the final transition. * Discussion A question was asked from the audience if the database software was going to support the domain objects which are not defined by RPSL, and so could be used by ccTLDs. The answer to this was positive. Another question was asked if the irrd-style query commands (!commands) for expansion were going to be provided. This started a short discussion: while the syntax is not (yet) supported, the functionality of these commands was already provided. A quick show of hands showed that about 4 people from the audience used this irrd functionality. Consequently, it was felt to be a low priority issue for the moment. A suggestion was made to intensify cooperation with Merit on testing the new software using the test suites that Merit used during the transition to RPSL. An interoperability issue was raised. It was felt that it is essential to ensure compatibility on the user-object level with irrd and whois, so that the RIPE database could be used as an NRTM client of irrd or a server for irrd in order to be able to accomodate all databases in a single whois server. It was suggested to do that with filters if no other way was possible. Nonetheless the highest possible level of interoperability shall be maintained. o 36.R1 on the RIPE NCC During the transition phase to the RPSL software - verify with RADB on their test suites for testing RPSL implementations - coordinate with RADB on consistent mirroring of databases (NRTM) - coordinate with RADB on consistent whois interface of databases including irrd Part of this work is covered by the rps-dist effort, but the Routing WG explicitely asks RIPE NCC and Merit (RADB) to work closely together here to guarantee interoperability, because rps-dist is not yet mature. D. RIS, Status and Plans (Antony Antony, RIPE NCC) presentation available at http://www.ripe.net/ripencc/pub-services/np/Talks/0005_RIPE36/ Major topics of the presentation were * introduction * progress since RIPE35 * explanation current setup * observations made * plans which are comprised below * introduction Goal of RIS: to store the history of inter-as routing information and make this history queryable for the good of the community. It will also be a foundation for the reality check project of the routing registry and trend analysis. The queries will allow viewing of a routing table at a specific point in time as well as viewing of the changes observed during specified periods of time. This is achieved by collecting BGP data available to the project participants at different points of the internet and storing at the RIPE NCC. New developments in the project since RIPE35 were presented: - increase of the number of peers to 13 - web interface available at http://abcoude.ripe.net/ris/risalpha.cgi * Discussion A suggestion was made that a command line interface would be useful for scripts. It was explained that lots of information needs to be transferred to the program as arguments, infeasible to do by hand, but technically not a problem, because this is actually what is more or less behind the web interface. It was suggested that a perl library could be useful. This issue will be considered in more detail by the NCC. A question on software availablility was asked. It was explained, that the software consists of 3 components: - BGP listener (MRT/Zebra) - available in public domain - tool to insert the data into the database - written by NCC - query engine - written by NCC The components developed by NCC are not publicly available at the moment, but this may change. Following these questions, some remaining open questions were presented: - investigation on hardware/software needed (scalability problems) - decision on how long keep in the database (current plan for 3 months) - how often should the dumps occur (now 3/day) - how this should be turned into a regular service It is estimated that for most of these questions answers will be found from the experience during the current alpha phase, and later beta. * observations made 'dark prefixes' still exist (difference between the union of all prefixes available at all peers and the set of prefixes available to particular peers, indicating fragments of the internet unavailable to the peers) 25.4 % of the IPv4 address space is currently announced and can be seen by at least one RIS peer. 25.36% can be seen at NCC (equivalent of 19 /16s missing w.r.t the union seen by RIS.) 25.32% can be seen at CERN (53 /16s missing) (overlaps have been eliminated) No trend can be observed so far, the instabilities are more of the random nature and are sometimes high, like a /8 unavailable at the NCC for a whole day. The decrease on the graph of the number of prefixes can be explained by about 8000 /30s observed before RIPE35 that were internal routes of one of the RIS peers and have been withdrawn. * Discussion: These preliminary results triggered the question if there was a distinction between announcements from the peers, meaning routes this peer tells to any Internet peers, or the backbone routes, or those for their customers. So far no consistency was enforced in requesting the peering policy from RIS peers. Hence some differences in the set of prefixes covered can appear. Without the consistency, the results are not really comparable. It is obvious that such a policy should be developed. This is considered to be part of RIS, but also input from the community is required here. Since the policies themselves were not going to be public and practically no traffic was being sent from the RIS peers, it was pointed out that the NCC should have no problems requesting RIS peers to peer with the RRC boxes following specific policy guidelines. NCC will come up with a suggested policy. User feedback on usefulness and suggestions for functionality was requested. An example on the propagation of the announcement of the meetings' prefix on the Internet was presented by Daniel Karrenberg, giving an impression of what can already be done today with the alpha version of RIS. It was stressed that the tool provides an integrated view eliminating the need to consult multiple looking-glasses. * project plans were subsequently summarised: - 2 more RRC's (Remote Route Collectors) in Europe - solve scalability problems of the BGP listener - answer open questions on usability - examine observed effects closely Y. General I/O with Other WGs Besides progress report on the database reimplementation and corresponding issues, which will be presented at the Database WG session, no other I/O happened with other WGs. Z. Any Other Business No other issues turned up and thus no other business was discussed. 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 - closed - 36.R1 on RIPE NCC During the transition phase to the RPSL software - verify with RADB on their test suites for testing RPSL implementations - coordinate with RADB on consistent mirroring of databases (NRTM) - coordinate with RADB on consistent whois interface of databases including irrd Marek Bukowy, Joachim Schmitz, July 2000 -----