You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
32 |
Working Group: |
Routing |
Status: |
Final |
Revision Number: |
1 |
Please mail comments/suggestions on:
Chair: |
Joachim Schmitz (JS395-RIPE) |
Scribe: |
Roman Karpiuk (RK-RIPE) |
Attenders: |
74 |
Joachim then passed the participants' list around, and asked for a volunteer scribe. Roman Karpiuk volunteered.
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:
As agreed during earlier RIPE meetings tutorials on RPSL will be held. The first one in Europe was done prior to the last RIPE meeting. We now had a second one just before this RIPE meeting on 26-Jan-1999. It was the first one organized and given by the RIPE NCC alone. There were about 60 participants.
The original presentations are available at the ISI web site.
The training effort will be continued. We will have yet another tutorial at RIPE33. For the future, as discussed before, the tutorials will become part of the present LIR courses. The corresponding course with the administrative boundaries is currently developed at the NCC. Plans currently include a separate tutorial day before or after the LIR training, This offers sufficient flexibility for participants to either just take one of the courses (LIR or RPSL, only), or to visit both.
Joachim then thanked the trainers and the RIPE NCC for organizing and holding the tutorial.
While as usual a multitude of topics was discussed Joachim focused on two topics directly related to the work of the Routing Working Group
The RPS Working Group is progressing. There has been some additional work on the rps-auth and rps-dist drafts. A major concern was how the working group itself should proceed because their milestones set originally were achieved. Nonetheless, several new related topics had been discussed (especially the authorization and distribution issues). Accordingly in compliance with the IETF regulations for working groups a set of new milestones has been set up, and the charter is currently reworked.
Besides the usual development of IPv6 related Internet drafts and standards most notable probably at this time is draft-ietf-ipngwg-iana-tla-00.txt. This draft describes a proposal of how to distribute TLA space to the address registries. According to the proposal the sub-TLA space 0x00c0-0x00ff is suggested to be given to RIPE.
With address space now beginning to be distributed, ESnet started an initiative called 6REN which is a native IPv6 Research and Educational network meant for production. Info is available from their web site at http://6ren.net/. David Kessens mentioned that a presentation on 6REN will be given at the IPv6 Working Group session.
David outlined the RPSL transition process consisting of three phases. Phase 1 of the basic software development has been done. Phase 2 consisting of additional code developemtn, testing, education, real time mirrors, and implementation of an RPSL update path for autnum objects are more or less done. Phase 3 as final switch over is yet to come.
Looking at Phase 2 in more detail David listed the resources available at ISI, namely the RAToolSet, the running RIPE database with RPSL extensions, and the converter software for RIPE-181 objects to RPSL objects. David then acknowledged the IRRd development at Merit, which takes advantage of the new RPSL features. On the educational side they held tutorials
June 98 |
NANOG Detroit |
Sep 98 |
RIPE31 Edinburgh |
Jan 99 |
RIPE32 Amsterdam (RIPE NCC) |
Mar 99 |
APNIC/APRICOT Singapore (planned) |
May 99 |
RIPE33 Vienna (RIPE NCC, planned) |
David's conclusion then was that the world is ready for Phase 3 where any incoming RIPE-181 object is automatically translated into RPSL, and RPSL is used throughout. An RPSL server is available, mirror servers are running at participants' sites, and potential participants are waiting (CONNECT in Australia already configures their routers with the RPSL capable RAToolSet).
Accordingly, at the IETF meeting in Orlando, a session was held to discuss transition. Participants came from ANS, C&W (former MCI), RA (Merit), Telstra, Qwest, ARIN (they will start a routing registry of their own during February), APNIC, RIPE NCC, Connect. Among those it was agreed that all of them make their RPSL data files available for mutual download at 15-Feb-99 to present all registered routing data easily. The next meeting is planned for the IETF meeting at Minneapolis in March, where a final confirmation is meant to be achieved whether all parties are ready for RPSL and when they will switch over.
RIPE NCC is in Phase 2 of the transition process, having a mirror server running for 10 months already, and having started to give tutorials. RPSL data files available on the ftp site:
ftp://ftp.ripe.net/ripe/dbase/rpsl
containing autnums, routes, communities (route-#sets) and as-macros (as-#sets). Input is needed from potential users on how they use it and where they see problems.
The RIPE NCC will not support RPSL fully until the new database code (of reimplementation) is in production. This extends the period for people who need to switch over, probably adapt scripts, etc until Dec-99, meaning that the RIPE NCC will maintain backward compatibility. After the transition only the RPSL files will be published, and the RIPE-181 files will no longer be available. This may occur already during 1999 for other registries (possibly C&W, ANS) which perform an earlier switch over.
There was some discussion on this topic, especially when the new syntax will become available to RIPE database users. Joao explained that the production database will only accept RIPE-181 format, while the mirror has the RPSL translated format. A complete write is only possible to the production database using RIPE-181 format. Nonetheless, there is an update path for autnum objects in the RPSL mirror database (but not for other objects).
Any update to the RIPE-181 database will be reflected in the RPSL database - except in the case that a mirrored autnum object has been updated in the RPSL mirror using RPSL syntax. In this specific case, the RIPE-181 autnum object will not overwrite the RPSL autnum object. However, the RPSL autnum object will not be reflected in the RIPE-181 production database because RPSL is a superset of RIPE-181. The RPSL mirror is not considered production by the RIPE NCC.
This raised the question of how the transition to RPSL should occur. i.e. whether the old RIPE-181 objects or the new RPSL autnum objects should be used in the new upcoming RPSL database. Joao suggested to decide on this during the next RIPE meeting.
Action (RIPE NCC, JLS Damas): Write-up draft document about transition issues of RIPE-181 to RPSL.
Joachim added that reimplementation of the RIPE database software has higher priority than moving to RPSL. RPSL will be natively supported in the new software meaning that RPSL transition and software reimplementation are coupled together.
Merit has established a measurement infrastructure with probe machines at many Internet Exchange points in US (Mae-East/West, Paix, PacBell, AADs). They collect default-free part of global routing table at the University of Michigan via EBGP multihop configurations. They have gathered data for the last 4 years. The tool used is called Route Tracker. Based on peering with ISP routers it logs all routing information over time to disk and generates statistics.
Then, Abha gave a review of previously observed pathological routing observations. Actually, most route updates had been pathological (millions per day) with a disproportionate impact caused by small ISPs. These updates consisted of duplicate announcements, duplicate withdrawals, or private networks announcements. Most of it was caused by router software bugs (errors in implementing the BGP algorithm), and BGP misconfigurations. Many of those pathological updates have been fixed over time. As of August 1998 number of announcements exceeded number of withdrawals. Improvements are also visible in the frequency analysis of updates, where the 30 seconds component has been decreasing a lot.
As a new topic, Merit has been looking in more detail at Internet failures. They analyzed longlived default free BGP announcements for multiple large providers and found that the Internet is significantly less available than telephony: 60% of the routes show availability below 99% where availability is defined as percentage of the time a route was present in the routing table, compared to the elapsed time. This covers all NLRIs meaning real reachability. At the same time the MTTR (mean time to repair) analysis showed that 80% of the problems were solved in less than 2 hours.
Discussing failures with the participating ISPs showed that the three main reasons for network failures were
As next steps in their analysis programs, Merit is now
The RIPE database is used for:
Data stored in the RIPE database may be distinguished in
Joachim also showed that domain objects registered are at best incomplete because RIPE is no domain registry. In addition, person and role objects are definitely an uncertain area where accuracy is impossible to fathom.
Looking at routing policies and routes, it is found that there is no obligation to register them in the registry (except since some time a basic routing policy is requested intially from the RIPE NCC when distributing AS numbers). It is at least questionable whether these objects are uptodate.
The question is whether we as the Internet community care at all. Actually, disregarding internal networks and private peering, routing information on the Internet is essentially public (traceroute, looking glass...). It must be public because otherwise networks would not be reachable. Rüdiger Volk had objections and felt that the full policy of an ISP is not public. Nobody could figure out his full configurations from traceroute and such tools. As an example many networks are multihomed and still competing routes are not announced. Much of the routing information cannot be derived from just observing the life system.
Joachim agreed to a certain point, e.g. for private agreements and peering among neighboring ISPs, or from the fact that certain BGP parameters do not propagate beyond the nearest peering neighbor. Nonetheless, at least the basics of routing policies must be publicly known because otherwise networks would not be reachable on the Internet.
Publishing the routing policy and routes helps debugging. If things go wrong the IRR is a perfect reference as long as data are properly registered. Then, it may also be used for building configurations.
Even though in general nobody is obliged to register routes and policies, many big providers demand that their peers properly register. This information is then actually used to install filters at least on the boundary routers.
Obviously, there is a benefit in checking the accuracy and completeness of routing information in the Routing Registry. The best way to check probably is
With tools available, the question arises who should check. In principle, everybody could do it on its own. This should definitely be encouraged but there should also be more. Joachim actually proposes these checks as a service by the RIPE NCC because it
There was consensus on the usefulness of the project proposal. Joao Damas told that the current RIPE NCC Activity Plan for 1999 includes a Routing Information Project and the Database Consistency Project besides others. The new project should take this into account.
Action (Joachim Schmitz): Write up the project proposal on reality checking of the RR, and submit it to the RIPE NCC.
Cooperation between Routing WG and MBone WG (Kurt Kayser)?
Kurt Kayser as chairman of the MBone Working Group reported about the latest (in)activities of the WG. No topics for discussions for the WG session at RIPE32 were proposed on the mailing list. Reasons for this may be
There was some discussion and input from the members of the MBone WG. Joachim and others pointed out that multicast routing at this time is pretty stable, and as a routing topic it should be possible to discuss issues around it for ISPs and the LIR area in Europe.
Rüdiger Volk thinks that it looks a bit suspicious that there is no feedback during the migration period from old technologies to BGP based multicast routing. It seems as if there is no demand from the RIPE community. Rüdiger then asked who is really using MBone seriously for production or commercial use. There were a few like Brent Frere who said that 90% of their business runs on IP multicast. However, most of the activity seems to be still in the research network domain.
Further questions revealed that half of the particpants in this session are using multicast routing in their network (enabled on their routers), while only a minority is running dvrmp or mrouted.
Since there were no requests to keep the MBone WG separate, it was merged into the Routing WG. Wolfgang Nair made clear that he understands it as a merger, and if there is enough demand, it will be split again. There was general consensus on this approach.
Bernard Tuy said that there is not much traffic on the MBone mailing list. There are other related mailing lists, e.g. at ISI. Nonetheless, general feeling was that the MBone mailing list is still useful, and it will be kept. In addition, the web page with the contact list will still be maintained by Kurt Kayser, who will also give an overview of MBone activities in the Routing WG from now on.
There was no other input from other WGs, or output to them.
- Routing Working Group Meeting -
Agenda for RIPE 32, January 1999, Amsterdam
Roman Karpiuk, Joachim Schmitz
4-March-1999