RIPE 61

RIPE Meeting: 61

Working Group: Routing

Status: Draft Revision Number: 1

Rome, 17 November 2010, 14:00 15:30
Co-chairs: Rob Evans, Joao Damas

A. Administrative Matters

The minutes from the RIPE 60 meeting were approved.

B. Incident Analysis with RIPE NCC Tools

Erik Romijn (RIPE NCC) presented on Incident Analysis with RIPE NCC Tools. The presentation is available at:
http://ripe61.ripe.net/presentations/214-ripe61_linx71_incident_analysis_pdf.pdf

Randy Bush (IIJ) clarified that the RIS/Duke BGP incident didn't affect IPv6, because the new BGP attribute wasn't announced on IPv6 BGP-sessions.

Randy also thanked the RIPE NCC for saying sorry, and said you're not going to be able to anticipate what happens in events like this, but being able to react is critical.

Rudiger Volk (Deutsche Telekom) said that what we see is broken BGP and we have to live with that. The next step would be to rethink the BGP standard, to handle situations in a more resilient way.

Rudiger continued that it's important to get advance notice for experiments. Rudiger expected that for some operators the impact was worse then what showed up in the statistics Erik presented.

Daniel Karrenberg (RIPE NCC) mentioned that for the RIS/Duke experiment components were tested in the lab, and asked Erik to describe the test-setup.

Erik described how the patch to Quagga was tested in the lab and the output packets were verified. Erik mentioned that the lab didn't have an IOS XR device.

Randy said that you couldn't have everything in your lab. You never catch bugs until it's in the real net, since there is no bug-free routing code.

Dave Wilson (HEAnet) said that while the network was quite severely affected by the RIS/Duke experiment, he'd like people to continue this type of work. He was relieved to see this was encountered first when it was done by a well-known and neutral entity that was willing to mitigate quickly and document thoroughly afterwards. He wanted to be assured that experimentation like this happens in the future, after which the audience applauded.

Nick Hilliard (INEX) thought that this experiment makes a very strong case to ask vendors to provide virtualised router images. If that had been done and Cisco had a virtualised platform available for end users, the RIS/Duke BGP incident wouldn't have happened.

Joao Damas (chair) summarised that it's clear the RIPE NCC has learned some lessons and that he hoped the router vendors also learned to not just produce a patch but also integrate these into future testing environments for new releases. He said that overall, this experiment has resulted in an improved Internet, and the whole Working Group expressed support for this work.

C. Exploiting Router Programmability to Ease Routing and Traffic Analysis

Maurizio Pizzonia (Roma Tre University) presented on Exploiting Router Programmability to Ease Routing and Traffic Analysis. The presentation is available at:
http://ripe61.ripe.net/presentations/180-2010-11-17_ripe_rome_traffic_matrix_beyond_the_best.pdf

Lorenzo Colliti (Google) was intrigued by the performance characteristics of the next hop counting and wanted to know if it would scale, because if it would do a linear scan, it's impossible because it requires bandwidth that's not available commercially currently.

Maurizio answered that they asked Juniper and they said that it could be possible, although unusual, but it would have to be tested. His next step will be to test with real loads.

D. W(h)ither RPSL

Nick Hilliard (INEX) presented on RSPL. The presentation is available at:
http://ripe61.ripe.net/presentations/231-228-inex-ripe-rome-routingwg-whitherrpsl-2010-11-17.pdf

Nick requested input from the audience on the ideas he presented.

Shane Kerr (ISC) thought there is a lot to improve upon the current RPSL standard. Shane proposes to simplify the language at the same time as expanding it, and mentioned these don't have to be at odds. Shane mentioned additional things to look at are looking at how RPSL fits into the overall process. Shane commented that the using a research environment for looking at RPSL is good for exploring new ideas, but may not be a good idea for production quality and maintainable software.

Nick responded the RFCs are pretty grim and he agreed on the comment on research projects. Nick thought the operator community is too busy to look at this themselves, so it makes sense to have a third party look at this.

Joao asked if Shane was volunteering for this, but Shane didn't make that commitment.

Daniel Karrenberg (RIPE NCC and co-author of RPSL specification) clarified the history of the specification and his role in trying to keep the specification clean. Daniel thought he had failed that task, because of time constraints. Daniel agreed with the sentiment to discard the current specification. Daniel would like to make a distinction between two purposes for RPSL:
1. Configuring a system of routers, eg. an AS, instead of the current norm of configuring individual routers
2. Coordination with other ASes.

Daniel suspected a single tool for both purposes might not be what we want.

Daniel thought engaging academia in this discussion would be really good and invited people to think about the role the RIPE NCC could play in that.

Dave Wilson (HEAnet) reported on his attempts to use RPSL in virtualisation, and from that experience agrees with Daniel that the current RPSL falls between the two purposes that Daniel described: It is capable of doing both, but in practice not the right tool for either. Dave was not sure yet about separating the two purposes, because he didn't want to see a future where there is some interface in between the description of what networks look internally and what is in the RIPE database.

Andrei Robachevsky (RIPE NCC) said that RPSL doesn't solve the documentation-part of the problem too well, but the network configuration part is not that difficult, according to the network operators he asked about it.

Andrei thought this points towards making RPSL simpler and for the parts that are used in network configuration focus on making it machine-parsable.

Randy Bush (IIJ) polled the room for how many people configure their routers without touching them with a keyboard, in a multi-vendor network, and found one person.

Randy explained he has been doing that too for over 15 years. Randy pointed out that his router configs are built from internal data that, for business reasons, will never ever end up in the RIPE database. Randy thought separating internal and external data is crucial, and pointed out that the two things he thinks the operator community need from the RIPE database are the things that the community wishes and is willing to share with each other, and the things that attest to ownership of resources.

Rudiger Volk (Deutsche Telekom) emphasised it is important to find the subset of functionality that is actually used and supporting that. Rudiger agreed on the split between public and private data Randy mentioned, but thought that doing the full configuration out of policy defined in RPSL seems little used and hard to maintain. Rudiger expected things to migrate into RPKI, although authorisation is not done well yet, and also mentioned RPSL has RPSS, which is not state of the art.

Daniel agreed mostly with Randy, except for the part where not being able to publish your routing policy, makes a publication mechanism for inter AS coordination not useful. Daniel thought exploring what things can be published to manage inter AS complexity is useful.

Joao said it would be nice to have a way to check that what you see, is what the person intended to have you see.

E. Route Flap Damping Considered Useable

Randy Bush (IIJ) presented on Route Flap Damping:
http://ripe61.ripe.net/presentations/222-101117.ripe-rfd.pdf

Geoff Huston (APNIC) mentioned it would be nice to know what the final answer is (in case of prefix instability), to which Randy replied that MRAI attempts to do that, but doesn't succeed because it's poorly implemented.

Geoff mentioned that he sees around 19k prefixes a day that typically deliver 100% of BGP updates, and this instability is tightly coupled with time.

Randy objected that he only sometimes saw this coupling with time, and concluded there is work to do here, to which Geoff agreed.

F. BGP Decision Statistics a First Experiment

Randy Bush (IIJ) presented on BGP Decision Statistics: http://ripe61.ripe.net/presentations/221-101117.ripe-statistics.pdf

There were no questions (session was already over time).

Z. A.O.B.

Nobody had any items for A.O.B. and the chairs closed the session.