RIPE 63

Routing WG RIPE 63, 2 November 2011 14:00
WG Chairs: Joao Damas, Rob Evans
Scribe: Emile Aben
Chat: Robert Kisteleki

Status: Draft

A. Introduction

Joao Damas did a last call for IPv6 routing recommendations, and after no comments were received asked the RIPE NCC to publish the IPv6 routing recommendations document.

Joao Damas reminded attendees of how there was an ongoing last call on IPv6 routing recommendations that was closing today (the day of the meeting) and asked if anyone had any further comments. After no comments were received asked the RIPE NCC to publish the IPv6 routing recommendations document.

Daniel Karrenberg (RIPE NCC) asked to touch upon routing beacon address assignment in AOB.

B. The Flat World of BGP - Geoff Huston

The presentation is available at:
http://ripe63.ripe.net/presentations/61-2011-10-31-bgp2011.pdf

Andy Davidson (Hurricane Electric) suggested the effects Geoff presented are due to the prevalence of networks to peer, because people who peer more widely are enjoying the lowest convergence times.

Geoff responded that work was done in this area at UCLA that compared number of updates against the position on the peering table and found that the lower you are in the pecking order, the more updates you receive. The idea to connect as quickly as you can to the core of the network, the more you are doing yourself a favour and oddly enough the rest of the network as well.

Nick Hilliard (INEX) expressed his concerns about routing scalability.Geoff's work didn't take into account that an IPv6 prefix will take up four times the amount of lookup space then an IPv4, and also ignored iBGP and VPNs. The conventional wisdom is that one million prefixes, which is the standard size for large-scale routers today, are not really sufficient any longer.Once one goes beyond this one million, it becomes expensive and difficult to get to the next stage, which will last you for only a few more years.

Geoff responded that an engine that could process all BGP updates in 2004, still copes today. Preliminary results from a major carrier'sinternal iBGP also showed a relatively flat profile of updates overtime. The system doesn't look to be out of control.

C. "Control BGP From Your Applications" - Thomas Mangin

The presentation is available at:
http://ripe63.ripe.net/presentations/37-RIPE_63_-_Mangin_-_BGP.pdf

There were no questions.

E. Impact of the Tohoku Earthquake on Japanese ISPs - Randy Bush

The presentation is available at:
http://ripe63.ripe.net/presentations/128-111102.ripe-quake.pdf

Immo Wehrenberg (RRBone) asked for the difference between the MPLS and real IPv6 network.

Randy responded it was not them, but a neighbour network and this was because with MPLS they didn't have routing, they had circuits.

Immo asked if he looked at latencies and noticed failover times.

Randy responded that in the Sendai case the circuits were dead, and for the others he didn't look at detailed changes in latency.

F."Measuring the CPU Load of BGPSEC" -- Randy Bush

The presentation is available at:
http://ripe63.ripe.net/presentations/127-111102.ripe-crypto-cost.pdf

James Blessing (Limelight) commented their network is quite a bit bigger than the examples presented. He expressed that the presented calculations wouldn't work for his network.

Randy responded that he would like to have data from this type of network.

He also expressed that BGPSEC is something that is not deploying this year, but, say, five years from now. What the work presented suggests is that it is not going to be easy, but it's feasible, while people thought it was impossible.

James also asked if signing with IPv6 would take approximately the same amount of time. Randy didn't elaborate.

Nick Hilliard (INEX) observed that there is very little indication of multi-threaded route processor software being implemented.

Randy responded that router vendors would disagree with that.

Lutz Donnerhacke said this presentation showed how BGPSEC fails to get deployed even in the easiest model, so he didn't support it.

Randy responded he didn't ask for support.

Immo Wehrenberg (RRBone) said it took him 40 seconds to verify a full table, but this type of processor is not in a router. Once BGPSEC becomes an issue it is not a problem to add a cheap CPU to an expensive line card.

Randy said router vendor engineers are going to test this extensively.

BGPSEC is going to deploy in islands, so when big islands deploy they will ask the vendors and they catch up an make faster hardware.

Randy pointed out that there is also memory that could be an issue, but assuming one million keys of 400 bytes each, it turns out not to be problematic.

Daniel Karrenberg (RIPE NCC) asked for clarification on how the customer cones were calculated.

Randy responded it's based on AS path, with prepending removed, because that is what the signature count is in the currently proposed BGPSEC drafts.

Joao Damas (ISC) observed that as long as deployment is slow enough BGPSEC is not going to be a problem; it will just grow the islands. He asked if there is a way to predict the size of an island before you join it.

Randy said this is easy.

G. AOB

Daniel Karrenberg (RIPE NCC) asked if the working group had input on the usefulness of RIS beacons.

Randy Bush (IIJ) said he refers people to the beacons a couple of times a year, and thinks people are actually using the beacons.

Geoff Huston (APNIC) said he uses them, because he knows them and understands their behaviour.He would like to see this activity continued.