RIPE 62

RIPE Meeting: 62

Working Group: Routing

Status: Final

Amsterdam, Wednesday, 5 May 2011, 14:00-15:30

Co-chairs: Rob Evans, Joao Damas

A. Administration

B. IPv6 routing recommendations - Rob Evans, JANET

The presentation is available at:

http://ripe62.ripe.net/presentations/112-ripe62-rtg-agenda.pdf

There were no comments from the room on the IPv6 routing recommendations document, so Rob is going to go forward in making at a RIPE document.

C. Online Testing of BGP - Marco Canini, EPFL

The presentation is available at:

http://ripe62.ripe.net/presentations/118-RIPE_-_Online_Testing_of_BGP.pptx

David Freedman (Claranet) said it is wonderful, and asked if they had interaction with the IETF because the Global Routing Operations Working Group (“GROW”) is working on similar topics.

Marco answered they had not yet.

E. Effect of RPKI development scenarios (work in progress) - Alexandru Stefanescu, NLnet Labs

The presentation is available at:

http://ripe62.ripe.net/presentations/123-ripe62.pdf

No questions from the room on Alexandru's presentation.

Joao encouraged Alexandru to come back to show results from their research.

D. AS-level Multi-Path Routing - Adriana Szekeres, NLnet Labs

The presentation is available at:

http://ripe62.ripe.net/presentations/109-MultiPathRouting.ppt

Wilfried Woeber (Uni Wien/ACOnet) asked what sort of modification in BGP would a node require for packet forwarding to work when the link between two nodes in its forwarding path fail.

Geoff Huston, APNIC, clarified that the presentation says assuming there is a mechanism that allows alternate paths to work in BGP, then what do the updates look like? He added that what Wilfried referred to is that the alternate path mechanisms in BGP really look ropey. Geoff agrees with that, but it's not what the presentation is about.

Blake Willis (L33 Networks) asked if the simulation was on the routing level only, not at the packet forwarding level.

Adriana clarified it was at the AS routing level.

Blake also asked if she was aware about similar work on OSPF and IS-IS.

Adriana answered she was not aware.

F. Certification in the Real World - Alex Band, RIPE NCC

http://ripe62.ripe.net/presentations/102-Cert-RIPE62-RoutingWG.key

After his presentation, Alex Band asked what the proper default for maximum

prefix length in a ROA is.

Ruediger Volk (Deutsche Telecom) said proper default for maximum prefix length is to leave it blank.

Geoff Huston (APNIC) explained why the APNIC RPKI system has a default of allowing up to /128. This is because they assumed the prefix owner was not the same as the route originator, and this would allow for the maximum flexibility for the route originator.

Alex clarified that the problem with the choice the RIPE NCC made is that people don't realise what leaving the field blank is.

James Blessing (Limelight) highlighted that advertising a black hole community for a more specific may not work anymore in the future.

Ruediger Volk found it confusing that the RIPE NCC called a CA implementation “client software”.

Alex said he was right.

Ruediger Volk said up/down should be top priority for the RIPE NCC RPKI team.

Alex responded that it is.

Sandy Murphy (Sparta) said the RPKI goal is for a prefix holder to say who is originating a route to the prefix, and wondered why the web interface started off with picking an AS number.

Alex clarified that it's not about what AS number you are, it is about what AS you authorise to announce your prefixes.

Ruediger Volk said the user interface is limiting, It is not quite clear how many prefixes you can put in a ROA.

Alex responded that the LIR can see all their prefixes if they are logged in.

G. Idealized BGPsec: Formally Verifiable BGP - Randy Bush, Internet Initiative Japan

The presentation is available for download at:

http://ripe62.ripe.net/presentations/100-110504.ripe-bgpsec.pdf

No questions from the room on Randy's presentation.

Z. AOB

Randy mentioned his recent work on route-flap damping, and how it can be made useful if you set parameters in a particular way. He also suggested that the working group might want to work on a revision of ripe-378.