RIPE 32

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

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

The RIPE database is used for:

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

Data stored in the RIPE database may be distinguished in

• allocation data
• routing data
• both

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

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

• 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

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

• 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

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

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

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.