Connect Working Group session
17 October 2018
11 a.m.
REMCO VAN MOOK: Good morning, please find your seats. Put your bags why the overhead locker. There are five emergency exits in this room, one on that side, one on that side. This is not Address Policy, so if you are looking for Address Policy, that's next door.
Welcome to connect. This is RIPE 77. We are here, I am here with my lovely co‑chair Florence in front and our new co‑chair Will. Who is making my life a little bit easier, we have got an agenda for you.
There is also a couple of things we took out of the last meeting on, well basically there is a lot of you in this room, but there is not a lot coming back from this room, you have been very, very quiet and for any number of reasons.
We have died that had this session we're going to give it a shot by taking, allowing the options for people to provide anonymous feedback through the RFC channel, so, you ask a question on say I don't want my name to be read out with this, then we'll take it on and provide that as feedback to any presenter without actually saying who said that, so if you happen to represent a large American company with a lot of nasty lawyers, this is your option to actually say something, and there is going to be part of the session at the end where we will look at turning off the archive for that bit, so anything you said there will be seen by people not watching the life streaming but will not end up in the archives.
With that said, we'll‑ is going to say something about the anonymous feedback and open the rest of the session.
CHAIR: So basically, it was just to show you where to go and be able to do that, so I might have the clicker here. That's our agenda. And so basically, if you want to go to the moment participation part, you can go like on the RIPE website and click on the main room, you will see this thing, this model, this small window and you can put, like, any name you want, like 'anonymous1', or whatever and then it will be your way to go and comment during the session.
And with that, we will be now welcoming George, who will be presenting and covering are moat peering interconnections at IXPs.
GEORGE NOMIKOS: Hello everyone. I'm a research engineer. To, forth is a research foundation in Greece, and today I will present research work in collaboration with university, DE‑CIX and AMS‑IX.
Actually, in this part, we will have three main contributions. We propose quite promising methodology on how to identify remote peering links over IXPs. We analyse the remote peering eco‑system and we introduce a new system, based on this methodology.
Of course, we all know what are the benefits of peering with an IXP. So, it's not necessary to go into the details in the slide. But, I'm not very sure if you will know that there is a pressure for the ASes to have a diverse peering. Actually, everyday we notice that the traffic volumes increase, and this can be translated to pressure to the ASes for a more diverse peering system and as a result, the need for a fundamental system to new peering practices becomes actually more significant.
So, the question is, can we consider moment peering as an alternative effective solution of that problem? It offers advantages like much less cost to connect, to multiple access space with only one border router. But we shouldn't forget that also moment peering can introduce some other drawbacks like remote peering can decrease transparency, because now third parties are involved, some extra delays between IXP and IXP member. And resilience because okay, the single mode router of a remote peer can be considered a single point of failure.
In order to be all on the same page, when we say remote peering, we mean that a network can peer with an IXP. Or through a remote peering reseller.
What is our goal? Actually our goal in this project is twofold. Firstly, we would like to offer much for transparency? How? Based on our technology. To whom? Both to IXP operators and their actual members.
From the IXP operators point of view, this is important because they need to understand the characteristics of their members, and for the IXP members, because it's known as actual can drive their traffic engineering or even their ping policies.
However, additionally actually, as a second goal, we would like to analyse the features of moment peering and how these can differentiate against local peering.
What is already out there?
Actually, there is a prior research work that has been published in connect 2013 and this guy actually propose exclusively RTT based methodology and they say the similar thing that okay if we have an RTT delay between the IXP and the IXP member and this slay is more than 10 seconds, then this IXP member can be considered as moment.
However, based on our ground truth data, we will that this methodology cannot work well with some cases and of course, can meet some moment peering links.
Actually, we made an experiment. We used some ground truth data and we also intending targeted a number of IXP interfaces from vantage points we think the IXPs, and we measured that the 99% of the local peers have less than 1 millisecond added delay. Okay this is something than more expected. However for 40% of the moment peers, we have a RTT less than 10 milliseconds and specifically for the remote peers, we have less than 1 millisecond RTT. So you can notice that if we take into account this methodology, we can approximately miss almost half of moment peers.
Also, this methodology does not work well with wide area IXPs. A wide area IXP is geographically distributed IXP which posts infrastructure in multi‑facilities in different cities or even countries. We consider a wide area IXP member as local to this IXP independently in which location ‑‑ actually depending on where it's located. So, we made also an experiment. We actually took some RTT measurements between the facilities in which the net IX, an example of a wider IXP is located, and we found that for the facility of the delay, we have that for 87% of the cases you have a median of more than 10 milliseconds RTT. I should mention here that this is not just a single connect case. Actually in our datasets, we have about 14 percent of IXPs asks where they are the IXPs.
So what we have here. Actually we propose a new methodology, it's a first principles approach, and we build this methodology based on five design aspects.
More details about this.
Firstly we used port capacity values. The idea here is is that fractional port capacities can only be purchased through the remote ping sellers. This means that if we see low port capacities, this information can indicate that the IXP member peers remotely.
We used RTT measurements to approximately estimate the distance between the IXP and the member we used co‑location facilities information. The key idea here is that an AS cannot be local to an IXP if both are co‑located at least in one common facility.
We introduced the multiIXP routers. This means that an AS can connect multiIXPs using only one border router.
And finally we use private peering links. The idea hers is an AS can also have private peer links with other IXs in the same IXP facility.
Now based on this five design aspects we build our methodology and we implemented four main modules. I have to say here that in order to make a successful inference, it is not necessary to go through all our ‑‑ all through the four modules. Actually we have an inference for one module. We stopped the aggregating and we go to the next member. Otherwise we go to the following module and so on.
So, in the first module now, we use the port capacity values that we have collected from different databases, mostly publicly available or even IXP websites. And what we do here is, we check if the port capacity value that has been assigned to the member is less than the minimum port capacity as reported in the section in the IXP's website F this is the case, then we infer that this member is moment. Otherwise we go to the next module.
In the second module now, having in our hands are the measurements, we tried to approximately estimate the area in which we expect this IXP member is located. If in this area we have also facilities in which both the IXP member and the IXP are co‑located, they will refer this IXP member as local. Otherwise we refer to it as moment.
In the third module now, firstly, we try to identify if this AS has a multiIXP router. Remember a multiIXP router means that an AS with one border router connects to multiple IXPs and we try to figure out if this IXP router is local or remote. For example a local IXP router means that the AS is local to all the involved IXPs.
In order to have a remote multiIXP router we need the AS has to be referred to as moment AS at least in half of the IXPs. In previous modules and of course all the involved IXPs have at least one common facility.
Following the same process, we can infer if we have a local multiIXP router.
Here I have to say that we can also stand on hybrid multiIXP routers, this means that for a subset of the involved IXPs, they as a member can be moment remote, and for the rest of the IXPs can be local.
And in the final module. We utilise all the private, we tried to mark these private links into a certain facility for a certain AS and then we try to see if this AS has several private links with other AS noose this facility.
Then if this is the case, we consider as ‑‑ we consider this AS as local to that facility. If this this facility this AS has also an IXP peering and this IXP is co‑located in that facility, then we consider this maybe as local, otherwise as remote.
Okay. After describing all this research, the question is does it work? Based on our graph to date, we managed to validate this methodology and the news is quite good. It works, we managed to succeed about 94% accuracy and 93% coverage in our results.
Now, as a following step, we tried to analyse the remote peering system applying our methodology. For this reason, we useded third largest IXPs in our datasets, and based on our methodology, we found that 10% of the inferences can remain only using port capacity value. Of course the second and third module offers majority of inferences. And finally, we have found that 25% of the multiIXP routers are connected to more than 10 IXPs. Actually, this is an interesting finding, because highlights a misleading indicator of resilience because you will notice that all this in the connections depends only, can actually, depend only in a physical equipment.
Concerning now the inference results. We have also found that one out of 3 IXP members peers remotely with an IXP. 90% of the IXPs have at least 10% of their IXP member base as remote. And finally, 3 of the largest IXPs in the world, DE‑CIX, AMS‑IX and France IX, they have approximately about 40% of their members as remote.
Now, some of the features that we also tried to analyse and compare the remote peering against the local peering. We analyse the the growth rate. For this region reused historical trace route data for five IXPs in a time window of one‑and‑a‑half years. And we have found that the IXPs growth is mainly driven by more peering, which contributes two times more than local peering. However, we have noticed that remote peering also exhibits higher depart rates than the local rate. We have found finally, they have switched to local peering.
Some other features that we try to analyse about remote and local peering. We actually analysed the total traffic levels that have been reported in ping dB for each IXP member and here you can see in this chart that for both local and remote peers we have similar distributions for the actual fractions of local versus the remote peers are larger per traffic level. We also analyse the officer cone sizes based on K DOS datasets. Again you can see here similar patterns between local and remote peers, however, concerning the hybrid peers, we see one 4th ago attitude larger customer cones, this happens due to the fact that here we have large networks, geographically distributed. Of course with a diverse peering model probably.
We also tried to analyse the routing implications of remote peering, this this reason we made an experiment. We actually ran traceroutes from every remote tier to any other IXP member, again in DE‑CIX in Frankfurt, and we found that for 66% of the cases, the traceroutes crossed the closest IXP to the remote peer.
However, for 44% of the cases, even if the remote peer and the IXP member had as alternatives other common IXPs closer to the remote peer, finally the remote peer didn't decide to off load its traffic through the closest IXP.
Last but not least, here we introduce our new system, and here actually we tried to visualise all this kind of remote and local peering information. At the top we have a link, it's a demo you can start to get familiar with that. I have to say for now you have only posted data for AMS‑IX. This is actually a portal which in the future it will support some filtering mechanism in the IXP and facility level, and of course rest API. And what we see here. On the right side we have a list of the facilities. Of the select IXP in which this IXP is co‑located. And for the query' edge we have a local inference. And this local AS for that local IXP is present in the green facility we have annotated in the slide.
We have also here an example of a remote peering inference and we see that this time the remote peer is located in the green facility.
To sum up. In this work we produce ‑‑ we introduce a new accurate and quite promising methodology, we see that the remote peering service becomes quite popular, and finally, we plan to make publicly available soon this new system.
As future work we plan to conduct a longitudinal study including many nor IXPs back in time to investigate if this remote peering is an actual trend and just a recent development of the remote peering ecosystem. We hope to ‑‑ the community can benefit from this study, even the IXPs, to overcome let's say, I don't know, the local saturation and expand their markets somewhere else.
And finally, we plan to make a traffic analysis in order to see the actual traffic levels that come from remote peering.
So this is it. This was my presentation. Thanks a lot. I think we are ready to go for some questions.
CHAIR: Thank you George. So, I think we have some questions that appeared. Anyone? From the chat.
AUDIENCE SPEAKER: Hi, I'm Gergana and I am the chat monitor for this session. There have been a few comments and questions in the chat.
There is one more of a comment.
In our case is 42541, we have our Amsterdam IXP ported directly to our Amsterdam Copenhagen wavelength, aka do it yourself remote peering, since all our customers are in Copenhagen it doesn't hurt any traffic.
So that's more of a comment I think.
Then there is also a question for the presenter.
The work is motivated by the will to improve peering transparency about remote peers, why is that so important to know if a network is remote or not, connected to a reseller or not? Are there any risks linked to that?
GEORGE NOMIKOS: As I said at the beginning of my presentation the goal is transparent. It's up to the IXP operators and the IX members and IXPs what they can do having this information. From the IXP's point of view, as I said, they can benefit from this work for their business model. For the members, IX can benefit from the case that if they see some lower performance, to divest their traffic engineering for instance.
AUDIENCE SPEAKER: Gergana: I have another question. First a comment and then a question.
The presentation seems to be biased against remote peering. What we SOA in this presentation this accounts for very little traffic and port utilisation which suggests that remote peering is used either for redundancy, not primarily and/or for a committees before becoming local. So that very much of a bad thing?
GEORGE NOMIKOS: The point is to uncover moment peering. This was the difficult stuff of this work, because in order to infer someone as local, I think it's something more straightforward. I don't think that it's bias. This is just an alternative solution, more effective, more accurate, comparing what actually there is out there in the literature.
AUDIENCE SPEAKER: Gergana: I also have just a few comments actually on the chat. Somebody commented to the person who was asking, if he could indicate whether they really believe 40% of the connections to the example large IXPs given is connections for redundancy or test connections. As far as I can see from the chat the person has not answered.
Then there is another comment, if you want to peer with, for example, NetFlix, you often have to be connected to an IXP far from your user base. So that's just a comment as far as I can see.
And another question, as per previous works, the methodology is based on RTTs. In the future, IXP database will gather members information from IXPs to populate the database. This will make it easier to find out where connected members local or not and who is connected via the resellers. Will you adapt your methodology to make use of this tool?
GEORGE NOMIKOS: Actually, I didn't understand the initial part of this comment. You said that the comment is based, the methodology is based on the RTT.
AUDIENCE SPEAKER: Yes, it's an abbreviation.
GEORGE NOMIKOS: No, this methodology does not dependent on the RTT. The RTT is used only for the approximating the area. After that we utilise a number of different heuristics in order to have a final inference, this is actually the main difference of the prior research work that they only used RTT measurements and of course they missed so many ping links.
AUDIENCE SPEAKER: All right. And last, I think it's a comment not a question, but, if you wanted to start accepting PNIs in Amsterdam IX we would appropriately only put a switch in Amsterdam and still do routing in Copenhagen.
That's it for now. Thank you.
AUDIENCE SPEAKER: Giovanni. Thanks for presentation and measurements, very interesting. I have a question about Anycast. So, with Anycast, you can announce the same IP address for multiple equations across the globe and I work for a DNS operator so that's what we run on DNS. And I wonder, sometimes you want to have insight on peering and certain sites to know if it's better to deploy over that site and use Anycast site or not. I wonder if your methodology works with Anycast or if it accounts for that or if you have any insight into that.
GEORGE NOMIKOS: That's a good point. This point is actually a future work, but ‑‑ but I'm very sure that the remote peering can affect actually Anycast, because it seems local but it doesn't, so it redirects the traffic actually far away from the CDN.
AUDIENCE SPEAKER: Okay. Thanks.
CHAIR: Thank you. Another question?
AUDIENCE SPEAKER: So, I was wondering how do you ‑‑ I am Tom from CloudFlare, sorry. I was wondering how will your methodology deal with an IX that has a panning fabric across multiple cities, like the peer might be local for the city but is not local on the IX because their latency is 20 milliseconds, but it's local for most of the peers in the same city. You are just on the same fabric.
GEORGE NOMIKOS: Yeah, if you are on the same fabric, yeah, you can consider this maybe as local to the other ‑‑
AUDIENCE SPEAKER: But your current methodology would show that it's remote I guess because the RTT is high.
GEORGE NOMIKOS: If I have an IXP and it's a wide area IXP, this means that ‑‑ like an L IX, it's considered like a unique entity around the world, this means that the IX member, based on our methodology is local. On the other hand, DE‑CIX Frankfurt or DE‑CIX Munich, it's not a wide area IXP, it means that if an IX member is local DE‑CIX Munich cannot be considered local also DE‑CIX New York. The difference is in the first situation we have an IXP like one entity and the other case we have model back space, okay, in one organisation, but different entities.
AUDIENCE SPEAKER: Thanks.
CHAIR: Okay. Thank you. And the last question.
AUDIENCE SPEAKER: Hello, I'm Andy Davidson. I have a question relating to the research that you did where you looked at a number of traceroutes that went to distant paths when a closer path otherwise existed. I think the statistic was around 60% of traceroutes used a path that was longer when a shorter one existed and had been built by networks. Are you interested in making your research available to those affected and misconfigured ASes on a per AS basis? Because I think that, in this room in this city we have accidentally created this Internet that's worse than the one that we had before remote peering existed and if we're going to do something about this, this shameful thing that we have sold, then your research looks like a great piece of work that we can use to start to make it better again and keeping the traffic local.
GEORGE NOMIKOS: You are absolutely right. This is just an observation. Of course as the next step we can also try numerous other IXPs or in a larger time window actually.
AUDIENCE SPEAKER: I appreciate the work. It's very good. Thank you.
CHAIR: Thank you.
(Applause)
So now, I would like to remind you to please rate the talks, and now I will call Andy that's going to talk about MANRS for IXPs I guess.
ANDY DAVIDSON: Hello. Thank you for inviting me to share some comments and thoughts about the MANRS initiative. There is quite a lot of useful and interesting information about the MANRS initiative that's been published but I wanted to share our points of view about what we receive MANRS as and why we did that work and potentially also look at some examples of how we did this work as well that might be interesting to other Internet exchange points.
First of all what is the MANRS initiative? How did it start? Why does it exist? MANRS is a statement, a group of actions that carry a networks first of all, ISPs and carrier networks, to demonstrate their shared commitment to a collective culture of responsibility for Internet resilients to make it a better and stronger Internet and for security the routing system. And the MANRS initiative started out as a set of actions which you can do as a carrier network, as an ISP, to apply a relatively simple minimum level of best practice at the inter‑domain border and you had to do a few things that were ‑‑ that were good practice, but a manageable amount of things to filter the spread of incorrect routing information, filter traffic with spoofed source IP addresses and get involved with some kind of cooperation with other network operators at events just like this one, and at mailing lists like the one that comes with this Working Group and your regional network operator group for example, collaborate with other network operators who are interested in Internet resilience and routing security, to cooperate and improve each other's networks.
As I say, this is intent, this document, is a set of actions that, if you follow the Internet, will benefit, and this work was initiated and coordinated by the Internet Society, who very kindly took the lead on producing these actions.
MANRS for Internet exchange points, well we are not ISPs, we are not carrier networks and these routing actions only apply to those dirty carrier networks that we have have nothing to do W we will run clean, pure, honest, Claire 2 ethernet domains only. So the end of the presentation is we can continue to do no work at all. Thank you.
Actually, if that was ever true, I think today it's no longer true. If it was ever the case that the IXP was a simple clean Layer2, actually it's not the case and it's why Internet exchange points have also got together to do some work under the MANRS initiative as well.
IXPs are important partners for ISOC and the carrier networks because they tend to provide a focal point for collaboration between network operators. They are often useful venues at which the coordination of regional Internet development and security can take place and education and learning can happen.
Additionally now, almost all IXPs operate route servers, Layer3 services like carrier networks and therefore must be secured in the same way. And that's before we even consider the IXPs, it's important that IXPs demonstrate good Layer2 hygiene in order for the security and the reliability of the Internet to continue.
So there are different actions. You remember I explained that carrier networks have a set of actions relating to carrier and ISP services. MANRS for IXPs is a set of actions that IXPs should follow in order to be MANRS members and MANRS compliant and those are to prevent the propagation of Internet routing information at our Layer3 borders, i.e. the route servers, which is mandatory action. In order to be signed up to MANRS you need to comply to that one. Promote MANRS the wider initiative within your membership or customer base, that's also a mandatory action. And then a number of optional actions in which you must adopt some of them. Protect the peering platform. Facilitate operational communication between network operators. And provide monitoring or debugging tools to your participants, your members, your customers.
The key one, the one that I have some examples on later is preventing the propagation of incorrect Internet routing information. Essentially, I think this is extremely important because an IXP operator operating a route server has the same burden of responsibility as a Layer3 carrier, a transit provider, and ISP. We have the same burden of responsibility as IXP operators not to spread false wrong insecure routing information as an ISP does. And I argue this from the point of view that no customer facing BGP relationship should be unfiltered. So if you are a transit customer, you just filter the transit customer. If they are an IXP participants connected to the route server and you are going to provide that information, that connection shouldn't be unfiltered. It's the same as a carrier BGP customer relationship.
The other reason it's important that IXPs should do good route filtering on their route service is we often sell it as a way that ISPs, our members, our participants, our customers, can out sort good quality hygiene, route filtering between peers on the exchange. So we better get up and do that work.
So far, there are 24 Internet Exchange points who have signed up to the MANRS initiative. You can see a list of them if your IXP is not on that list, hopefully you will want to make this, 25, 6, 27 this week and look at some of the deck next and options that I'll talk about in the second half of this presentation next. Hopefully you'll be next. .
We are an Internet Exchange point operator. Why did we at Asteroid adopt the MANRS initiative? First and foremost we wanted to be good Internet citizens, it was the right thing to do to configure our networks, our IXPs as we intended for them to be stable reliable platforms. We think it's the right thing to do if we're offering a public Internet service for this to be done as good Internet citizens.
Not only that, I don't really like dealing with tickets. So, it reduces the likelihood of emergency support incidents because because if we configure the networks to be secure there is a lower likelihood of a security issue that needs intervention at inconvenient times. It reduces the likelihood that we have to do work especially at inconvenient times of day.
Also, using the MANRS initiative to be a guideline for how we configure our peering ports and route server configuration etc., it increases the confidence in automation, because if you're planning to do a project whereby you are you automate some of the work that you do. If you can look at a document and a template by explains doing it this way is a good idea, it will increase the confidence in your automation.
And actually, the barrier to do this work was relatively low. We had already done quite a lot of the work, so we thought it was a good idea to sign up to the initiative on the basis of that.
How did we implement it?
Here is an example of our automation. We didn't have to ‑‑ we already had this in place before we started this work. This is a screen grab from our Ansible system that rolls out route server configuration and I show this because it might be useful to people doing similar work because the way that we implement it is to ensure that our build scripts does not build a peering session facing a route server customer if cannot generate a prefix list for that customer. I.e. the route flag in the database must be set to true, i.e. the customer wants, intends for us to build this session, which reduces a risk of accident. The AS macro is defined in our database for that customer, so they have communicated to us a macro that we should use to build filters against. But also that that macro expands to a prefix system at least one prefix. So if the prefix list is wrong or ‑‑ the routes are accidentally withdrawn, the peering session will not be built. So if somebody changes their configuration and removes their prefixes by error or something like that so that there is no prefixes, the session will go down and alarms will be raced and things like that. We try and fail safe and it's one of the ways we do that. So a prefix must be defined in order for a BGP session to be built and we will only accept prefixes on a route server session if they are registered in IR D P or actually RPKI as well, to build that session.
How do we protect the peering platform? We publish a policy, we publish an A U P which describes what's allowed on the peering LAN and then we use two things to enforce that policy. First of all port configuration, that tries to drop traffic like link layer protocol, LDP, spanning tree frames, we try and drop those if we can, if the switch can do that. If we can't, then we have scripts on the collector that look for prohibited traffic that peers to have reached the peering LAN and respond by writing a ticket to the customer and help them fix their config, we also use Mac port security, so if we see too many Mac addresses on the port so ensure that a customers's own restrict is not ex possessioned to the peering LAN, we'll shut the port down, again fail safe.
We also don't announce the public peering LAN as a way to try and also restrict outside traffic from hitting the LAN.
Another one of those actions is to provide a Looking Glass, we didn't have a Looking Glass at the beginning of the project so this is what we had to do. Because we already used Bird watch here which I think is a hackathon output from a previous meeting, I think, we were able to look at some previous hackathon projects as a way to get information out of BIRD. And that's what this Looking Glass uses for realtime information. We were able ‑‑ we produced a Looking Glass service, so it was the piece of work that we had to do in order to become compliant with the MANRS system. But fortunately somebody had already written one so we used that. It's Open Source.
Being MANRS compatible is, MANRS compliant is entirely compatible with the values we use when we run our exchanges. It's a lightweight set of actions that's good to follow, it's worth following these actions anyway because it improves the quality of your products. So they are efficient, lightweight requirements.
It's simple to, if you have automation, we automate everything that moves. It's actually easy to deploy into our automation. We didn't suffer any cost and yet there is still a wider benefit to the work. And signing up to this initiative and encouraging others to do so, encouraging our customers to follow the MANRS initiative for peering networks helps to encourage that trustworthy collaborative cooperation between networks and IXPs that we want to take part in as well.
And as a result of doing the work, once it became embedded in our entire product, because we automate, we did the work once, it's available everywhere we are going to run exchange points. If you have our white label product, then it will be MANRS compliant and at public exchange points, Amsterdam here that's live now and Mum Bass a that we're building now, those exchange points are automatically MANRS compliant because we built that into our scripts and systems.
I'll leave that there. If there are any questions about the MANRS initiative, why, how we did it, you can speak to me afterwards or you can ask some questions at the microphones now if you wish, I'd love to talk to you more. Thank you.
(Applause)
FLORENCE LAVROFF: All right, any questions?
AUDIENCE SPEAKER: Hi, I am Vesna from the RIPE NCC, I am happy you used one of the projects from hackathon from the ones that we did in the past and if you are interested to develop more tools together with the community, we would like to maybe hold a hackathon together with you and work on this. So let's talk about it later.
AUDIENCE SPEAKER: Hello. Andreas. GRX has already joined MANRS and I would like to confirm here that there is a five minute job for an IXP who is already doing this stuff, and most of you, most of us already doing this stuff, so there is a five minute work to join MANRS, you just need to put up some information on your website and fill in the form. So if you are already doing this, please go ahead and support MANRS and if you are an IXP who doesn't support this, this again you should join MANRS because this will help you become a better IXP.
Having said that, we also consider incentive to our members who also join MANRS, but what we miss here as a feature is that we would like to have some sort of periodic auditing to the members, that they indeed keep these... keep doing what MANRS describe. So it is not a whole adjustment in the past and they will have a discount forever and we need also some information which is the data that they joined MANRS and the day that they left so that we will be actually able to give some sort of discount. So, this is something that we would like as a feature by MANRS.
ANDY DAVIDSON: Okay. I don't know if Andre perhaps might want to comment on it because I feel I can't speak authoritatively for the work that and Roy behind you is doing on the MANRS for carriers, but you might have an answer on that question. If you want to speak.
AUDIENCE SPEAKER: Thank you for this question. Those requirements actually are well recognised and the MANRS community working on measurements, I presented some of this stuff in the MAT Working Group, I also sent our measurement framework that we are planning to launch this year to the MAT Working Group. The idea is to build a MANRS Observatory and ultimately expose some of this data publicly so people can assess the level of MANRS readiness for MANRS participants. Also we are working, if you can specify your requirements on this kind of API to access the list of membership, that would be helpful because we are also working, we redesigned the website. It has a basic API to allow to you to get the membership data but maybe some of the fields we need to discuss what you would like to see.
ANDY DAVIDSON: I did see the website. I think the website at the minute is the new one, because yesterday I saw it, it's easy to use and a good piece of work.
AUDIENCE SPEAKER: We have basically PI built in but we can tailor this to the needs of IXPs so other parties that would like to get the membership list.
FLORENCE LAVROFF: Thank you. More questions from the room? Remote participation? Do we have anything? Okay, all right. I suggest we move onto the next topic on the agenda. Thank you Andy.
(Applause)
And our next presenter is Nick Hilliard from INEX.
NICK HILLIARD: Hello everyone. I want to talk to you about RPKI on Internet exchange route servers.
I am going to precede this by saying that we haven't implemented RPKI yet. We have thought about it, but we haven't written any code yet, so these are initial thoughts rather than a finalised product or something that's going to give feedback on what's actually happened. We will do something along these lines relatively shortly I think, and at some stage in the future there is going to be a feedback process.
It hasn't happened so far in general that Internet route servers have implemented RPKI. This is actually a lot of reasons and I think this kind of comes down to the way that that software and protocols evolve over time from being sort of a rough and ready tools, you know, to having all of these kinks ironed out and event leave all of a sudden, and we seem to be here at this stage that all of a sudden things sort of converge and it looks like it's the right time to do this.
There's been a lot of historical difficulties with implementing RPKI at route servers. The main one was that most Internet route servers run Bird, and Bird version 1.X didn't really support RPKI properly. It supported ROA tables which meant that you could take an RPKI validator feed and you could then write out a list of ROAs into the configuration file. But it was kind of a Hackey way of doing it. This has been fixed in BIRD Version 2.
Now, there are other route server implementations which support RPKI, in particular the router protocol which is the live validation feed to a validator.
But for various reasons, those route servers just aren't as widely used as BIRD. So, there is a list there, I'm not going to go through the list because I hate reading off slides. It's just one of those things you can look at later.
Validator software. This is something that's improved hugely in recent times, because the RIPE NCC has released the RPKI validator version 3.
This is incredibly easy to set up. It took me, on a test bed system, more time to fix my firewalling rules than it did to actually set up the VM in the software. What this says about my firewalling rules are a bit ‑‑ it's a bit awkward but there we go. It should have been a bit better because the firewalling was technically handled by orchestration, which is even more embarrassing in other ways, but there we go.
But this is I think I'd just like to hand a lot of accurate to the RIPE NCC for fixing this problem and for making it so easy to do this.
There are very modest VM requirements. You set up a Centos or an Ubuntu VM, put in a couple of gigs of memory, download the software, type in yes when it says the ARIN T AL, because they are a bit special and they need explicit permission for downloading their TAL. And this is all about like lawyers in the US and you know, it's a bit difficult. Anyway that's a separate discussion which I'm not going to get into here.
But this is incredibly easy to set up and it only takes a short amount of time. It has to be acknowledged that there is a difference between setting up a test bed system, a pilot system, and an actual production system. But, it does look like the sort of software that could be turned from one into the other with a relatively low level of understanding and from a production deployment point of view, I think this is really important.
ROAs. There is a variation between how easy it is to create your ROAs. Obviously if you want to have your own TAL and kind of go out into the Internet, you can do that. But if you want to use the RIRs, well that's very easy. I mean in the RIPE NCC and a whole bunch of other RIRs, you blog in, you kind of click okay a couple of times and then this ROA PoPs out at the end of it and it's really very simple. It's a little bit more involved in ARIN. You have to open a ticket and request e‑mails but it's not terribly difficult. This assumes by the way that this is regular IP address space. If it's legacy resource space you have to engage a little bit more with the RIRs. And in the case of the RIPE NCC, you have to have some form of relationship and the relationship mechanisms are pretty flexible. There is a variety of different ways, but essentially, in the RIPE NCC service region, any sort of engagement whether it's through a sponsoring LIR or through anything else will get you RPKI capabilities.
In ARIN land and I don't want to sound as if I'm picking on ARIN here, but these are all bumps that need to be ironed out before RPKI is really going to work. If you are in the ARIN service region, you have to sign the legacy RSA which causes a lot of people a lot of indigestion. That needs to be sorted out.
AS paths. This is a difficult area. At the moment, RPKI supports prefixes only. It does not support AS path validation and it turns out that AS path validation hasn't really gone past the stage of defining a list of sort of what to dos in the IETF. It is a to do list published as an RFC, and it's quite a substantial amount of work.
There is also no mechanism to support AS path sets. And this also causes difficulty, because when you are list engine to a set of announcements from a client, and they suddenly decide that they are going to announce YouTube prefixings with the YouTube ‑‑ with a faked origin ASN, if you blindly accept that, well you have just accepted an invalid announcement, so this needs to be sorted out. Now there is a draft in there, draft RPKI AS cones. It's pretty early in terms of the development of this, so it's going to be several years before we see that implemented.
But this is something which is really critically important for implementations.
All right. So, considerations, coexistence with existing implementations needs to be done. There is going to be huge temptation to create policy which is just overly complicated because RPKI gives lots and lots of scope for doing really interesting things, and I think from the point of view of a route server, it's more important to do something in a really simple way and do it well rather than giving lots of rope for people to hang themselves with.
There are open discussions, there are lively discussions about what to do with invalid tags. Some organisations feel that they ought to be dropped. Others feel that they ought to be tagged. This is a discussion I'm not going to get into at this point. But I think for a future talk at a connect, I think there is plenty of meat inside there.
In terms of implementation, there are issues with revalidation. So what happens with a ROA when it changes, and it's say suddenly goes from being valid to invalid. Most RTR implementations on route servers don't actually do dynamic revalidation. So this is something that needs to be handled.
We do need a consistent approach for handling RPKI invalids because I think one of the biggest things that wrecks the heads of organisations which connect into IXPs is when they have 20 different IXPs and 20 different policies for handling route server policy.
So this is how I think we're going to do this in INEX. It's going to be enabled on a per client basis. The first evaluation criterion is to compare against the IRR AS paths because we don't have an equivalent in the RPKI yet, and then if it's invalid ‑‑ sorry, if it's not in the AS path list, we'll drop T then there is going to be a very, very straightforward RPKI evaluation. If it's valid, we'll accept. If it's invalid, we'll drop. If it's unknown, we'll pass it through to existing protocol implementations. Which is to say regular IRRdb filtering.
That's pretty much it.
So any questions on this?
AUDIENCE SPEAKER: Job Snijders. I was wondering why are you doing this on a per client basis and not just enable it for all clients without an opt out?
NICK HILLIARD: Because this is an implementation, an early implementation. I love your tie by the way. Is this a requirement for your new job?
JOB SNIJDERS: It's an RPKI tie. And unlike the ARIN tie, it can be freely distributed. So, I'd like to share some experience. I am a volunteer for the Calgery Internet Exchange, and about two weeks ago we enabled RPKI based origin validation on the route servers on open BGPD and so far this has proven to be a successful concept and nobody has asked for opt out or any other thing, so. I would like you to consider this and just do it for all clients.
NICK HILLIARD: Okay. Good point.
AUDIENCE SPEAKER: I am an operator of a very small network that is connected to a lot of Internet Exchanges.
I have a comment about the BIRD 1.0 and RTR validation and so on. There has been a tool out for a while which was sort of CLI based and sort of nasty that took a connection to a validator and then connected it back to BIRD. Earlier this year I took the liberty to improve on that source code to actually turn it into a full functional demon with everything you'd expect it to be so you can actually use that to get life integration into BIRD 1.0 for RPKI. So, please have a look at that if you are interested and if you are an IX that is hesitating to a full on migration to BIRD 2, there is the fantastically named BIRD‑RTR /CLI which is now no longer just CLI. Thank you.
NICK HILLIARD: This is something that we are aware of. I didn't put it into the talk because there are lots of patches for this piece of software, that piece of software to kind of Hack stuff in, but this was all about kind of main line, what you get with your standard distribution. So it does exist, but I didn't include it deliberately.
AUDIENCE SPEAKER: Geoff Huston APNIC. Unfortunately, I go to way too many of these meetings, as does Job Snijders, and what he said at NANOG made a lot of sense in relation to what you are trying to do here. That what he was proposing there, and I'd recommend anyone to look at his slides from the routing security session was to actually pull the IRR feeds through a ROA validation phase and drop the things that a ROA is saying is really bad. Have a look at it. Listen to the audio and think hard about what you are doing against Job's approach. I happen to like the approach. Well done. So, good idea. Study it.
Secondly, we have gone a long way down AS path validation in the BGPSec protocol. So far down that it's undeployable. That doesn't mean it hasn't been standardised. It has. But it requires so much heft and weight that no one is willing to deploy it it in the way that it needs to be deployed. It's unlikely we are ever going to get to that point and so the next thought bubble is do we need AS path validation. And I'll leave that open. It's possible we don't. But we may need to be a little clever err.
Last and not least, the whole ARIN thing. There is no doubt we live in a litigious world and there is no doubt that through the actions of an RIR, and I happen to work through one. I could cause an enormous amount of damage in the routing system through nigh negligence. Obviously it makes me nervous. But the real problem is that lawyers go hunting for entities with money and sue the pants off them. And the real problem is, the size of the problem is much greater than the size of the reserves any of the RIRs have and it becomes existential threat.
Now what the NSF has done is actually funded a study by Christopher Hugh of the university of Pennsylvania, who is a lawyer, who is actually doing a study on the legal barriers to RPKI adoption and it's actually a deeper study. Telephone companies used to have indemnification from the State. You lose your phone, get stuffed we're not interested, go sue the government. But we're not like that. We have no backstop here. We're exposed. And so to what extent all of our assets, the entire address registry, is at stake if we muck up, scarce a lot of us. ARIN's response was the best effort they had to try and address that issue to some extent within the framework of US law. RIPE has similar indemnification, so does APNIC but they don't require you to click through. What's the best answer? I'm an engineer, I don't know. But we really should get some help in trying to make sure that when we do this we are not putting everything at stake if we happen to get it wrong and cause a huge damages claim. We don't want. None of us want that, so that's my reaction. Thank you.
NICK HILLIARD: I'm going to comment on one thing that you said. It's just on the ROA pre‑validation thought. This is actually been done by, in A route server, it's quite neat. It has a different sort of evaluation mechanism to using a strict ‑‑ or at least a standard RPKI validator feed. It requires a little bit more work. But there are ‑‑ there are a good reasons as to why you would choose one over the other. Neither it better. So, it's ‑‑ yeah, I think this is something that probably ought to have been thrown into the talk but we didn't throw it into the talk, so E why, but good point. Thanks for making it.
AUDIENCE SPEAKER Andrei Robachevsky. Two questions, one you say when you say AS path validation or do you mean the Koen is set or do you mean full path check?
NICK HILLIARD: Yes. What I mean is that at the moment for regular IRR filtering, we implement checks to make sure that the AS origin matches an AS which is included in the AS‑SET from the IRR. Now there is no similar mechanism available in RPKI. So I think the AS cone proposal is going to solve this. But the AS cone proposal is also several years away from being a mature product that we can actually deploy. No code has been written, nothing has been standardised yet. That's several years ago. In the interim that's what we need.
In terms of pure RPKI AS path validation, yeah... that's quite a difficult thing I think. I take Geoff's correction, that it's a little bit further down the road than I thought it was. But we don't have any software to do this yet.
AUDIENCE SPEAKER: And second question is, when you talk about implementing those thoughts, I assume that you are going to implement this in the IXP manager?
NICK HILLIARD: Yes, it will be freely available.
AUDIENCE SPEAKER: Do you have a rough timeline for this implementation?
NICK HILLIARD: Oh my God!
AUDIENCE SPEAKER: Not commitment.
NICK HILLIARD: Whatever I say at a microphone will be used in evidence against me. I would like to say soon, but we have quite a large backlog of features that really need to be done. RPKI is actually quite high up that list of features and there is ‑‑ I have even been in discussion with a bunch of other Internet Exchanges who have made it very, very clear that you know, this is something that they really need quite soon. So, we're going to try and get it done as quickly as we can.
AUDIENCE SPEAKER: Maria ma DNSKEY a, cz.nic. I'll say just a little statement. We are aware of the problem with RPKI revaluation, and we have the commendation for the 2.0 version, and we are currently implementing the structure to enable RPKI reevaluation, but it will take several months to get into production.
Anyway, if there is anybody who is interested in this new feature, please contact us. We are here, me and my colleague behind me in the blue T‑shirt.
NICK HILLIARD: Thank you very much. It's actually relatively straightforward to work around if a hill bit Hackey. All you do is you do a daily process to reload all incoming BGP sessions and that will cause a reevaluation. A little bit Hackey but it can be done in the interim and that's what we would anticipate doing until there is proper support in the software.
AUDIENCE SPEAKER: Brian NIX son, go daddy. In the IETF area, there is another piece of work or a couple of pieces of work that may be interesting, may be capable of doing some of the stuff that the AS cone can achieve and get 99% of the way there I think, and that's the open parameter where you, between two ASes you establish what kind of relationship it is, peer or customer transit, combined with a route leak detection and mitigation mechanism. And once you have that, other that somebody maliciously mucking with the actual announcements themselves in detail, that, combined with the ROA stuff, I think gets almost all the way there in terms of protecting the routing.
NICK HILLIARD: I'm not sure if it does. I need to look at that draft again, because I know the draft you're talking about and it's something that I have got up in my podium and ranted about it because I think it's a little bit ‑‑ I think it's probably a little bit too simplistic in its approach towards Internet routing mechanisms and you know, if we were to look at it ten or 20 years down the road, would this end us up in the sort of place that we would want to be? And I don't know. But I take your point, I'll have another look at the draft in this context and...
AUDIENCE SPEAKER: The draft needs some work, I need to do some work on it with authors, but yes.
NICK HILLIARD: Thank you.
AUDIENCE SPEAKER: Peter Hessler from the open BSD projects. One of our sub projects is open BGPD and we have a new release coming out tomorrow coincidentally and I'll be doing a short lightning talk about the improvements we have done in open BGPD and to spoil it a little bit we have implemented RPKI and ROA sets.
NICK HILLIARD: Great. Thank you very much.
CHAIR: Before we move on we are checking wifi no questions from remote participation. Okay. Thank you Nick. Please rate the presentation.
Applause)
All right.
FLORENCE LAVROFF: All right. So, for the regular here, you may have noticed that this is becoming a recurrent slot in our Connect Working Group agenda. We see some value to have a slot to give all the news interconnection related in our great interconnection world. So if there is anything else you feel should be on this slide, feel free to get back to us at the mic after this session and also put things on the mailing list and we will be able to update that. Thank you.
So, just to go rapidly through the slides. The first information that I would like to highlight here is regarding peering B D. So the PeeringDB folks are rebranding and going Open Source. So in case you are wondering why we had no PeeringDB update peering this Working Group session, well now, you know, it's because they are very, very busy right now and we will have the great pleasure to welcome them in the next Working Group session.
There was a presentation that was made on the various peering events that I would like to crypto currencily mention here.
There is one about the detection of peering infrastructure outages which will we will remind you some work which has already been presented in this connect session at RIPE 75 in Dubai. So, you know the usual suspects. Vassilius, Christoph and Emile.
Then of course I wanted to refer you to the presentation presented during the last EPF. From Job about RPKI and the role of the IXPs. And finally I would like to close this brief list on interconnection update about the French market which was pretty useful because it's been sometime that we didn't have such a comprehensive presentation, and this is from Sammy Swissey from the regulator.
That being said, I would like to hand over the mic to Bijal who is going to more into details for everything which is IXP related. Welcome Bijal.
BIJAL SHANGHANI: Okay. Hello everyone. I'm not going to be doing my usual EURO‑IX update. We have done this before, but it's been a while and I think it's nice to bring it back.
So, today I'm going to give you some news from the EURO‑IX members. A couple of weeks ago I sent a mail to our members mailing list and asked the members if they had anything they wanted to share with the Connect Working Group. So, here we go.
Okay. First of all, from Moscow IX, they are transferring to a multi‑service platform. I'm not going to read, you can read it yourself. But the key points are, and they have just launched a new data centres, M 9 plus which was one of the most popular ones in Russia. And you'll see so far they have had 40 participants who have used both the co‑lo and connect solution that they run.
GR IX plan to launch a new POP in Tessalonaki ‑‑ which is the second largest city in Greece and this will hopefully make connecting into Greece a little cheaper.
Interlan, Interlan has now 40 gig and 100 gig available in both Bucharest and Frankfurt. And some news from DE‑CIX. This is a new IX coming in Lisbon soon. They now have 10 plus enabled sites. 200 of the new access points across Europe and they are also working on new automated provisioning features. And I think there is a video on the website that you can look at which gives you details about that.
And that's it. So, thank you.
CHAIR: Thank you Bijal.
(Applause)
And now we have a short update of Thomas King regarding the renumbering in DE‑CIX.
THOMAS KING: Welcome to the talk. My name is Thomas and I will give a quick update. I want to give you a quick update on what we have to do in New York. I'm just talking about DE‑CIX New York so just be aware it's just that, not Frankfurt, because we have to do a renumbering project for DE‑CIX New York, and who of you is connected to DE‑CIX New York directly or remotely, it doesn't matter in this case? Who is connected? I see a couple of hands. So, it's interesting, especially for you guys.
So, what had happened at DE‑CIX New York, here on this graph you see the growth of the ASes connected over time at DE‑CIX New York and we have nearly reached 200 ASes which are connected to DE‑CIX New York, which is a great success. But if you look at the IP peering LANs, it's just a /24 which means we have only 256 IP IP addresses which we can use to run the peering LAN. So, if we forecast the growth of DE‑CIX New York for the future, we see, and if you were to use also the available IP space for the IPs, we have to use for the operation of the IXP, so for instance for the route server and for the monitoring, we see that sooner or later we will run into an issue in terms of we will run out of IP addresses. This is not a great thing to happen. So this is why we decided to have to re‑number or peering LAN.
And we were in contact with ARIN already about this renumbering, so we got assigned a new /22, which will give us some head room for the growth of DE‑CIX New York, because then we will have ‑‑ we have it already ‑‑ we have now a space for 1024 IPs, which is great.
But, what is coming is that we have to re‑number, which means we all, all the peers which are connected to DE‑CIX New York, have to change their BGP sessions and we will do that after the network freeze period after the Christmas time and beginning of the 28th January next year, until the 30th January next year, so it's a three day grace period. We will allow to use the both IPv4 spaces, so the cold used the IPv4 space and the new one, and what we will do during that time as well is we will shut down one of the route servers in the old IP peering space, because this is a wake up call for everybody who isn't aware of what's going on, if the route server sessions go down, you usually get, usually customers call in and ask us what's going on and then we can tell them look we have to do a renumbering project. So, we are in contact with them and we can make sure that they do the changes.
Of course we will have two route servers in the new IP space for everybody to connect to. And we want to ask our customers and peers to adjust their configure during that time.
And I'm nearly done with my two minutes. So the final thing to notice is that on the 30th January, we will block the old IPv4 space. So you will a the BGP sessions will drop which are not altered in terms of using the new IP space. That's pretty much it. Be aware. Plan ahead and do the change and we will let you know many times before that what needs to be done.
So thank you very much for the time and that's it for my point.
(Applause)
FLORENCE LAVROFF: All right. Thank you. So if you would like to rate those presentations, please feel free to do this and we are a little bit every time. It is now time to go to the last spot of our presentation ‑‑ of our session, sorry, which is about the unrecorded off line part of this session for feedback. So, the co‑chair, let's go all of us together on stage.
REMCO VAN MOOK: All right. So here we are. So, the recording is off for this one. And the reason for that is we have had some comments and actually one of the things that this Working Group has been struggling with I am very pleased to say that this session has been better than quite a few of the previous ones, we have a lack of feedback from people in the room during the presentations, and for us as co‑chairs, it is really a struggle to well basically figure out what to do with you lot and what to feed to you and which way we should go forward.
So, one ‑‑ so one of the things we were trying this time around is the option for anonymous feedback which bot used in one of the presentations. One of the other things that we are giving a try right now is an off the record bit, which is this one. So, feel free to come up and say what you would like us to do. Should we pick up different subjects? Should we do more about IXPs? Should we do less about IXPs? Should we talk about data centre interconnect? If anyone wants to talk about that? Feel free to walk up to a microphone. They are there for a reason. And, well basically, just tell us what to do without fear of having this recorded in an archive and people shouting at you later.
AUDIENCE SPEAKER: Ralph yell, former France IX founder, I wonder if you can do something to fix the expansion of peering points into some co‑location space in New York and Paris, I would be grateful to have for, less expensive cross‑connect.
REMCO VAN MOOK: Well ‑‑
AUDIENCE SPEAKER: You know what I'm talking about.
REMCO VAN MOOK: So, in my old job, I tried to fix one of those. I'm not going to say which one. In my new job, I'm not sure if I can fix any of of them. And I think it would be a vast over estimation of the power of the Working Group Chairs to actually have a financial impact on either IXPs or co‑location providers. But I do appreciate the sentiment. Anything that we actually can do, that would be great.
AUDIENCE SPEAKER: Hi. Rebecca stand itch, I am sorry this is a shameless plug, speaking about feedback, PeeringDB has a survey outright now, so please if you receive the survey, could you fill it in and send it back to us and we'll publish the results in an upcoming session. If you haven't received the survey and you'd like it, please find one of the PeeringDB team, we are around, there is quite a few of us here, thank you. Sorry.
REMCO VAN MOOK: We'll let that one slip. Blake.
AUDIENCE SPEAKER: Blake. To address Ralph yell's comment, there is a BoF tomorrow night, from what I recall on connectivity specifically in data centres and I don't remember the specific charter, if you will, of the BoF, but I know it's interconnects and data centres and about whether we are going to talk more about co‑location and connectivity specifically within data centres. That's probably a good venue to address that sort of thing.
Basically we were going to go to the BoF tomorrow, I will go there and I will go and suggest that there might be some space also to come and discuss like the data centre and interconnect issues here at connect if that's something that the BoF is like ready, or the group is ready to go and do, because I think we could find a slot and some interest for that.
Any other comments? Rants?
AUDIENCE SPEAKER: Raphael again. I just saw something on Twitter about RPKI. I think. You should at EURO‑IX force all the members to enable by default RPKI and if you are not, you are not a member any more.
REMCO VAN MOOK: So, maybe we should have the next RIPE meeting we should have RPKI stickers and badges and we only allow people into the room who actually have an RPKI sticker on their badge. Would that be a good start?
AUDIENCE SPEAKER: Nurani: Just some general comments, I don't know if I have any specific construct I have criticism to give.
I don't think it's a matter ‑‑ I don't think we need to have an anonymous session. I don't think that's where the problem is. And I also think that you know, there are general, you know, lulls and you know, things happen and you know, you have active periods where everyone wants to present and then you have ones where you don't. So I don't think it's just a matter of trying ‑‑ if you want to build better agendas, it's also a manager matter of just actively canvassing that.
I do quite like having Bijal throw in some news from the various IXPs instead of having all the IXPs do that individually. If there are particular projects, you know, the IXPs can do that. And then trying to get I think some of the research stuff is very interesting. Sometimes maybe we should canvass some presentations from some of the other regions as well. I know, you know, they are here. And yeah, maybe either a beer, buying or forcing people up could get a few more good presentations up there. So thanks.
AUDIENCE SPEAKER: I would like to thank the RIPE NCC and the LACNIC for the very simplified procedure to sign the prefixes, that's very good. I was struggling a bit more with ARIN and AFRINIC because we are a member of the four RIRs. I have not nest tested the APNIC so I don't know about them, so yeah, good from RIPE and LACNIC for that.
AUDIENCE SPEAKER: I am Andrei. It's more a general comment I think. When we split Plenary ‑‑ well RIPE meeting Plenary in Working Groups, the idea was that Working Group would actually not only present but do some work. And that's what I'm a bit missing, and I am as guilty as anyone else. Sort of work that spans more than just one session, it goes along well, take for example this presentation by Nick today, right, is the group interested in reaching consensus how we should sort of implement RPKI in route server validation, reach some consensus, common ground and implement this in IXP manager? Is it something that a working group can commit and actually, you know, carry on maybe present at the next session the progress. Just a thought.
REMCO VAN MOOK: I mean, we fully appreciate that, I mean there is not a lot of policy work going on inside of connect. I mean there is not a lot of projects going on. We have tried a couple of past. There was one about CDNs that is Florence tried to get off the ground, but the issue we ended getting up in was that you are working ‑‑ it's collaborations between very large and potentially listed companies. So actually getting people who are allowed to speak on behalf of companies to go on stage, let alone collaborate with each other, requires layers and layers and layers of lawyers, which is unfortunate but it's the reality of 2018. So, which is one of the reasons why we are test driving this sort of off the record and anonymous kind of... because we feel that there is actually we know that there is a lot of feedback in this group that is actually not being fed back because of those restrictions. So, that's the exact reason why we're sort of trying bits and pieces and see what works, because in all fairness, we don't know, but we do feel that giving presenters honest feedback even if it's not the best and positive feedback they would expect is actually helpful for everyone.
AUDIENCE SPEAKER: I appreciate that. I don't think that is part of my suggestion. I think there is certainly areas of work that do not required NDAs and stuff like that. I think it's more a matter of commitment and identifying those issues that are of common interest.
REMCO VAN MOOK: Absolutely.
AUDIENCE SPEAKER: Buy Bijal. I think having the session maybe a little bit more interactive and having a panel and having discussions where the audience can also take part would be quite nice and different, because I don't think we have done anything like that in the Connect Working Group.
But I think generally, I think trying to do something which is a bit more interactive would be good. I was just looking around the room and I know some meetings you go to you get to kind of say your name and who you are and where you're from, there is quite a lot of people in the room, so I don't know how long that would take, it's quite nice to hear who is in the room as well.
REMCO VAN MOOK: Bring us a panel discussion, we'll happily host it. We have tried setting up a panel on a number of topics in previous sessions, only to drop them from the agenda because there was nobody actually willing to get on stage and start representing their or their company's views. So, it is a struggle. And I fully appreciate, I fully take your comment, which is exactly why we are standing here right now because we're as lost as you are. We really want to take this forward and find a meaningful format, a useful format for everyone here to have this discussion, because there is a discussion to be had.
AUDIENCE SPEAKER: Bijal, just to add to that, I had an idea, would it be possible to perhaps get, from people that can't, say, talk about their organisation directly, but maybe get anonymous presentations from people on information that they want. That's just...
FLORENCE LAVROFF: Well, we can have videos with voice off if this is really required. But... I hope that the unrecorded part of the session can help to cater for this anonymous need.
AUDIENCE SPEAKER: Wolfgang: One thing that I would like to see a bit of discussion about is you are a small IXP or a new IXP, I think most of our candidates, we would like to join that IXP have basically one available local carrier to connect there and that local carrier is also one of their transit providers and is afraid of losing transit traffic. And well this is not really that supportive in getting the idea out to their customers, so I think that's not really a problem for us, but for others. And that might be some interesting topic to discuss strategies and consider.
REMCO VAN MOOK: Thank you. Brian and Martin.
AUDIENCE SPEAKER: Brian Dixon, go daddy. At one our two other conferences they sometimes V it's more of an evening BoF kind of thing, it's what they call a peering personals which is where members can actually introduce themselves, particularly if you're somebody who is new to the RIPE region or, you know, about to improve your peering, to introduce yourself, and I don't know whether that's something that other folks are interested in just, well you know, saying welcome, Hi, talk to me, if that's something that people are interested in.
REMCO VAN MOOK: We can do that really easily. Show of hands, who is interesting in doing peering personals at the next Connect Working Group session. Two hands. Not everyone at the same time people please. We might give it a shot next time. We'll open the opportunity to do peering personals and if we get less than five we probably won't do it.
AUDIENCE SPEAKER: Martin Levy, CloudFlare. I have said this before and I'll say it again. Why is it the same people who keep coming to the microphone at everyone of these meetings? The same culprits, the same people who have that extrovert mindset about talking. But I'm going to ) modify that. Maybe that's okay. Maybe the question you should ask is is the audience in a somewhat full room happy with the status quo of the Connect Working Group and what's presented because sometimes there are people that just want to be the passive listeners that want to receive the information, they don't get it anywhere else. And maybe within this forum, which is different than a peering forum, so I modify a little bit about wanting peering personals here, maybe I don't want that, but maybe there is something different that is required here and maybe the fact that a set of updates from a consistent set of core people is in fact valuable to the community. Or not. The room either has to hum or has to disagree with me or violently agree with me or say nothing and leave a quandary for the chairs. But that's what came to my mind.
FLORENCE LAVROFF: Thanks for phrasing that. I really hope that the people who are present here right now are here because they have interest in this session and not because it's the only alternative to Address Policy. So I mean, please raise your voice. This is not recorded, so...
REMCO VAN MOOK: We can have a humming right now, what would be useful is to rate the talks please. But, as Martin said, if you think we're doing a half‑way decent job or better, I mean, how does this work? You do IETF's more than I do? You just ask for humming, is that how it works? Leave leave yeah, the humming is just for people who have never done is
MARTIN LEVY: ) Basically enough for somewhat anonymous, you can't really tell who is humming but the general sound. Just simply is that you have to ask your questions correctly and the chairs will have to do this, but I would suggest, you know, those people ‑‑ the first question is are those people comfortable with the amount of time this they have spent here today and found it valuable for their collective businesses. Just ask that question?
REMCO VAN MOOK: Well what Martin said...
MARTIN LEVY: And a hum means yes.
REMCO VAN MOOK: So are you generally happy with today's content or do you rate it a 6 out of 10 or better, I'd like to have a hum on that please.
That's quite a bee Hive. That's good. Thank you very much.
All right, I see two more people at the microphone and we are already into the lunch break, so I would think we will call it quits after Blake.
AUDIENCE SPEAKER: Dominic. I just want to give a general feedback of the contents. It's really great to have the Working Group. But maybe we can move the content with the IXP centric more to like a contractual point of view, because mostly new peering policies like open, selected or like something else, then they usually don't know what this means. So I would like to suggest that we give an introduction like how do you handle peering requests? What are the decisions you make? When to peer? Especially when it comes to remote peering stuff, like how do you keep up your IP quality in your network?
REMCO VAN MOOK: So should we potentially do a peering one on one, would that be useful.
AUDIENCE SPEAKER: Yes, some kind of tutorial, like what are the best practices to get this more in a concentrated repeating manner for newcomers.
REMCO VAN MOOK: We'll gradually take it on board.
AUDIENCE SPEAKER: Blake from Zayo. Speaking as a coordinator for a large carrier. This usually happens in the hallway track at a RIPE meeting and as EPF that we also do. The group's time here would be better used not doing that. That said, if the Working Group Chairs felt that there was a presentation from somebody about peering, then put it up there. But I think there is plenty of other places for that to happen that don't need to take up the time of the entire room.
REMCO VAN MOOK: All right. Thanks very much for that. I'm looking at my co‑chairs, anything else that we would like to ask, share? I think we're good.
So. We'll call this to a close. Thank you all for joining the Connect Working Group at RIPE 77. Enjoy lunch and don't forget to rate the talks. Thank you.
(Applause)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
