RIPE 58

• content to the Chair of the working group.
• format to [email protected].

Working Group Chair: Fearghas McKay (absent) | Co-Chairs: Cara Mascini and Mike Hughes

Session 1: Wednesday, 6 May - 14:00-15:30

A. Administrative Matters

• Welcome
• Select a scribe
• Jabber Monitor
• Microphone Etiquette
• Approve Minutes from RIPE 57
• Finalise agenda

There were no last minute agenda points. There were no comments on the minutes from RIPE 57 and so they were approved.

B. Co-Chair Vacancy

Mike Hughes stepped down from his position as chair at RIPE 57 in Dubai.
The WG Co-Chair called for nominations to be sent to the mailing list by 17:30 on Wednesday 6 May. Three candidates were subsequently nominated:
Wolfgang Tremmel from DE-CIX
Remco van Mook from Equinix
Andy Davidson from Lonap

Voting took place by ballot paper at the meeting on Thursday 7 May. E-mail voting took place from Wednesday 6 May 17:00 until Thursday 7 May 10:00.

C. IXP Updates

AMS-IX
Steven Bakker
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/amsix.pdf

There were no questions.

DE-CIX, ALP-IX & WORK-IX
Wolfgang Tremmel
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/de-cix.pdf

There were no questions.

Equinix
Celia Darmon
were no questions.

GR-IX
Antonis Lioumis
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Lioumis-GR-IX_PRESENTATION.pdf

There were no questions.

Inex
Nick Hiliard
[Presentation missing]

There were no questions.

LINX
Mike Hughes
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/LINX_Report_to_EIX_RIPE_58.pdf

There were no questions.

LONAP
Andy Davidson.
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Davidson-LONAP_IXP_Update.pdf
There were no questions.

NaMeX
Maurizio Goretti
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/namex.pdf

There were no questions
.
Netnod
Kurtis Lindquist
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Lindqvist-Netnod_update.pdf

There were no questions.

NIX.CZ
Josef Chomyn
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Chomyn-NIX.CZ_update.pdf

There were no questions.

NOTA
Josh Snowhorn Terremark
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Snowhorn-NOTA_Update.pdf

There were no questions.

VIX
Harald Michl
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/vix.pdf

There were no questions.

D. Euro-IX Update

Serge Radovcic
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/euro-ix.pdf

There were no questions.

E. Announcement of an IPv6 Peering Workshop - Breedband Delft

Paul Hoogsteder Stichting Breedband Delft

There were no questions.

Session 2: Thursday, 7 May - 11:00-12:30

Chair: Cara Mascini

F. Co-Chair Election: Andy Davidson was elected as co-Chair of the EIX WG. Details of voting for the Co-Chair are as follows:

Five email votes were disqualified because they arrived in too late.
Andy: paper 40, email: 17 = 57 + transfer: 11 . >>>>> total 68
Remco: paper 43, email 2 = 45 + transfer 14 >>> total 59
Wolfgang: paper 27, email 9 = 36

total: paper 110, email 28 = 138

Not all votes for Andy had 2nd or 3rd choice indicated. Only 25 of these 36 votes had transfer votes

G. BCIX - Update

Thorleif Wilk http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Wiik_BCIX_-_Update.pdf There were no questions.

H. When the Link Fails: Faster Recovery in Internet Exchanges

Zbynek Pospichal
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Pospichal-When_the_Link_Fails_Faster_Recovery_in_Internet_Exchanges.pdf


Steve Kent (BBN Technologies) said that work is being done in the IETF on successor security mechanisms for TCP specifically for protecting BGP sessions. These involve automatic key changes which make it completely unfeasible to have any list of passwords in the switches. Also this would mean that the switch should be looking up several layers higher than where it should be looking in the first place.

Stephen Bakker (AMS-IX) commented that he didn't see how this will work on layer two networks which involve multiple switches that need to know all those peering details. He said every single packet would heave to be looked at to make sure whether it's a BGP packet and then takeaction on it. Already, the current switches have a hard enough time switching the traffic that they have to do instead of just inspecting every single packet and doing something with it.

He continued that he didn't see this working. He was not sure what problem Zbynek trying to solve. The biggest problem is not the timing out of BGP sessions but the excessive flapping of BGP sessions due to a short link flap, for example. On these occasions, he said that you don't want your BGP sessions to flap, you want them to hold on for a short while. So it's just going to create more churn in the routing table than is necessary.

Wolfgang Hennerbichler (Vienna Internet Exchange) said that he thought no switch vendor will implement this. He said that Internet exchanges are a small fish for the big switch providers and every feature we want we usually have to fight for. Implementing this feature would involve a lot of time, switch vendors won't implement this.

Ruediger Volk (Deutsche Telekom) said that he thought it was a bad idea. He add that there are layer violations and that busing security leaks to sneak in stuff is layer violating.

Volodymyr Yakovenko (Google) asked about the extension to route server functionality. What is bad in tweaking BGP timers? Do you have numbers?

Zbybnek responded that it's not bad as such but causes stress on the CPU of peering routers. He added that it might cause flapping.

C continued: PARIS-IX

Maurice Dean
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Dean-exchanging_traffic_in_Paris_A_new_proposal.pdf

An attendee asked that the German be removed and perhaps put some French as the survey is partly in German.

New proposal: exchanging traffic in Paris.
Pheon-ix

Attendees were requested to fill out the survey regarding the proposal. Details available at: www.pheon-ix.net

There were no questions.

I. Introduction to ISC's Secure Information Exchange and 2009 Update

Keith Mitchell
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Mitchell-Introduction_to_SIE.pdf
Eric Osterweil (UCLA/Colorado State University) asked that, as a researcher, how could he get access to some of this? Specifically the DNS names?

Keith said that he would need to sign an agreement to make sure the data that he is receiving and analysing is dealt with appropriately and maintains confidentiality. Then he could be provided with co-location space for a server which he could plug into and can tune into one of the passive DNS channel. Then it is up to him what analysis he does on that.

Euro-IX - Best Common Practices
Wolfgang Hennerbichler
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Hennerbcihler-IXP_Best_Current_Practices.pdf

There were no questions.

J. Discussion Panel on Route-Server Implementation and Maintenance.

Why do I tolerate Quagga/OpenBGPd/Bird?
Nick Hillard
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Hilliard-Why_use_Quagga_for_Route_Servers.pdf

Cara Mascini said that she had talked to a couple of people at the session who also run route servers and that have specific set-ups. She said that they would like to say something about them and why they tolerated or chose what they did.

Andy Davidson (LONAP) said that he wanted to build route servers because it is a good way of growing value for people as soon as they connect to the exchange.

He said that it's a service that a number of people have individually asked us for and it's a good way to grow traffic which helps with marketing. So, LONAP decided to build some route servers but didn't want to build another Quagga because there were already several of them in London.

He continued that he was going to roll out route servers on open BGP and support AMS-IX's to add per peer RIB to that software, and also roll out Bird, which the guys from Prague are doing a lot of work to make good.

He said that LONAP would be the first exchange to roll that out as a route server. LONAP is working really closely with those guys to swap really good feedback. He continued that if there were other exchanges in the room making similar decisions, LONAP would certainly swap information about how successful the new builds are going. This explains our position and why we're not using Quagga.

Cara asked if anyone has a remark or question?

It was mentioned that AMS-IX as working on a new set up for open BGP.

An attendee said that that currently, less Quagga is being used, it's just too unstable, has scaling problems and the single-threading issue. So we're going to move to open BGPD which isn't quite ready yet.

Ondrej Filip (CZ.NIC) said that CZ.NIC is currently running two Quaggas as a route server and that he is not happy. We would like to have solutions so we are working on replacing one of the Quaggas with Bird.

Bird is a routing demon that was developed by people who have close relationships with this exchange point. So if you need some more features in Bird, just let CZ.NIC know and it can try to implement some new things into it.

Mike Hughes (LINX) said that LINX runs Quagga. He explained that in his presentation, he'd shown some stats and the number of peers and prefixes we received on there. We ran Quagga when at first because really that's all there was. There wasn't much in the way of viable alternatives. Route servers have become very vital to a lot of the larger IXPs - especially those IXPs that are the size of AMS-IX or LYNX where there are ± 31,000 members.

If you had an open peering policy trying to maintain that number of peering sessions and that number of peering relationships on a configuring per device per session, it would be quite a lot of work and you have to ask yourself, if it wasn't the route servers, would that peering community and environment be so rich? It probably wouldn't.

He continued that people might say that I'm not going to peer with these hundred people because it's not worth the time, if I can get it via the route server it's low cost.

He said that that LYNX is currently in the situation where there are issues with Quagga and has hit some of the scaling issues that were just mentioned. He continued that he is just backing several horses in this race because there are lots of alternatives and they are viable alternatives - Bird is one of them and so is open BGPD once it has the per peer per client RIB support. He said that there were not that many alternatives until recently.

He continued that the community abhors a vacuum and there is a vacuum with Quagga with the larger exchanges and we're trying to fill that gap one way or the other. He said that the larger IXPs are just trying to buy some time with Quagga but that's all we can do until we find a replacement and we are spending a lot of time and effort on that at the moment.

Harald Michl (ACOnet) said that, as he'd entioned yesterday, ACOnet currently plan to implement a route server as fast as possible but besides the decision on which software to take, ACOnet intends to take Bird because it's developed by IXP people.

He continued that there are always questions such as how do we implement the filtering issue. Nick showed that it's common to use BGP community tags to give the route server information which prefix has to be announced to which peer but this is not compatible with 32-bit ASNs and we want to build a new route server which is compatible with all possible features. He said that he did not want to call 32-bit ASN numbers a problem but if you build a new route server it should be compatible with everything that could come now. That's our main problem. We want to build something that is able to do all our requirements at the moment.

Arnold Nipper said that currently DE-CIX were still running a fairly old version and it's quite stable compared to what he had seen at other exchanges. Last week, at Euro-IX, this was talked about and it was decided that a Working Group on improving Quagga should be formed. He said that he has already seen a substantial improvement in gathering resources both in personnel as well as collecting money. He said that he was quite sure that at the next RIPE Meeting, RIPE 59 in Lisbon, we'll be able to provide results on this.

Z. A.O.B.