Dear connect-wg friends, Time flies, and it’s only 8 weeks before we meet again in lovely Amsterdam! We’re working on the agenda for the next session which will again be on Wednesday at 11AM: if you have anything you’d like to present (or know somebody who should be presenting), please drop us a note at connect-wg-chairs@ripe.net<mailto:connect-wg-chairs@ripe.net> Also, please find below the draft minutes of the previous meeting - please have a look and let us know any comments. Kind regards, Remco and Florence Connect-WG Co-chairs Draft minutes from RIPE 69: -------- Connect WG Wednesday 5 November 2014 0. Opening and Welcome [1 mins] Co-chair Remco van Mook welcomed attendees. Appoint scribe, Agenda Bashing [5 mins] Remco thanked the scribe, chat monitor and tech support. He announced that Nick Hilliard wouldn’t be presenting agenda point 8. He asked if anyone had any AOBs to add to the agenda; there were no comments. 2. Working Group Charter Discussion [15 mins] Remco said there was rough consensus on the WG’s charter that was drafted at the BoF during RIPE 68 but that it needed to be polished. He asked for comments on the charter; there were none. Remco asked for comments on the proposed chairing process of the WG. Will Hargrave, LONAP, said he supported the suggested process. Remco asked that he and co-chair Florence be subscribed to the RIPE Working Group Chair mailing list. Remco announced that the WG charter and chair selection process was agreed. 3. Cooperating with Cooperation WG [10 mins] 4. Social Side of Internet Interconnection [15 mins] Uta Meier-Hahn The presentation is available at: https://ripe69.ripe.net/presentations/60-Pra%CC%88sentation-Social-side-of-i... Andy Davidson, LONAP and Allegro Networks / IIX, commented that it the common belief is that the way you get around inherent weaknesses in the system is to just build more peering, more Internet, etc. The other motivation was about control: the more interconnection there is, people tend to believe it’s harder for any one system to take control. In order for the Internet to be open, it needs to be well peered. There were no further questions 5. IP Interconnection for Voice [15 mins] Martin John The presentation is available at: https://ripe69.ripe.net/presentations/52-aql_RIPE_69.pdf Maurice Deen, Facebook Inc., asked what was needed from interconnect facilities/IXPs to support voice and SMS traffic. Martin replied that it was about having good peering and good quality of service. SMS traffic is an over-the-top application that they run and voice is about having good peering, low latency/jitter so the more peering, the better service for the customer. Maurice asked if they were not need of QOE monitoring from IXPs. Martin said yes, the more monitoring, statistical data, the better. 6. CDN Best Practices [15 mins] Maurice Dean and Florence Lavroff The presentation is available at: https://ripe69.ripe.net/presentations/100-Working-with-CDNs-towards-BCP..pdf Jim Reid, RTFM, said having CDN best practices was a great idea and more information is needed about this. He asked if there is a BCP about it and how it would be published. He wondered whether it would be a RIPE document, IETF RFC or just a joint statement and let the ISP figure it out. Maurice said he wasn’t as familiar with RIPE’s processes with BCPs as he was with NANOG’s and there is a defined process there but he would love input on how to do this in the RIPE community. Jim replied that it’s easy with the RIPE community, you just have it published. The best thing is to have a working group declare consensus but there’s not a defined process, it’s light weight. It could be a working document and then you could have a more elaborate BCOP if you’re putting it through NANOG or other channels. Maurice thanked Jim for his input and said they could discuss it later. He added that this presentation was to garner interest. Joe Provo, speaking as himself, said that a CDN BCP would be a useful work product for this new working group. He added that many of the suggested BCOPs are just good peering practice so it might be just a good working document as well as on specific CDN usage. Joe also asked if they could encourage a standardised format for reporting across different parties because the external interfaces for reporting are currently opaque. Florence replied that that is something they could aim for in the long-term. She added that Google has documentation and hints for best practices with GC partners on its portal. Nina Bergason, Netflix, said she supported the proposal and it should be further discussed. She asked that the document go both ways (ISPs and CDNs). She added that communication between ISPs and CDNs is very important, there are things CDNs can do to work together better with ISPs. She added that Netflix has good information on their website on how to make the site work well in a network but awareness is low so there is work to do. Maurice replied that is a bilateral proposal with a goal to reach a common understanding of best practices and he’s interested in input on how that can be achieved Piotr Wydrych, AGH University of Science and Technology, asked to what extent they would cover exchange of info on topology between ISPs and CDNS. If it’s the case, Piotr would like to raise awareness of ALT O protocol, standardised at IETF in September. Protocol tries to extract info about topology and passes it to 3rd party to align overlay to underlay topology. He added that AS hop number doesn’t have to be a metric, it’s a flexible protocol. Andy Davidson commented that there may be too much reliance on DNS to solve the problem of traffic going to the wrong place and perhaps a generic page or cookie might be a better solution. Maurice said DNS resolver was just an example and that it simple. most are far more advanced. How we can add further signals is in scope. Florence added, re: DNS, important for CDN, do not map content to the end user with DNS but with BGP. Florian Streibelt, Technical University Berlin, said that the DNS extension mentioned earlier is where you put the client’s address into a DNS request and many CDNs so like the idea of doing HTTP requests and redirects because of old certificates and other things. They really want to have the first contact as a redirect by DNS, so that’s why they often use it. 7. Euro-IX & IX-F [5 mins] Bijal Sanghani The presentation is available at: https://ripe69.ripe.net/presentations/102-connect-wg-ripe69.pdf Remco jokingly asked what an IXP is and to explain it in four pages. Bijal said it wasn’t as simple. 8. The Update Session [5 mins] EURO-IX BCP Elisa Jasinska, netflix [There was no presentation available for download] Job Snijders, NTT, said the schema looks very useful and thanked Elisa and Nick for putting effort into it. He added that it looked complete and contains exactly the data he would use to automate what he currently scrapes using other means. From the peering DB side, he said he’d like to see if they could expose the data according to the same schema, maybe sooner than v2 and just piggy back on the current data model. He said he’d see what he could do to help. Elisa replied that her and Bijal had discussed how Euro-IX could use the same format for importing the data back which would reinforce the schema and the usability of it. Vesna Manojlovic, RIPE NCC, said she was grateful for this work and that they have a project called open IP maps which is crowd sourcing geolocation information for Internet infrastructure and this would be really useful information to import into their data set. 9. Open Mic and Feedback [4 mins] Remco asked for feedback on the agenda format. Carsten Schiefner, DENIC, said he liked Uta’s presentation because it was an outlook beyond the usual parameter. He said it would be good to have those kinds of presentations in future, at least one per meeting. Remco said if there are any other suggestions for out of the box presentations to let them know and they’ll see what they could do. Jim Reid said the agenda for the working group looked good. Remco thanked the attendees and closed the session. This email is from Equinix (EMEA) B.V. or one of its associated companies in the territory from where this email has been sent. This email, and any files transmitted with it, contains information which is confidential, is solely for the use of the intended recipient and may be legally privileged. If you have received this email in error, please notify the sender and delete this email immediately. Equinix (EMEA) B.V.. Registered Office: Luttenbergweg 4, 1101 EC Amsterdam-Zuidoost, The Netherlands. Registered in The Netherlands No. 57577889.