Routing WG minutes from RIPE 32

Please mail comments/suggestions on:

• content to the Chair of the working group.
  
• format to webmaster@ripe.net.

Report of Meeting, 27th January 1999

A. Preliminaries (Joachim Schmitz)

Joachim welcomed participants and discussed TCP "slow start" feature (session started at 9:15) because of ongoing registration of RIPE meeting visitors.

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:

29.R1 G.Winters, J.Schmitz, RIPE NCC

Definition of the IRR and an AUP
-in progress-
There was a presentation on this topic during RIPE31. Work is ongoing. Action still open.

29.R3 RIPE NCC, JLS.Damas

Implementation of PGP in the RR
-done-
Report will be given in the Database Working Group session. Documentation is already available in the RIPE-189 document

31.R1 RIPE NCC, D.Kessens, J.Schmitz

Basic Design for an IPv6 IRR
-open-
Work ongoing.

B. Recent Developments (Joachim Schmitz)

• RPSL Tutorial Report (Joachim)

  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.

• Report from 43rd IETF Meeting in Orlando (Joachim)

  While as usual a multitude of topics was discussed Joachim focused on two topics directly related to the work of the Routing Working Group

  • RPS

    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.

  • IPv6 development

    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.
    

C. Report on RPSL Deployment at the Registries

• General Overview (David Kessens)

  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)

  
  If there are suggestions for additional tutorials, David welcomes them.

  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 (Joao Luis Silva Damas)

  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.
  

D. Report from the RIPE NCC (Joao Luis Silva Damas)

This agenda point was skipped. The report will be given on the Database WG session. Slides are available as NCC report and RPSL update.

E. Observations in Internet Routing (Abha Ahuja, Craig Labovitz)

Abha gave the presentation about stability and measurements of Internet routing (IPMA project at Merit) as followup on Craig's earlier reports on Internet stability.

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

• Maintenance related
• Power outages
• Fiber cuts

Interesting enough, most of them were not related to router problems.

As next steps in their analysis programs, Merit is now

• looking for more peers in the US and in Europe
• trying to find supporters for hosting route view machines in Europe

Merit has FreeBSD desktop boxes to give away for this purpose. More information is available from ipma-support@merit.edu.

F. Reality Checking of the RIPE Routing Registry (Joachim Schmitz)

As seen in the previous presentation there are ways of measuring the quality of Internet Routing. Do we have means to measure the quality of data in the Routing Registry, too?

The RIPE database is used for:

• documentation (IP addres allocation)
• reference (contact information)
• configuration (routes and AS filter information)
  

Data submission is either mandatory or optional depending on data type. A database only makes sense when data is correct and up to date.

Data stored in the RIPE database may be distinguished in

• allocation data
• routing data
• both
  

Joachim then looked at the various objects in the database and found that for controlled resources the data quality is good, namely for IP address allocation (inetnum), AS number allocation, and most likely the corresponding maintainers which are mandatory at RIPE for inetnum and autnum objects. Christian Panigl pointed out that inetnum objects do not only contain allocation data but also assignments which are probably not that well documented.

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

• read internet routing table
• look at announcements/accept lists from registered policies
• compare both
  

Items which may be checked then are

• routes
  • aggregation
  • origin
  • flap statistics (not in the RR)
    
• autnums
  • AS paths
  • and more (BGP announcements, communities)
    

To this end already a number of tools exists:

• CIDR report on aggregation. There might be legitimate reasons why under certain circumstances routes are not fully aggregated (even though this is discouraged)
• RAToolSet (roe, aoe, RtConfig)
• PAIR - Policy Analysis of Internet Routing. This requires RSNG (Route Servers Next Generation) though which is not deployed in Europe yet
  

There are probably even more tools which might be used.

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

• already maintains European Routing Registry
• already provides a number of services
• is an independent organisation
  

Accordingly, a project is proposed with the following steps:

• investigate about
  • route server vs. plain router
  • check need for own developments
  • access to routing information
  • scope of reality checks with respect to policies
    
• develop parts as needed
• install system and programs
• offer as a service
  • on demand
  • on a regular basis as periodical report
    
  
  

There was quite some input from the audience on this presentation. Rüdiger Volk asked what the idea behind this proposal was: to help people who care, or to put pressure on those who do not care to fix their data or configuration? Joachim made clear that he does not want to force people into something they do not want, but due to the benefits the Routing Registry offers to the community it is best for all to properly register the public parts of their routing policy.
Actually, big ISPs (especially those running backbones) still demand from their peers that the routing policies are registered. These ISPs use the RR to configure their routers. Anybody not registering will therefore not be reachable or supported by those big providers. There was some discussion on whether this is still valid, but general feeling and information confirmed this practice.
Jake Khuon mentioned statistics from Merit show that approximately

• 50% of the routes in the RR were actually announced, and about
• 80% of those were uptodate.
  

Francis Dupont indicated that with IPv6 the situation will be different because IPv6 has an internal topology built in. While this is definitely true, the discussion was on the IPv4 RR only.

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.

Y. General I/O with Other WG

After the coffee break a final topic was discussed which had just emerged before this RIPE meeting.

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 are no MBONE related problems
• people don't use MBONE
• they don't care
  

Therefore, the proposal was put forward to merge the MBone WG into the Routing WG. Joachim Schmitz as chairman of the Routing WG does not have objections.

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.

Z. AOB

The solutions of the excercises from the RPSL tutorial were circulated. Since there were no additional comments or issues, Joachim closed the WG session.

Agenda

- Routing Working Group Meeting -

Agenda for RIPE 32, January 1999, Amsterdam

A. Preliminaries (Joachim Schmitz)

• introduction
• participants' list
• volunteering of scribe
• agenda bashing
• RIPE 31 minutes
• actions from earlier meetings

B. Recent Developments (Joachim Schmitz)

• RPSL tutorial
• IETF

C. Report on RPSL Deployment at the Registries

• General Overview (David Kessens)
• RIPE NCC (Joao Luis Silva Damas)

D. Report from the RIPE NCC (Joao Luis Silva Damas)

E. Observations in Internet Routing (Abha Ahuja, Craig Labovitz)

F. Reality Checking of the RIPE Routing Registry (Joachim Schmitz)

Y. General I/O with Other WGs

• Cooperation between Routing WG and MBone WG (Kurt Kayser)

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

Roman Karpiuk, Joachim Schmitz
4-March-1999