RIPE Meeting: 56
Working Group: EIX
Status: Final
Revision Number: 1


Thursday, 8 May. 11.30-12:30

A. Administrative Matters

* Welcome
* Select a scribe: Susannah Gray
* Jabber Monitor: Rumy Kanis (11:00), Mark Dranse (14:00)
* Microphone Etiquette
* Minutes from WG session at RIPE 55
* Finalise agenda

B. IXP Updates

* NaMeX
* NDIX - Presentation of the new logo
* Netnod
* Overview of South Asian IXPs

C. Surprise Event

D. Euro-IX Update


Thursday, 8 May. 14:00-15:30

E. 40/100GbE IEEEE & Progress Update - Greg Hankins

F. Some IPv6 Observations at AMS-IX - Arien Vijn

H. Results of the Peering Configuration Survey - Greg Hankins
(Force10), Ren Provo (Comcast) & Tom Scholl (AT&T)

Z.. A.O.B.


Thursday, 8 May. 11.30-12:30

Fearghas welcomed the attendees and opened the session.

B. IXP Updates

Cara Mascini

There were no questions.

Yvonne Hahn and Frank Orlowski

There were no questions.

Eric Troyer

There were no questions.

Nick Hilliard

There were no questions.

Andy Davidson

Mike Hughes

There were no questions.

Daniele Arena

There were no questions.

NDIX - Presentation of their new logo
Remco van Mook

There were no questions.

Nurani Nimpuno

There were no questions.

Josef Chomyn

There were no questions.

Akio Sugeno

There were no questions.

Christian Panigl

There were no questions .

Overview of South Asian IXPs
Gaurab Raj Upadhaya

There were no questions.

C. Surprise Event

A survey was distributed and filled in by the attendees.

D. Euro-IX Update
Serge Radovcic

There were no questions.

Thursday, 8 May. 14:00-15:30

E. 40/100GbE IEEEE & Progress Update
Greg Hankins (Force10)

There were no questions.

F. Some IPv6 Observations at AMS-IX
Arien Vijn (AMS-IX)

There were no questions.

G. Results of the Peering Configuration Survey
Greg Hankins (Force10)

An attendee who had seen Greg's presentation at the Global Peering Forum (GPF) asked if any work had been done to find out if the eBGP multi-hop slide is actually correct.

Greg responded that the slide the attendee was referring to had been taken out of the presentation for this event. He explained that the slide was about how participants preferred to do load balancing and that the options were link aggregation, eBGP multi-hop, eBGP multi-path and a few others. He continued that people overwhelmingly chose eBGP multi-hop. After some discussion, it was concluded that people didn't actually understand the question.

Nick Hilliard (INEX) said that he had done something with Jumbo Peering LAN at INEX and found out that people are quite interested in it until they realise the can of worms that it opens up in terms of raising MTUs universally on their networks. He continued that you'll suddenly find yourself blackholing traffic and, because most End User boxes don't use anything greater than MTU 1500, debugging and monitoring is not easy. He added that the Jumbo LAN is still there, there's no one connected to it but that it was an interesting experiment.

Ariën Vijn (AMS-IX) commented on the Jumbo LAN issue. He said that a few years ago, AMS-IX asked its members about Jumbo frames. They responded that their customers have 1500 byte frame sizes and so having a Jumbo LAN would only cause problems.

Greg said that, at the GPF when he first presented this presentation, he asked if these surveys should be carried out on an annual basis. He continued that a lot of people thought that it was a good idea and asked the RIPE Meeting attendees what they thought.

There was general agreement in the room that the survey should be carried out on an annual basis.

H. Let's do the Time Warp Again
Mike Hughes (Linx)

Kurtis Lindqvist (Netnod) commented that Netnod also runs NTP servers although they are operated on a more complex basis than Linx's servers. Netnod has a set of caesium servers and also a set of rebidium servers. It also gets a signal from the Swedish national time scale and that's actually what we end up distributing. This is good for applications that require you to be traceable to UTC. The drawback of using GPS, which is why Netnod does not use it, is that your accuracy is in the hands of someone else. There's well known techniques for jamming signals or disturbing them.

Mike responded that LINX decided that it did not need to have control of the time source but did not want to rely on a single time source. This is why the SHS, the secure hybrid platform, is a good solution because the German government are in control of one signal, or the British government are in control of MSF. He added that there's GPS stuff as well, which is also used by a lot of people, and this gives a better level of protection than just trusting a single time source without Linx having to run its own reference.

Kurtis commented that Netnod has been looking into providing higher accuracy frequency sources for people to clock their transport networks. Most people do this by using GPS, which again can be jammed, or they are buying it from somewhere else at a substantial cost. Netnod can provide a lot higher accuracy than this.

Mike responded that people are using the LINX system to synchronise sys-logs and to generally clock their networks to a reasonable level of accuracy but not the sort of level of accuracy that Kurtis mentioned.

I. v6 Numbering Plan @ Netnod
Kurtis Lindqvist (Netnod)

Arien Vijn (AMS-IX) asked what will happen when there is no IPv4 anymore and what will happen to the allocation scheme, which is based on IPv4.

Kurtis responded that Netnod will do nothing and that the scheme is not based on IPv4. He said that the scheme is based on having a number, not specifically an IPv4 one, at the end. He added that he might have problems when the last 64-bits run out.

Ariën asked why there was no scheme for AS Numbers.

Kurtis responded that they had the IPv4 numbers and wanted to use the same numbers and that if they had started from scratch, they might have used AS Numbers. He added that more clever encoding can be done.

Lorenzo Colitti (Google) asked what will be done when Netnod has more than 256 members.

Kurtis said Netnod does have /23s and so it could be numbered a little higher. It has not been done yet but it could be but this is not really an issue. Netnod is currently at 50 members after more than 10 years in operation. IPV4 space will probably run out before it becomes an issue.

J. Gaurab Raj Upadaya
[No slides used]

Gaurab talked about IPv6 in exchange points and said that there seems to be a lot of discussion but no well established processes to do it. He would like to produce a BCP for exchange point operators and ISPs for connecting to an IXP. He asked the audience for feedback.

Arien Vijn (AMS-IX) said that he thought that an IXP can do what it wants. He added that AMS-IX's scheme doesn't have any administration in it and people can figure out an IPv6 address. He added that, for router interface configurations, the AMS-IX website has a configuration guide which is publicly available and has many IPv6 options. He said that he didn't see that there was actually a problem and asked what problems Gaurab was referring to.

Gaurab said that the AMS-IX guide is very well known in the community. He added that a lot of exchange point operators are getting confused about what the best way to deal with IPv6 is.

Arien said that he did not think there was one best way.

Gaurab said that perhaps all the current best practices could be documented.

Kurtis Lindqvist (Netnod) added that he didn't think there was a single best way of doing this. Writing guidelines and documenting what different options there are and the drawbacks of them all would be a good thing for exchange points to do.

Arien added that he was a bit shocked that this discussion was taking place now, as AMS-IX already had guidelines in 2001.

Fearghas declared that there was no consensus in the room about creating the BCP document. Gaurab said he would take the discussion to the mailing list.

Z. A.O.B

Prizes for the quiz were given out. Fearghas reminded the attendees that RIPE 57 takes place in Dubai and starts on a Sunday and not Monday as usual. He advised people to book their flights early and register for the meeting as soon as possible.