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(a)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-…
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.
