RIPE 62

• content to the Chair of the working group.
• format to webmaster@ripe.net.

RIPE 62 EIX Working Group -- Session I and II
Amsterdam, 4 May 2011 11:00-12:30 and 6 May 2011, 09:00-11:00
Co-chairs: Andy Davidson, Fearghas McKay

SESSION I - Wednesday, 4 May, 11:00

A. Administrative Matters

• Welcome:
  Fearghas McKay welcomed the attendees and began the EIX session at 11:08 local time.
• Finalise agenda
  Fearghas went through the agenda and asked if there were any additions or omissions. There were none.
• Scribe and Jabber Monitor
  Fearghas thanked the technical team, scribe and chat monitor from the RIPE NCC for their help during the session.
• Fearghas asked for comments on the draft minutes from RIPE 61. There were none. Minutes were approved.

B. New IXPs in a Post IPv4 World

Andy Davidson, LONAP / Hurricane Electric

Andy asked for comments on the proposal to reserve a /16 from the final /8 soley for the IXPs.

Will Hargrave from LONAP supported the proposal.

James Blessing from Limelight Networks said it was a good idea and suggested takinga /16 from the existing space now rather than from the last /8.

Kurtis Lindquist supported Andy's proposal.

Bill Woodcock, ARIN Board of Trustees, commented that the previous suggestions were good and suggested that this reserved space not be just for new exchanges, but also for those that have a /24 and suddenly need to be in a /23 because of a bump in participant growth.

Christian Panigl, VIX, supported Andy's idea and and suggested finding sponsors because there are lots of organisations with big amounts of /16s that might be willing to donate it to the IXPs.

Henk Steenman, AMS-IX, supported the idea.

Aleksi Suhonen, TREX, said he supported Andy's proposal, James' suggestion and potentially Bill's idea but only if the document says what the minimum assignnment size for the IXP should be.

Anders XXX, supported the idea as long as it didn't mean putting a price on getting an IP pool. He suggested adding that maybe the space shouldn't be routed.

Andy replied that there was a long-standing tradition that address policy and routing policy don't overlap in the RIPE PDP. He added that many IXPs make a deliberate decision to route or to announce their peering LANS because their members ask them and to make debugging work. He said it was a good suggestion, but difficult to implement.

Several more attendees stepped up to the mic to voice support for Andy's proposal.

Andy thanked everyone for their support and said he would attend the Address Policy Working Group session the following morning to present the proposal.

C. New/Future IXP Services

Henk Steenman, AMS-IX

Christian Panigl, VIX, asked whether the SLAs came with penalties, if the customers have to claim those penalties, and if you can still get the contract without SLAs and one with SLAs but withahigher price?

Henk confirmed that this was the case for all of Christian's questions.

D. Renumbering an IXP

Petr Jiran, NIX.CZ

There were no questions for Petr.

E. Open Source Routing Forum Introduction

Keith Mitchell (ISC)

There were no questions for Keith.

F. Futuristic route-servers

Job Snijders (Prefix Servers)

Blake Willis, L33 Networks, asked if Job thought about making an making API available behind the interface.

Job replied that APIs are usually good, but if you're already updating the AS-set, it could be twice the work. But it could be useful if policy is enforced as fast as possible. API could be a nice method to kick the script and do it now.

Andreas Polyrakis, GRNET,asked if the RPSL wouldbe writtenin the web interface or in the AUT-NUM object of the peer.

Job replied that it what happens with a customers AUT-NUM is up to the customer.

Andreas agreed and stressed that you shouldn't request that the customer to change its own AUT-NUM.

Job replied that RPSL was nice but he didn't want hard dependancy on it because chances of mistakes or misunderstanding syntax is too complicated to rely on it blindly.

Andreas replied that RPSL was very limited and there was a need for another way to describe routing policies.

Job agreed. He said problem is that RPSL is used to describe what you will do with direct neighbours, you can't describe what will happen a hub away and that's needed in the route server context.

Sergio Ramos, chat, asked if Bidirectional Forwarding Detection (BFD) was suitable for route servers and if there were plans to implement it?

Job replied that if you talk BFD with the route server, it's useful, but what's needed is if a route server can redistribute information that two distribute, and set up a BFD session with each other. He added that David Freement from Clarinet is working on something like this and he'd use it if it became available on the market.

Niels Bakker, AMS-IX, commented that unlike what Job said on on his website, AMS-IX is perfectly capable of running ASN32.

Job asked him to explain how it worked with BGP communities.

Niels said they don't use BGP communities.

Job apologised.

Fearghas announced that Ondrej Filip from CZ.NIC would be giving a one-minute lightening talk and then Serge Radovic would give his EURO-IX update, pulling this agenda item from Friday.

Ondrey Filip, CZ.NIC, gave an update on routing demon, BIRD.

Kurtis jokingly asked for ISIS.

There were no other questions.

H. EURO-IX Update - Serge Radovic

There were no questions for Serge.

Andy concluded the session and thanked the tech support, scribe, chat, etc.

SESSION II - Friday, 6 May, 9:30

EIX Working Group co-Chair Andy Davidson welcomed attendees and opened the session at 9:30 local time. He encouraged attendees to participate in the EIX Working Group by joining the mailing list.

G. IX News

Nurani Nimpuno from Netnod gave an update on Netnod.

There were no questions.

Elisa Jasinska from Arizona IX gave an update.

Soneone asked how many sessions were up.

Elisa said there was one.

David Temkin from Telx asked who was responsible for engineering.

Elisa said she was.

Andreas Sturm from DE-CIX gave an update.

There were no questions from Andreas.

Peter Lievenfrom ECIX gave an update.

There were no questions for Peter.

Franck Simon from France-IX gave an update.

There were no questions for Franck.

Lucian Obrocea from InterLAN gave an update.

There were no questions for Lucian.

John Souter from LINX gave an update.

There were no questions for John.

H. Research and Development projects at TREX, Finland

Aleksi Suhonen

Andy Davidson asked if he'd be willing to share some of the R&D projects.

Aleksi replied that the installation process was fairly straight-forward, so they could make the documentation more presentable and share it, yes.

There were no other questions.

I. AOB

Andy opened the floor for any IXPs that wanted to give a quick presentation.

Harald Michl from VIX gave an update.

There were no questions.

Matjaž Straus Istenič from SIX gave an update.

Remco van Mook commented that “quality of service” is actually a fantastic marketing term because it's all about dropping packets, not improving the quality.

He added that if you have got two members who want this is than there is a fantastic layer one solution: a patch cable.

Matjaž said there might be more of them.

Remco replied that in that case, run more patch cables.

Aleksi commented that the layer 2 quality of service should be honoured and that the operators then should make it the standard way you treat those and make it available to members. Then it's their responsibility to map their internal QoS or class of service over the shared medium.

Matjaž replied that they don't want to move to trunks, but have no simple access ports without trunking.

Aleksi Suhonen, TREX, commented that they make addition services part of basic service model so it wouldn't be just peering. Members can decide whether they want VLAN 4 trunking or not. So he doesn't think it will be a problem.

Andy Davidson asked Matjažto report back on progress.

Remco van Mook gave an update on Equinix.

David Temkin from Telx gave an update.

There were no questions for David.

Andy concluded the session, thanked attendees and reminded attendees to join the mailing list.