You're viewing an archived page. It is no longer being updated.
RIPE 65
EIX Working Group
26 September 2012
9:00-10:30 and 11:00-12:30
WG co-Chairs: Fearghas Mackay, Andy Davidson
Scribe: Amanda Gowland
A. Meeting Admin
Fearghas welcomed attendees to the session, thanked the RIPE NCC staff for scribing and chat monitoring and asked anyone presenting during the lightning talks to upload a one-page slide with their contact details.
B. Overview of the local peering scene lead– Mark Gauw, NL-IX
The presentation is available at:
https://ripe65.ripe.net/presentations/58-EIX-RIPE65_Overview_local_peering_scene,_by_NL-ix.pdf.
There were no questions.
C. The sense of distributed Internet exchanges– Mark Gauw, NL-IX
The presentation is available at:
https://ripe65.ripe.net/presentations/59-EIX-RIPE65_The_sense_of_distributed_IXPs,_by_NL-ix_.pdf
There were no questions.
D. Analysis of Query SRC and Anycast locations - Kurtis Lindqvist, netnod
The presentation is available at:
https://ripe65.ripe.net/presentations/149-i-root-src-analysis.pdf
Mike Blanche, Google, asked if DNS resolvers use latency to try and determine the best place to pick.
Kurtis said they are supposed to and that it depends on the software. it more and more.
Mike commented that some of the issues might not be routine, but could be DNS servers picking servers further away than the closer one.
Kurtis agreed and added that the latency is also tied to optimise your routing.
Mike added that the country of the AS registration isn't necessarily the country where queries originate from.
Kurtis agreed and added that this was especially true for Google.
Mike added that people like Level 3 have big European networks so the fact that they have stuff appearing in Brussels isn't such a big surprise.
Kurtis said that was right but they aren't seeing any level 3 anywhere else so every single query from that AS is going through Brussels.
Mike commented that that was probably stupid.
Kurtis agreed.
Jen Linkova, Google, asked if Kurtis saw any strange solves for v6 traffic.
Kurtis said he didn't have time to look at that.
Jen replied that she'd be interesting in comparing data because she noticed plenty of documentation prefix and an unclear linkup.
Kuris replied that he could do that. He said it was not as much as for IPv4, otherwise it would have showed up on the list. He said the threshold was 1% of the queries and nothing in the threshold showed strange traffic but that was a good thing.
Patrik Falstrom, netnod, in response to Mike's question about DNS, said that they do have homogenous software and hardware data on both nodes and they believe that the amount of application layer software back-off is actually extremely low. On the other hand, you do have to be careful when drawing these kinds of conclusions on why “A” is communicating with “B”. He said they were just looking at the IP traffic between the ASes. He said that he was also doing a similar analysis in parallel regarding smtp traffic and he's having similar issues to the one's Mike was referring to.
There were no more questions.
E. IXP Traffic During Major Sport Events - Mirjam Kuehne, RIPE NCC
The presentation is available at:
https://ripe65.ripe.net/presentations/137-IXP-Traffic-EIX-RIPE65-Kuehne.pdf
Mike Blanche, Google, thanked Mirjam for an interesting presentation and commented that a lot of the traffic is probably hidden because it was delivered by CDNs that are inside access provider networks, for example, BBC. He asked if there were any access providers in the room interested in giving a presentation about the traffic impact from major sporting events.
Mirjam agreed and said that's why she said not all the traffic went through exchange points.
Lauren Provo, Comcast, commented that they didn't see a huge change because of time of day shift.
Fearghas commented that Lauren was an American access provider, so it makes a difference. He added that UKNOF was taking place in a couple of weeks in London and there would be a couple presentations from CDNs and they would be available to watch remotely.
F. AMS-IX IPv6 Day Before & After - Maxim Tulyuk, AMS-IX
The presentation is available at:
https://ripe65.ripe.net/presentations/122-ams-ix_ipv6_day_2012.pdf
There were no questions.
G. AMS-IX collaborative model - Cara Mascini, AMS-IX
The presentation is available at:
https://ripe65.ripe.net/presentations/198-RIPE65_presentation_Cara_Mascini_v1.1.pdf
Session II
H. IXP Wish List Status Update – Harald Michl, Vienna Internet Exchange
The presentation is available at:
https://ripe65.ripe.net/presentations/156-ripe65-eix-hm-wishlist.pdf
There were no questions.
I. Euro-IX Update* - Bijal Sanghani, Euro-IX
The presentation is available at:
https://ripe65.ripe.net/presentations/157-Euro-IX_Update_RIPE65_Final.pdf
There were no questions.
J. Bird Update - Ondrej Filip, NIX.CZ
The presentation is available at:
https://ripe65.ripe.net/presentations/191-BIRD-20120926-OF-RIPE-EIX.pdf
Howard Lee, Time Warner Cable, commented that not having to have a master routing table is one of the biggest advantages of BIRD. He added that they create pipes between the small routing information tables. He added that the pipe equals to a bilateral BGP peering so they don't have to have so much memory.
Ondrej replied that it would be interesting to compare the two setups and he might try to show the results of what's better and how it performs.
Kurtis Lindqvist, netnod, asked about his feature request for ISIS.
Ondrej said he expects it to be in place by the beginning of 2013 but can't say for sure.
Kurtis asked if it would be part of 2.0 or a separate development?
Ondrej said it would be in the main branch.
James Blessing, Limelight, remotely asked how many secondary routes a single RIB could hold.
Ondrej said it imports the best that matches the filters.
There were no more questions.
K. Quagga Update – Martin Winter, ISC / OpenSourceRouting.org
The presentation is available at:
https://ripe65.ripe.net/presentations/146-Quagga_Status.pdf
Maksym Tulyuk, AMS-IX, asked what the problem was with joining the main BGP and EURO-IX branches.
Martin replied that the challenge is that people want to see nice commits and a small breakdown. He added that the code was written on his own without much community input. It's about 170,000 lines and BGP changed a lot of the library so he'd like to see those issues merged in there together. He said they're still looking at it but that it's a lot of work to clean it up, have the code reviewed, test it, etc.
L. Content caching/CDN sharing for small ISPs at IXPs - Toshinori Ishii, NTT Communications
The presentation is available at:
https://ripe65.ripe.net/presentations/152-RIPE65_EIX_caching.pdf
There were no questions.
M. Remote Peering - Zaid Ali, LinkedIn
The presentation is available at:
https://ripe65.ripe.net/presentations/196-RIPE65_EIXWG_ZA.pdf
Mark Gauw, NL-ix, asked Zaid if he could highlight what the multiple BHP sessions mean in his latency traffic.
Zaid replied that they think it's just like extending to a POP, like New York or London and then another POP in Amsterdam, you're still going to build a transport layer so you have that amount of latency still unless you do some kind of local caching and need some presence there where you're serving content of that place, then latency will matter and it won't actually help you.
Nina Hjorth Bargisen, TDC, commented that Zaid's view was very much from a content holder perspective and wondered if the same benefit would apply to a network like hers where she has like eyeballs. She asked for Zaid to elaborate on routing inefficiencies. She asked how Zaid chooses which port to send traffic to when you use traffic engineering to send your traffic on certain ports according to the distance of the remote peering connection, try to get as close to somebody's eyeballs and then you have several sessions with the same network or with the different IXs that you reach. She added that, as far as she understood from the slides, if he had all the ports on the same router he has only one port and wondered how he chose between different sessions to make sure that traffic gets most efficiently routed to the end users.
Zaid replied that they try to peer with people in multiple locations, so they do have policies for that.
Nina added that it means that the port they choose is completely random then.
Zaid confirmed it was.
Will Hargrave, LONAP, commented that the part of Zaid's presentation where he discusses dropping bits on the floor when you have a layer 2 outage was like comparing apples and oranges, a multi-site IX versus your members connecting using carriers. He added that when you have any decent multi-site IX that has very good resilience protocol in its layer 2 any outages would be very short. When you have this sort of carrier arrangement, it's actually very difficult to do some inter-provider layer 2 resilience which means they are building a bit more of that fragile IX. He added that outages are more likely to occur where you have multiple parties involved because you can't assure the resilience.
Zaid replied that it was a big point of debate and that people in his team have argued about it a lot because they actually prefer layer 1 service but sometimes the cost cannot be justified. He added it was a choice where you want your RIS to be. He agreed that the biggest challenge in that is up to the transport providers to give you that level of service that doesn't cause outages all the time and that's the success of remote peering otherwise the fragility will take over and people won't do it anymore.
Will replied that a lot of IXs are looking for increased reach and partnering with people to do this. He added that IX operators needed to think carefully about the way that they engineer resilience with their partners and carriers with the service that LinkedIn buys because he wonders if it's good enough right now.
Zaid replied that it was a good point.
Mike Hughes, smashing.net, commented on the layer 2 failover and waiting for the BGP session to die and that it's going to happen if you are over on an IX with shared media regardless of whether you are doing remote peering or whether you've got a layer 1 connection if the peer goes away on the far end, it doesn't matter whether it's one IX switch or it's multiple IX switches. It doesn't matter whether it's multiple exchanges or remote peering if the far end goes away; you still have got to wait for timers. He added that if there is a particular peer that you care so much about that you need instantaneous detection of that peer going away. You need to P N I with them or you need to use some other sort of way to check liveness. He added that he sees where Zaid's coming from with the hybrid approach and thinks that's great, too many people are remote only or very heavily remote.
Will replied that he disagreed with Mike and that what matters is not just the fact that an outage occurs and how it occurs and how long it lasts. If there are more fragile elements in the network, then by its nature, there is a greater RBKI of happening and the impact is greater. He added it was relevant to think about but they need to look at the whole context of the whole network and the whole path.
Mike said he thought will was right and their comments weren't that far apart, if there's somebody you care about that and you need immediate notification you need to take the fragility away, like you are saying the fragility is a bad thing.
Blake Willis, L33 networks, asked if Zaid's had any service providers propose a virtualised router service at any exchange like where they lease them, for example, a Juniper logical system.
Zaid replied no.
N. Lesotho Internet Exchange Point - Puseletso Putsoane,Vodacom Lesotho
The presentation is available at:
https://ripe65.ripe.net/presentations/173-LIXP2pdf.pdf
Mike Blanche, Google, said he was pleased to see this development in Lesotho and asked how much traffic costs there.
Puseletso replied it was very expensive, about $1,000. She added that she forgot to mention they are getting Google caches and the infrastructure was already in one of the peering companies so it would be interesting to see how the curves change after the Google caches are up and running.
Mike replied that it will be interesting to see how it grows.
O. IXP 30 sec updates
Ben Hedges from LIX gave an update.
There were no questions.
Akio Sugeno from Telehouse gave an update on NYIIX.
The presentation is available at:
https://ripe65.ripe.net/presentations/182-NYIIX_Presentaion_RIPE_65_Sep_2012_Amsterdam.pdf
There were no questions.
Bengt Gördén, Resilans, gave an update on STHIX.
The presentation is available at:
https://ripe65.ripe.net/presentations/184-ripe65_sthix.pdf
There were no questions.
Cara Mascini from AMS-IX gave an update.
The presentation is available at:
https://ripe65.ripe.net/presentations/199-AMS-IX_Cara_Mascini_30_sec_update_RIPE65.pdf
There were no questions.
Kurtis Lindqvist from netnod gave an update.
The presentation is available at:
https://ripe65.ripe.net/presentations/194-eix-netnod.pdf
There were no questions.
Ondrej Filip from CZ.NIX gave an update.
The presentation is available at:
https://ripe65.ripe.net/presentations/170-NIX-20120926-OF-RIPE-EIX.pdf
There were no questions.
Martin Hannigan from Akamai gave an update on TorEx.
There were no questions.
There were no AOBs. Fearghas thanked the RIPE NCC and the stenographers for support during the sessions and attendees for participating in the discussions.