RIPE 65

RIPE 65
MAT Working Group session
Status: Final

Scribe: Mirjam Kuehne
WG chairs: Christian Kaufmann, Ian Meikle, Richard Barnes
Date: 27 September 2012, 16:00 - 17:30

A. Introduction

• Welcome
• Scribe
• Jabber
• Agenda

MAT WG co-Chair Richard Barnes opened the session.

Brian Nisbet, Anti-Abuse WG co-Chair, announced that the nominations for the RIPE Programme Committee were closed. There were 10 nominees, their bios and pictures were available on RIPE 65 website, and the voting will take place towards the end of the first plenary session on Friday.

B. Intercountry BGP As Topology (20 min)

Martin Levy, Hurricane Electric

The presentation available at:
https://ripe65.ripe.net/presentations/293-RIPE65_MAT_Intercountry_BGP_As_Topology_Martin_Levy_Hurricane_Electric.pdf

Daniel Karrenberg, RIPE NCC, thanked Martin for the interesting presentation and made some suggestions regarding the issue that some ASNs are marked with "EU" rather than a country code. He clarified that the first two letters of the reg-IDs are not necessarily country codes. There are actually some better datasets that could be used and that might produce better results, like RIS. Daniel said it should be noted that the information is based on third-party data. He asked Martin if he has any suggestions how RIS can be made better. Where does he see the gaps and which kinds of peers would be needed. Daniel said he was interested if Martin had any ideas about how this could be merged with RIPE Atlas data.

Martin clarified that he used the data from the public statistics files available on the RIR's ftp sites, and not the RIPE Database. He acknowledged that he could get better data but that would mean he would have to send emails to thousands of ASNs and ask them to participate in RIS.

Daniel asked in which order the first 2,000 be contacted and in what order and with what strategy, given limited resources.

Martin explained that he used some ranking which means he looked at large ASNs first. For instance, taking certain countries and getting a well-connected AS in country to convince them to feed even on a remote feed into Oregon or into RIS, would suddenly expose all the connectivity inside that country. He did this in Mozambique, but he couldn't find any
data until there was a feed to the outside. Suddenly he could see all the connections. But that's a special case and would require a lot of work. Usually, many or all ASes seem to connect to an Internet Exchange Point in a country. That means one would need an active collector, actively going after peers in Africa, South East Asia and Latin America, and then slowly mapping. Martin suggested to take Daniel's RIPE Atlas (traceroute) related question offline.

Wilfried Woeber, UniVie/ACOnet/VIX and RIPE Database WG co-Chair, explained the background for the state of country codes in the RIPE Database. There are at least two reasons for this: During the early resource transfer project (ERX) resources were moved from other databases into the RIPE Database. And because the correct information was not known, it was decided to tag them with “EU”. Together with the RIPE NCC Registration Services staff, this could probably be corrected quite easily now. Another reason is that it has been decided some time ago by the community to keep country codes in the RIPE Database even if they are not 100% correct. Wilfried asked if this question would have to be revisited.

Martin advised against removing the country codes. Even if they are not 100% correct, it still provided useful data. The more geographic information the better, but even some is useful. He said he now understood why an ASN holder couldn't modify their country code information in the RIPE Database. He would suggest that “EU” is probably not the right code, but that decision had been made a long time ago.

Wilfried suggested putting this item on the agenda for the next RIPE Database WG.

[ACTION MAT WG co-Chairs: Contact RIPE Database WG co-Chairs and ask to put “EU codes in RIPE Database” on the next RIPE Database WG agenda and possibly start a discussion on the mailing list before then.]

Richard Barnes, MAT WG co-Chair, asked if his report is going up to BGP.AG.net.

Martin confirmed that this was the plan and that he keeps dumping more servers in front of BGP.AG but he doesn't want to put stuff up unless he feels happy with it. There are still a few hiccups in the graphs. He will work on it for another month or so and then you will be able to click on any country and any region to get diagrams. Martin mentioned that regulators love these diagrams, and that's one reason why we should be very careful about getting them right.

Richard suggested that Martin send a mail to the MAT WG and the RIPE Database WG mailing lists once he gets the data online.

[ACTION Martin Levy to send pointer to Intercountry BGP AS Topology to
the MAT and RIPE DB mailing lists.]

C. RIPE NCC Measurements & Tools Strategy (Vesna Manojlovic, RIPE NCC)

The presentation is available at:
https://ripe65.ripe.net/presentations/290-mat-ncc-strategy.pdf
There were no questions.

D. RIPEstat (Vesna Manjolovic, RIPE NCC)

The presentation is available at:
https://ripe65.ripe.net/presentations/292-mat-ripestat.pdf
Christian Teuschel, RIPE NCC, announced the winner of the RIPEstat quiz. It was decided to take all those answers into account that were at least 60% right. Inigo Ortiz de Urbina won the prize (a bottle of Sake).

E. RIPE Atlas Roadmap (Vesna Manjolovic, RIPE NCC)

The presentation is available at:
https://ripe65.ripe.net/presentations/289-mat-atlas-roadmap.pdf

Martin Levy commented on the “three strikes” approach (after three reminders to a RIPE Atlas probe host that is not connected, the probe will be written off) and asked why the RIPE NCC does not insist that the probe be returned.

Vesna confirmed that this would be done.

Daniel Karrenberg added that the probe host would be asked to either return the probe or give it to someone else who will actually use it.

F. RIPE Atlas Anchors (Vesna Manjolovic, RIPE NCC)

The presentation is available at:
https://ripe65.ripe.net/presentations/289-mat-atlas-roadmap.pdf
There were no questions.

G. RIPE Atlas Measurement Methodologies: Examples and Discussion (Benno Overeinder, NLnet Labs & Philip Homburg, RIPE NCC)

The presentation is available at:
https://ripe65.ripe.net/presentations/278-RIPE85-MAT.pdf
Lorenzo Colitti, Google, said he was impressed by the speed in which RIPE Atlas was able to answer the queries. He asked if that was possible because Philip had some special RIPE NCC powers or if this was also possible for normal users.

Philip explained that he set up an experiment on all the probes (which RIPE Atlas users cannot do at his point in time, but would be possible in the future). Philip added that this might not be very practical because it consumes a huge amount of credits. The RIPE Atlas team would have to look into it more. He said he just used the standard interface, so in future it would just be a matter of having enough credits.

Lorenzo said he would not have known that he could use “dig”. He thought you could only run ping and traceroute from RIPE Atlas probes.

Philip confirmed that DNS and SSL measurements are open for everybody who has credits on the RIPE Atlas system. This might have to be published better. Philip also suggested to Lorenzo (and others) to join the RIPE Atlas user mailing list.

Richard Barnes asked if it would be an idea to merge the RIPE Atlas user list with the MAT WG list because there is quite a lot of overlap.

Daniel Karrenberg suggested following the announcements on RIPE Labs (https://labs.ripe.net). He said it is great that Benno went ahead and used RIPE Atlas for these experiments. He commented that the research community loved RIPE Atlas and he is very happy about that. He reminded the audience that the people who are paying for it are the ISPs. He urged caution not to just build a research community. He said it would be good if we could also involve the operators to find out what their operational requirements are. It would be bad to create two separate communities.

Benno agreed and added that lowering the barrier would be a good thing. Maybe creating building blocks or a toolbox might make it easier for people to use RIPE Atlas.

Richard reported that he attended the NLNOG Ring BoF which is more operator focused and driven. He wondered if it would be possible to build a ring-ping with RIPE Atlas or if there is another way to find out what requirements the operators community has.

Lorenzo responded that if we want to involve operators, time is the key. It would be nice if the RIPE NCC could provide tools for LIRs so that they could measure the performance to their website from all RIPE Atlas probes on an ongoing basis. In order to make it really useful to operators, something that provides the results to them and that allows them to generate graphs and alerts pretty easily would have to be developed. In response to Daniel's comment, Lorenzo said there was a natural difference between researchers and operators: researchers want to do things that have not been done before so they can publish it. Operators, on the other hand, mostly have to solve problems. He agreed that it would be nice to create one community, but said there needed to be a few more building blocks before operators could see the return of investment on the time that they spend using it.

Job Snijders commented that the NLNOG ring had 99 operators and that it could be interesting to reach out to the NLNOG mailing list if you are an academic and you want to learn what operators need. He said that operators needed to get results immediately and that they needed real-time data. As an operator, he would be interested in tools that run continuously and provide continuous feedback that would alert him if he has to start debugging. Regarding implementing ring-ping on RIPE Atlas, Job said he believes this is already possible.

Philip explained that one of the goals is to enable a feature where you start a measurement now and then within half a minute or so you would have the first results. He added that at the moment the RIPE Atlas system is optimised for doing continuous measurements. That means, you start your measurements, they will run for a while and then you get all the results and can start analysing them. Currently, if you would do a ping now, then you would get results in about six minutes.

Daniel responded to Lorenzo's comments and said he realised that the interests of the research community and the operators community are distinct and that he wasn't suggesting to make them the same. He clarified that what he was suggesting was to keep talking in the same room. He said he wouldn't like to see these two communities develop their own tools, but to coordinate these developments ("what's research today, might be operations tomorrow"). He added that he appreciated that people realise that it's mostly the operators funding this project.

Richard thanked all the speakers and contributors from the audience.

(Applause)

Z. AOB

Ian Meikle, MAT WG co-Chair, announced that he decided to resign as a WG chair of the MAT WG (after ten meetings). When he became a chair at RIPE 55 this WG was called the Test Traffic Measurements WG. The other chair was Henk Uijterwaal. Henk and Ian managed to move it from the TTM WG to the MAT WG and recruited two new very capable chairs (Christian Kaufmann and Richard Barnes). Ian said he was happy to see that this WG has moved from being stuck in a small side room to one of the bigger RIPE WGs now. He thanked the members of the community, and Christian and Richard for all the support and all past and present RIPE NCC staff who helped to make this a success. Finally, he said he would leave it to Christian and Richard to decide if they need to replace him or if they continue as two co-Chairs.

(Applause)

Richard thanked Ian for his service over the years.