Plenary Session
22nd October 2017
At 4 p.m:
CHAIR: Good afternoon everybody. Please take a seat, we are starting now in the second session in the afternoon. Well, hello, welcome to this second plenary today. We are beginning this session with state of the Internet in France by Samih Souissi from Arcep.
SAMIH SOUISSI: If you don't know what is Arcep, Arcep is the French telecommunications regulator and I work at the open Internet unit so basically our work is to keep Internet open every day and it's not that obvious.
So in this presentation I will talk about ‑‑ I will give a brief overview of the state of the Internet report that we published this year and then I will divide my presentation into two main parts: The first one is related to data interconnection market evolution in France, and the second one is related to the transition to IPv6 in France and how are we doing stuff to promote it.
So, on May 13th 2017 we published our first report on the state of Internet in France. It identifies the threats that could undermine the Internet proper functioning. And neutrality. And sets out the regulators' actions to contain those threats. As you can see, there are several issues addressed, it goes from data interconnection transition to IPv6, quality of Internet access, open platforms but in this presentation I will focus on the two first topics, if you have any questions related to quality of service or net neutrality we can speak after the presentation.
So in this report, we had like different external contributors, we tried to federate the ecosystem of tell communications in France, including European Commission, the body of regulators in Europe, research institutions like north eastern university that are working on net neutrality detection tool, AFRINIC, Internet Society, etc..
So let's start by monitoring the data interconnection market. Why are we we doing it and why are we the only regulator doing this in Europe? In our report in 2012 to the parliament and government we indicated that interconnection market may result in ‑ tension between actors, so it requires vigilance on some practices like virtual integration or paid peering, but disregarding hard regulation or law so we don't think decision are needed for interconnection market.
So, how do we do this monitoring. So in order to have a thorough and up to date knowledge of the interconnection market we had set up interconnection routing data gathering campaign and the data collected in this campaign allows us to consolidate our knowledge of the interconnection market in France and extend its evolution and this supervision is useful because it puts us in position to react quickly if there is a problem and on the other hand, it encouraged the actors to behave virtuitously because if they know that the regulator is aware of what is going on with interconnection they will do things in a better way.
So, here I present some formal proceedings that happened in France before that explains the decision to collect data that was published in 2012 and it's update that was published in 2013. So what happens is that in May 2012 Cogent complaints to the Competition Authorities about the quality of their interconnection with orange, what happens that like client of orange, they couldn't access to the mega upload website that was interconnected with Cogent, and independently from the fact if the service is legal or not being upload, the interconnection was congestion so the Cogent complained about the capacity of our interconnections offers, especially that orange has two autonomous systems, one that is proper to the operator and one which is like open transit international which is a tier 1. And also, they complained about the financial terms asked by Orange. Then in October 2011 Arcep published its opinion to the Competition Authority, saying that there is a high asymmetry ratio between Cogent and Orange, there is no sales transaction and asked by Orange are not unrelated to underlying cause and IPN there is a balanced bargaining of power providing that end user are informed of the impact of interconnection on their service.
So, after this opinion, Arcep decided to start monitoring interconnection to be ready to understand this market and to get more expertise. After cogent and orange formal proceedings we had another, we had like the Competition Authority that accepted commitments of Orange to formalise an internal transfer protocol and facilitate a regular supervision of its implementation. And second formal proceedings we have the problem related with free and Google, for their interconnection practices, so after consumer association has warned Arcep about the difficulties of many clients are free to access Internet services provided by YouTube, Apple, etc., so after that we released our conclusions in 2013, saying that there is no discrimination done by Free, what happens is that they were using traffic shapers to reduce the traffic going to their network through transit so we had like global congestion of free transit capacity that negative impact on all traffic using transit and going to Free Network. This led to the update of the decision to look for capacities not only, unstalled but also parameter that may be like different from installed for several reasons that operators may explain.
So, how does the gathering campaign looks like: So this is like, it's as simple as sending an XL file to operators and asking them about each interconnection. And the type of interconnection if it's peering, transit, paid peering or free, the different capacities, standard parameters, the pricing scheme and then we have like ongoing and the outgoing traffic, and also the agreements on IXPs about public peering. So the scope of this decision is related to electronic communication providers in France, not only but also the companies that have ASes and are connected with autonomous systems in France, for example, CAPs or other external operators, so if you work for an operator or content provider and you are interconnected to French autonomous system, we may speak later to get your contact.
So, after like this, how say, after ten ‑‑ after ten cycles of gathering campaigns between 2012 and 2016 we were able to publish a certain number of statistics related in this presentation mainly to the four main interconnection ‑‑ operators in France. So as you can see, with our traffic is not necessarily shaped as many other countries because we have like more transit than peering because like we take into consideration open transit international and the transit traffic counts for more than 50%, concerning private peering we have like around 10% and public peering is keeping at 5% but what is interesting is that we have an increase in total inbound traffic of 36% compared to the end of 2015.
So, if we see like more in subdivided with each semester it went from two terabytes on the first semester of 2012 to reach 8.4 terabytes and this is related only to the four main ISPs and for their interconnection that are higher which capacities are higher than gigabytes. Concerning the capacities we had the same increase, but it doesn't mean there is no concession because, as you can ‑‑ as, you know, we need to check for every link to look for congestion hints. And as you can see we had the traffic that doubled each two years and other information that we got from gathering campaign is that we have seen that peering has increased from S1‑2012 to second semester of 2016, from 39% to 45% and this increase was related to the increase in private peering of CAPs with ISPs, and as this private peering it explains also why we had this increase in paid peering from 22% to 36%. And those statistics are all indication of inbound traffic.
ISPs in France have experienced the steady decrease since 2012 so we have transit prices 10 cents plus VAT and for the transit market is around €4 million per year concerning paid peering it's like between 25 cents plus VAT for ‑‑ and I want to add that this is related to the different ISPs that have answered our questionnaire. So for smaller ISPs in France, as in this report we didn't focus on smaller ISPs, it will be the main topic for the next report. Most of them belong to tier 1 classes, they have multiple transit providers, about two or three and times even four for resiliency purposes and connected with the main ISPs in France and some big operators that are ‑‑ that are not interconnected to IXPs in France. As they have small traffic, the transit price is higher.
So, another source of information for Arcep is questionnaire for new market trends that we sent this year. But before we had the information related to break down traffic in France, 50% streaming, now it's around 70 because this is not up to date. But the most interesting is this part where we see that the traffic coming from internal CDNs is increasing steadily and now we have 11% of traffic coming from internal CNs or caches of CAPs that they put inside the operators' network and this 11% is like an average but we can find operators without internal CDNs and others that have more than one quarter of their traffic coming from CDNs.
Another information that this questionnaire helped us get is the breakdown of traffic in France by origin. So as we can see, there is concentration of the traffic for the 5 main content provider that represents 5% that have their positions strengthened in the content delivery market. So what is our position in the interconnection market is supervising without interfering, so what we will be doing is keeping monitoring interconnection in France in order to be able to react swiftly in case of necessity, not only that but also we have tried to investigate new markets, as I before, In Marseilles our transition to IPv6 in interconnections and then that's what we aim to do in this second semester where we are ‑‑ we have a public consultations actually to upgrade the information gathering process to take into consideration traffic coming from internal CDNs and incorporate concepts of IPv4/IPv6, speaking about IPv6 I switched to, our work done for encouraging the transition to IPv6.
So, as you may know, due to the Internet success, the increasing the users and the multiplication of connected objects, we have shortage of IPv4, the transition is unavoidable and too much transition delay would result in to explosion of costs, dysfunctioning, etc., so the solution that is obvious is IPv6, that provides an unlimited addressing, a new functionalities and and for this sake Arcep wrote a report to the government of the state of IPv6 deployment in France and recommended the certain number of actions to do by Arcep and the different public institutions to promote IPv6 in France. So the first one is related to segment the example by committing to make all State services, government, etc., switch to IPv6. If you check our website, it's still in IPv4, but it's not related to us because the contractor doesn't want to switch to IPv6 and we were waiting for the next procurement that will be in 2018 to switch so we are trying to give the example with constraints. And then the second action is to extend education over IPv6 because right now we see that there is a lack of knowledge concerning IPv6 within operators, small operators, etc., and even in, within engineering schools where there is a focus more on IPv4 than IPv6, so it's our role to push in this direction and third action is related to the setting up of the appropriate place for discussion, creating events in France to federate the ecosystem and to share knowledge and practices and experiences. And the fourth action that I will explain more after is related to improving coordination between stakeholders. The fifth one is better inform user about its devices IPv4 and the problems related to them on a medium term or long‑term and finishing by preparing the phasing out of IPv4.
So, to improve coordination between stakeholders, what we did is we created the transition to IPv6 observatory, we published it for the first time on December 9th last year and we updated it in March and it will be updated by the end of this year. It's something that, it doesn't look like this but it has some, it's interactive and it has this information, so for its first version what we are doing right now is that we work with AFNIC and several other French organisations to gather external information, Tier1s, to describe the IPv6 situation in France, and to take all aspects into consideration, we took into consideration equipment manufacturer, fixed Internet, mobile Internet, CAPs, infrastructure, DNS infrastructure, sorry, and technical intermediaries, etc., and we relayed also information from Cisco and did some name and shame here that was interesting to push operators to incorporate IPv6 in their transit.
So, in the current observatory that was updated shows this increase was mainly due to the migration undertaken by Free in 2007 and by Orange in 2016. The not also a matter of operators, there is also problem related to CAPs, we have 50% on IPv6 and weighted by average so it's hiding thousands and thousands of small CAPs that are still in IPv4 and in order to benefit from this protocol we all know we need to migrate .
So what we are doing right now is enhancing the observatory of IPv6 with information gathered from the operator, for example the number of IPv6 client activated and ready, etc., and their traffic, IPv6 traffic on the interconnection, and this enhancement will be validated by the end of this semester. And it will also incorporate the transition programmes of the several operators over one year and three years. And another topic that we are dealing with actually is to foster reflection of IPv6 advocacy events and to create at least Annie vent to better share information and best practices. Thank you very much. If you have any questions, I am here.
(Applause)
CHAIR: Thank you very much. If you have a question please come to the microphone. State your name and affiliation. I have a question for you. You mentioned that one of the issues with converting the main websites was that a contractor wasn't so interested in doing that. Can you describe some of the ways that you want to help influence them to make the correct decision.
SAMIH SOUISSI: We need to start by influencing at the beginning the operators that are not willing to to because they are putting 2000 private IP addresses behind the NAT or 10,000 and then they say we don't have IPv4 short ‑‑ so we won't use that, so why we are doing kind of name and shame, because for them, even if the not necessarily a choice for the client, you won't necessarily choose your operators except if you are a geek or something like that or in the community, to choose your operator because it does IPv6, it's just the fact that like when you show a podium like this, if you see an operator like this you will know that this operator is not the ‑‑ is not pro innovation, is not prolike new Internet, so for the operator the fact that we are putting this kind of podiums and we are right now will be putting podiums for one year and three years of their strategic planning on transition and we have operators that are at 80% in three years, others that are at 15, so the fact that we put this side to side, the operator will understand and the client will understand. So it will have an impact and the ‑‑ it can be even simple because many operators are like do deploy their IPv6 compatible boxes but they don't activate them per default and no one knows why but it's like a decision who is doing this decision, no one is giving us the answer but in general having this kind of information, providing data in a kind of transparent, it's a way of regulating by data. So provide data to all consumers, it's a matter of regulating with transparency and to promote this transition.
GEOFF HUSTON: APNIC. Thank you very much for that talk. Your first part of the talk was about peering and interconnection. And you mentioned I think at the outset that this is largely a market‑based activity. What role do you see as a regulator in attempting to control the actions of these players outside of arbitrating in particular disputes? So in two cases there was a dispute between two parties so that's fine but in a general market, what would be your role as a regulator around peering and interconnection of market actors in France?
SAMIH SOUISSI: What we are doing right now is, as I said before, there is no interest in ex ante regulatory decision in this market so what we are doing right somehow regulating and the fact that ‑‑ not regulating sorry, but monitoring the different interconnections, so we have each semester operators are sending us their charts with the different traffic, etc., and we see what is going on and it leads them for a virtuous behaviour. It's like, how do you say, it's like in quantum physics theory, just by observing we can change things.
GEOFF HUSTON: Just by observing you can change things?
SAMIH SOUISSI: Yes.
GEOFF HUSTON: Thank you.
MARTIN LEVY: CloudFlare, I have to follow on from Geoff's question. Quantum aside. In the example on your earlier slides you talked about the contentious issues of peering that in fact hit the courts or at least hit the public press. The last date on that slide was quite a few years ago so to follow up on Geoff's question, do you believe that things have quieted down in France because of your involvement, or do you really think that the market has matured to the point of the individual players? This is a slightly different question. That's my first question. The second question is, on the chart that you have right there, you have Free, Orange, etc., etc., the French specific players. Can you tell us about how the individual players in France peer and is that a successful non‑competitive, non‑combattive environment? We are very familiar with the external content players, of which I am one, but I had a' like to know more about the French‑specific players. Two different questions.
SAMIH SOUISSI: So for your first question, just to mention small parentheses, we had a problem last year but it was not public, between Orange and ‑‑ there was a problem the same as Orange and cogent but it was with Orange and tel I can't, with the same reasons and we tried to speak with every actor to find a solution but the solution came from the CAP, just switching more traffic on entity other than tel I can't and everything went well. So I don't know if there is like a direct impact on this market but the fact of monitoring will help us, like what happened in the last February, to react quickly, to know who to contact and to know at least which interconnection is leading to congestion. Is it clear or ‑‑
MARTIN LEVY: I understand your response, yes. I will wait for the ‑‑ so you and for the second question ‑‑
MARTIN LEVY: About the French operators specifically amongst themselves.
SAMIH SOUISSI: The French operators among themselves, there is still like some issues but like small players are mainly interconnected on IXPs, and how do you say, the main issue right now in France is related to the implementation of internal CDNs by CAPs within the operators' network, for example Google, Acamai or Netflix, they are kind of forcing operators to put their servers within the operator networks, which is not necessarily for certain operators a viable, economic plan. But concerning the small operators, as long as there is no problem, so far, so good.
MARTIN LEVY: Thank you for the clarification on both of those. If I may go back to the first question, I'm trying to still truly understand the cause and effect. You mentioned the companies involved, therefore I can repeat their names: Orange, tel I can't and you mentioned NTT: I hope that wasn't under non‑disclosure, because you said this was not really a public thing. However, these are players that, from my experience, know each other very well; the individuals that are important in those companies are very aware of each other, so I'm just trying to, just understand completely whether the mere fact of your existence causes them to solve problems or whether you play some more active role, and in a way I am hoping you don't play an active role any more, to be honest. This is useful information, but I'd' like to know that ‑‑ I would like to believe the players deal with these issues themselves. And I am just to delve ‑‑ you have opened a new issue, I am just trying to clarify that.
SAMIH SOUISSI: As I said before, our only action is when a problem is happening. So we are not intervening or regulating or telling each one to peer with that one or ‑‑ there is no hard regulation on this. We are just observing. If something happens, we analysing data that we have gathered, we try to interact with the different actors to try to find a solution. And this is what happened with Orange ‑‑ at the beginning of this year, there was other than in specialised newspapers, there was no official publication about this. So it was solved fluidly and no one is ‑‑ has known about this, it was not on the head likes.
MARTIN LEVY: Your role is more reporting after the fact than reporting on anything else. Thank you, I appreciate that.
CHAIR: Thank you very much.
(Applause)
Up next we have Sander Steffann going to be talking about the state of IPv6 only, which is a long‑term goal for many of us.
SANDER STEFFANN: Hi, so originally the plan was Lee Howard was here to present this, he couldn't make it here today so I am the stand‑in. I am going to give a short presentation on IPv6, IPv6 only, see what is happening and basically some of these slides you will probably have seen 100 times but I hope at the end especially that I will give you some that you haven't seen 100 times already.
This is the well‑known graph, Google, number of eyeballs, and we are basically at above 20% at the moment. So, if you look at these numbers, as it should, IPv6 usage is going up. Up and to the right. Looking at the spread around the world, most of the activity is in the US and Europe, but India has turned pretty green as well recently. So there is lots of IPv6 all over the place. If we are looking at the network operators, most of these are pretty well‑known. But you can see that some of them like Comcast and A TT, they are above 60, 70% of IPv6 deployment. The reliance is 84. These are huge networks, charter is big US ISP, they bought Time Warner Cable so they are pretty big player as well. If you look at these numbers, these networks really do a lot of IPv6.
Now, looking at the other side of the story, what we just saw were networks that offer v6, a lot of content ‑‑ sorry, a lot of eyeballs, these are the countries that actually show up when you look at the websites that do IPv6. Now, to be fair, a lot of this is Google's fault because if the main web properties in a country are Google all of those have IPv6 so the country jumps up a lot. But again, nice numbers.
Famous Belgium, looking at eyeballs again, but also countries like Greece and the US have come up really fast over the last couple of years. India didn't show up at all a year ago. Now it's number 6 worldwide. So there are ‑‑ there is really a lot of deployment happening.
Now, because we are in the Middle East let's focus on this region. If you look at the websites Armenia, Palestine, Turkey, Iraq, there is a pretty long list of countries that do have IPv6 enabled websites. So, UAE is pretty good as well. But still, worldwide only at place 102. So have to put it in a little bit of perspective there.
Looking at the users, Saudi Arabia is leading by far, Emirates are second, so also there is a lot of happening. Unfortunately, after the top three, everything drops down to 0.something, so there is a lot of work to be done in this region. And I think that there is the local ISPs can at least show the right direction.
Now a bit further, looking at Erik's graphs, he has a graph where you can plot S‑curve against current IPv6 deployment, as measured by Google. So if you plot an S curve a projected 300‑day lead, then actually this is going pretty fast in about two years, we would reach the 50% mark. In about five years we would preach 90% mark. So if the current trend continues and if using s‑curve is actually appropriate for this, I mean, it's all ‑‑ it's all prediction so you can't be sure, but then we are actually moving pretty fast in the right direction.
What are the consequences of this? If you look over the world you actually see that most of the continents are at 15%, US is a bit ahead, Africa is behind, but there is a lot of IPv6 capability spread all over the world. This is the current region again. Saudi is the biggest one here. They have, they are starting a healthy IPv6 deployment. Looking at the speed of the region, you can see some really big spikes, and if you look at the dates at the bottom of this graph, you can see actually see that all of this is pretty recent, this all started last year. So every ‑‑ all the v6 deployment we have in this region is actually less than two years old. So not bad at all.
These are the websites, these are actually the APNIC stats.
So, like I said, v6 is actually moving in the right direction, so what does this mean? Well, it means that at some point we should be able to do IPv6 only, but this has been a lot of discussion about what IPv6 only actually means. Does it mean that you ban every little bit of IPv4, disable v4 stack in every device? Where do you draw the line? So, at this point I think a reasonable definition would be, like a host is v6 only, if it doesn't have a v4 address on an interface. And a network is v6 only if it doesn't carry v4 packets. I hear ‑‑ we are referencing your draft here ‑‑ Jordi says natively. And that is a last point. Transition mechanisms at this point ask still be part of v6 only deployment. If you look at, for example, in my own home country, Ziggo, they have v6 network and provide DS‑Lite on top of it, that is not exactly a nice protocol, it's a bit ugly, costs a lot of money to build the CGN boxes, v6 only, still provide v4 to their customers but I think this will be a major direction. You also see devices in the mobile world, they run NAT 64 but all the packets on the network are just IPv6. Yes we play a trick with DNS and we NAT it back to IPv4 somewhere in the core but the whole network is IPv6 only. The end host is IPv6 only. You don't have any v4 in there any more. And that is actually pretty neat and this is something that we are running in production today. So, thinking about IPv6 only is at the moment not as crazy as it sounds.
If you look at the ‑‑ at the networks and this is from the US, as I said this is originally Lee's presentation, if you look at these networks and how many are ‑‑ the IPv6 capable, if you look at the top ten they are all above 90% and the moment you reach the point where you can, 95, 99% of your devices can actually speak IPv6, can use IPv6, suddenly the need for IPv4 starts to go down and these networks could actually, if they don't already, like some of them might do IPv6 only and use NAT 64, but for others this would be a viable option at this point. You are actually getting to the point where turning off v4 in your core might start making sense.
So what is the reason people don't? Well, it's obviously the rest of the world because you want to reach destinations that don't have IPv6 yet. But in these cases, simplifying the core, running v6 only there, having some translation at the edge makes a lot of sense, it can save you a lot of headaches. One of the most difficult things about running IPv6 is you still have to run IPv4 as well and you to get to do all the work twice and get all the interactions and transition mechanisms. If you start running IPv6 only you can simplify a lot.
So, there are actually 374 ASNs at the moment that only announce IPv6. They don't announce any IPv4 routes. Now, to be fair, I guess most of these actually do have some IP v4 just on a different ASN. But we checked some of them manually, some of them have a separate ASN where they do both v4 and 6 and ASN only v6. Maybe these are special deployments, testing environments, I don't know exactly what it, but they are there.
Now this is an interesting one that comes from Apple, so Apple actually collects statistics were from all of their devices, iPhones and tablets and the blue area in the graph are v6 only hosts, don't get v4 address any more. Those are probably all the phones on NAT 64 network. And if you look at the size you see it's pretty stable since, basically the end of last year. So for the last year we actually have IPv6 only devices and they are, what is is it, about 5%, 5% of the Apple devices actually don't even have a v4 address any more, which I think is pretty neat.
So, this slide is spell for when you download them from the archives because all of these are links to all the different IPv6 initiatives and you can read up. There is a lot happening. Cisco is working on it and Deutsche Telekom and charter, T‑Mobile has already gone v6 only. There is a lot of projects that are focusing on IPv6 and deploying it.
So, this has a lot of positive sides. Simplifying your network, use your addresses in a better way. Actually get better latency, we have seen from, was it linked in, yeah, that they showed that clients that use the v6 are actually have better latency, lower latency than the ones that use v4 and go through all the CGN stuff. And they might even be cheap. If you can minimise your v4 deployment, who knows, maybe you can sell off your v4 space and make some money. I hear those addresses are 10 or 15 dollars each these days so...
So, where do we think this is going? Well, we will see a continued growth in the providers that, for example, have the DS‑Lite. In the Netherlands, Ziggo has DS‑Lite. I talked to them, they realise that had it might not be the best protocol but this is what they have invested in, this is the direction they are moving in. So those will just continue. I know in the Netherlands that all new customers that are connected, all customers that move, all get DS‑Lite now. So this is becoming normal.
Map is another interesting one because for the ISP a lot cheaper to run because you can run it statelessly, you don't need a stateful device in the core of your network. You can balance it over multiple paths, you don't have to keep state and redundancy, so that is actually cheaper to run, but up to now there haven't been many CPEs that support it. I was talking to Jordi during the lunch break, and I heard from Lee that in the US charter is now actively going to deploy MAP and there are worldwide CPE vendors that are now actually selling devices with MAP support in them so it is becoming a viable alternative.
Then we have the mobile world. Increasingly v6 only with NAT 64, Android has 464 XLAT that simulates on the device for applications that needed. IOS has been a bit harbour to their developers, they said okay, listen, you can't rely on v4 any more, just make sure it works with v6.
And I heard that actually we are now getting to the point where CPEs support 464 XLAT, which the ISPs, might just offering this to the home users as well. The CPE would do 464 and simulate v4 for the local network. At that point, you know, the clients don't really care, we still have all the PlayStations and all the home entertainment devices that don't do v6 but if you can do MAP or 464 on the CPE, you don't case the ISP can go completely v6 only, the user wants some simulated v4 fine. And the one that we have seen presentations about before, for example, from Facebook, is data centres that are v6 only which simplifies the whole data centre, put the transition at the edge and you can also make that simpler.
So to summarise: Well, dual stack is only an interim solution. It still requires us to have this ugly v4 thing. So where we immediate to go in the future is v6 only and we are actually getting a really close to where that is a viable solution. For a lot of organisations it already is. So, if you look at it you might compare that the current state of IPv6 only is where dual stack was six years ago. Six years ago dual stack started to come up but now it's pretty normal. At this point we are looking at v6 only and I am guessing in a couple of years it's just going to be a normal thing to run your network like this. At least I hope so.
So, of course, the final IPv6 only would be if IPv6 without any translation technologies or MAP or NAT 64 or anything like that. I think that is a bit further away. We will still need to support a lot of the legacy stuff, but I am hoping that in the next couple of years we can actually move to networks where the whole core can just be v6 and we don't need to worry that much about all that legacy v4 stuff any more. Thank you.
(Applause)
CHAIR: Thank you, Sander. Are there any questions? Yes, I see questions.
AUDIENCE SPEAKER: I think ‑‑
SPEAKER: Good afternoon, speaking on my own behalf, not on behalf, speaking as the author of DS‑Lite, I know fake news all over the world but want to be honest here for a second, if you look at NAT 64 DS‑Lite or any of the others they more or less are the same thing. This is all about IPv4 as a service on top of IPv6 only network.
SANDER STEFFANN: Yes.
AUDIENCE SPEAKER: And some have differences in amount of state and where the state is, but specifically if you look at NAT 64 and DS‑Lite they are exactly the same amount of state and exactly the same amount ‑‑ and wanted to clarify this. The reason I came to the mic was not about this, it's your first slide about the state of IPv6 worldwide. And I have been tracking this for a couple of years, many years I think, and what strikes me is difference of speed at which this is being adopted in different parts of the world. We have some countries that really on this escrow that you are talking about and we see numbers like 50 plus% somewhere and I am sure we go to, where nothing is happening, and if you track from six months to ‑‑ this is still the same thing. Like we had 135 countries less than 5%, actually it was 160 countries and 130 countries less than 1%. And if I look six months later this is exact same one. I am very concerned and person concerned for somebody who has been in this industry for 20‑plus years that we may end up in a world where we have IPv6 Internet and IPv4 Internet, where essentially we have two Internets, and if we go toward IPv6 only fast in some of places as you are suggest, those two words may not be interoperating and that worries me a lot.
SANDER STEFFANN: That is exactly why I said that the two versions of IPv6 only, like v6 only but as a support platform for IPv4 as a service, and IPv6 only where you completely get rid of IPv4 and don't even offer it as a service any more. For all those countries in all those networks basically, it's not really countries, that are still completely v4 only we still need those translation services. I am seeing a lot of places where v6 deployment is happening could benefit from this, we still need to translate or tunnel or whatever way provide IPv4 as a service, to be able to reach those. That will definitely not go away in the near future.
AUDIENCE SPEAKER: I like the idea of one Internet, not two Internets.
JAN ZORZ: Speak on my behalf as a random guy from the Internet. Can you go one slide back for the predictions. So I am really happy to learn that A plus B or how it's called these days, MAP, is starting to get traction.
SANDER STEFFANN: ‑‑ had something to do with that at some point.
JAN ZORZ: We spent two‑and‑a‑half years standardising it and I am happy we see it's coming into production. But my question is, though, I have two questions or maybe suggestions: Can we start building a web page with the chart of which CPEs are supporting 464 XLAT and which supporting MAP and make it public and see how that goes, who will, if we can, other vendors make them implement the stuff much quicker. And the second question is, where do we see it leaning, operators, where are they leaning, towards MAP or 464 XLAT? They want stateless or they want stateful?
SANDER STEFFANN: I think we will ‑‑ the operators, for example, that are also deploying on mobile, I was exactly the same question discussed with you earlier before today, the operators that are on mobile already deploying NAT 64, so 464 XLAT they don't want to add another protocol like MAP or DS‑Lite, they would like to standardise on one solution. They will probably go for that. I think if you look at the fixed carriers that don't have the NAT 64 on mobile, I think those will go for DS‑Lite or Map, more that direction. I think that will be the split.
JAN ZORZ: So if you already gathered some data which CPEs are supporting which we can start ‑‑
SANDER STEFFANN: Lee isn't here unfortunately. I know that he has somebody in his office testing a home user equipment and CPEs for all these things at the moment so I am sure there will be some interesting documents coming out of that.
JAN ZORZ: Thank you very much.
BENEDIKT STOCKEBRAND: Training consulting. Two things: First off, what is an IPv6 only host with definition with interface? I assume that doesn't include look back interface because that is one way to really hurt yourself, if you disable IPv4 to the point that look back interface doesn't do IPv4 any more, a lot of things still blow upright in your face. But what I was more interested in, could you look back to the last slide again ‑‑ the last one. There it is. Dual stack is the halfway point. In a way it's right but it's also misleading because dual stack doesn't always have to be the way. In a number of contexts, you want to avoid going dual stack, at least in parts of your environments, because some of your members, the talks ‑‑ doing only IPv6 only networks right from the beginning and keeping things out, are the data centre accept on the edge, and putting it like this might be at least easy to misinterpret. The basic idea if you want to do an IPv6 deployment is to try to minimise the dual stack wherever you can, so yeah, just ‑‑
SANDER STEFFANN: I fully agree with you. It's a possible halfway point.
AUDIENCE SPEAKER: Yes. Okay. Whatever.
RUEDIGER VOLK: Deutsche Telekom. I am quite sure I did see Lee at the NANOG three weeks ago. I wonder whether he did not notice a presentation that ‑‑ disturbing observations about v6 and the DNS, that was pointing towards DNS with DNSSEC, unfortunately relies on some v4 in the background for actually fully being available. I am kind of irritated that that kind of question isn't addressed in any way by Lee's presentation.
SANDER STEFFANN: I am sorry, I wasn't aware of that. Lee will arrive later today, so you can ask him that in person tomorrow.
JORDI PALET: Regarding the CPE support for map and 464 XLAT I just want to add something. I ran a panel in last APNIC meeting, last month, in that panel I invited different CPE vendors, unfortunately only three participated, but they are big CPE providers, one of them is ‑‑ the other one is dealing so I guess they are quite significant, and the other one was, it's not very often used in Europe, it's Europe and Middle East is NA C. And all the three of them said they had called ‑‑ running on their CPEs to support both Map and 464 XLAT and DS‑Lite and this code can be implemented like this in any CPE, it's only 10, 12 cases so it's not a problem of hardware or memory or something like that but they said they don't do it because they don't get customer demand. So it's up to us, the ISP, the operators, to request that. And get it.
SANDER STEFFANN: Good to know. Thanks.
CHAIR: This is the last question.
GEOFF HUSTON: I gave that presentation that Ruediger referred to, and the issue comes that folk who are running what they claim is an R v6 network today, cannot support IPv6 DNS with DNSSEC. There is just so much loss going on with extension headers, fragmentation and that is a problem. What I'll do in the v6 Working Group whenever it is later this week is actually expose how we measured it, what we are measuring and talk about the challenges that gives back to us, as to how we are going to make fragmentation or at least large UDP responses actually work in a v6 only network because right now, the failure rate is big enough to be a concern, but we will talk about that later in the week. Thank you.
SANDER STEFFANN: Looking forward to that. Thanks.
CHAIR: Thank you very much and thanks for doing this presentation.
(Applause)
Please remember to rate the presentations, you have special place in the website for it. And now it's time for lightning talks but ‑‑ I didn't introduce myself, I didn't sleep today, I was flying. So, Maria Isobel Gandia, Consorci de Serveis Universitaris de Catalunya, and Peter Hessler. And now it's time for Daniel ‑‑ I just wanted to go on the stage while I was talking. He is going to talk about RIPE Gripe. The floor is yours.
DANIEL KARRENBERG: Thank you. Good evening. What I would like to do is basically share with you an idea I had for maybe a new small service that the RIPE NCC could be doing, and my name is Daniel Karrenberg, I am chief scientist at the RIPE NCC and just to keep up with the fashion, I am not speaking for the RIPE NCC right now. Although I checked it with some people.
So let me give you the anecdote and what I will do is I will speak for about three minutes and then invite comments. So, it's not going to be long. The anecdote, how I arrived at this idea was, that I was doing some research on DNS, specifically on queries that we get at K‑root and there is a class of queries called priming queries which you expect from each client at most like every day, if they are really well‑behaved. And I found that some IPv4 addresses were actually querying us five times a second. So I thought, that is an anomaly, so I couldn't make out why it was, so what I really wanted is contact the people who ran the resolver or whatever this host that was basically hammering us with queries, and what do you do and many of you will know, you get an IP address, you want to talk to a human so you go to the RIPE database and what you get is, in the first instance, is an abuse contact and an abuse e‑mail address and that is not really the point that you want to contact because you want someone with clue and someone with operational clue. So what do you do then? You go through various other contact addresses and make an informed choice and about who you write to and then as in this case, actually I speak the language of these people so I wrote a nice e‑mail, starting with I have a question, and hoped for an answer. Before I actually I had completed all this, I think it took me about ten, fifteen minutes to go through all these things, find the addresses to use, compose a nice message, and that is quite a costly thing. And even once I had done that I wasn't sure whether I would actually receive a response, based on past experience.
So, in this case actually the people were quite nice, I sent them the e‑mail at six in the morning or something and by 9 o'clock I had a response and I got to know why this was, and they basically corrected their misconfiguration. But there were about 1,000 other systems that were doing the ‑‑ that are doing essentially the same thing, maybe not five a second but maybe two or three a second. So, I was thinking, that doesn't really scale, if I want to really contact all of those, so I said okay, I got one example from my next talk and that was fine. Then I gave this talk at a meeting of DNS org and during the same meeting a guy called Ed Lewis, who many of you will know, suggested that DNS org should go into maybe brokering operational anomaly messages, a little bit better than it does right now through a mailing list. And while Ed was talking about this, I had an epiphany because I thought, really what you don't want to look up in ‑‑ an e‑mail address based on IP address. There is actually organisations that do that for a living and the RIPE NCC is one of them. So why isn't there a way that, if I know an IP address, IPv6 or IPv4, or an AS number, I can make a gripe or a remark about an operational problem that I'm seeing, just by using that IP address? And I don't also want to write a nice message, I just want to write a little thing that look at your DNS server or what is all this traffic coming from? Or what is your route flapping? Or whatever I see. And I want to do it with a minimal cost. I don't want to do all this looking up stuff, I just want to say, this address, you know, this message, send and be done with it. I might even want to say, hey, I don't really want a reply, I wanted to let, you know, never mind, ignore it, or whatever, don't come back to me even. Why don't we have this? Because at the moment we all do this by e‑mail and the people who deal with these e‑mails don't like to get so many messages by more or less clueless people who say, my intrusion detection system just said you attacked me, or something like this.
So, thinking about this a little bit further, I think there might be room for a service where a regional registry like the RIPE NCC gives you an interface and maybe just to start it like a GUI through a web page, and you can only access this if you have a RIPE NCC access account so we can know a little bit that there is a person there and we might even know something about their reputation in the sense you are there, a member of the NCC, are they an ISP, things like that. And you just paste the IP address, paste a small message in there and click whether you want a response or not, you can think about all these kind of things and you hit send. Cost is very minimal. And on the other side, the ISP, which we know, or the holder of the address space, which the RIPE NCC knows from its registry, would be able through their LIR Portal, pulling, not getting these e‑mails but having a structured interface to see these messages. And maybe even get alerted if there is some peak in them, which might be interesting.
And I thought well, maybe this is not so difficult to implement. It's an added value for the membership so why don't I just talk at the RIPE meeting for about three minutes, explaining this idea. So, now first of all, I would like to do a little poll in the sense who in the room actually recognises the situation I was in? Who has this kind of stuff? There are a few.
Basically I am done. I am inviting questions and comments. And if you would go so far as if you comment to tell me sort of on a scale of one to ten what you think of this idea, like 1 being this is the most silly thing I have heard this year and 10 being like, this will solve all operational problems magically in the Internet in the years to come. And you manage the queue, please.
CHAIR: Thank you very much. We only have a few minutes and I see quite a few people. Let's just start on the right and work our way through.
AUDIENCE SPEAKER: Jelte Jansen, SIDN, on the scale of 1 to 10, I give it two cocoa nuts and a banana. I like the idea. I also see a lot of problems with it, but I would really love to work it out further. As working for an organisation that maintains a Whois database and e‑mail is a bad method for this, yes.
BRIAN NISBET: HEAnet also co‑chair of the Anti‑Abuse Working Group. I look forward to the full presentation on this but I don't think the NCC wants to put themselves between operators and ‑‑ people with a problem and people who are causing the problem in this regard.
DANIEL KARRENBERG: Why?
BRIAN NISBET: Because I think ‑‑ providing the information, sure, but actually being the conduit, being the people who are saying you have a problem it will then become, ah, I have got that e‑mail from the NCC telling me I have got an issue. There is a position in there I am not sure the NCC should be putting themselves in the middle between people. There is a lot of good there but it's a dangerous position for the NCC to put themselves in.
DANIEL KARRENBERG: I wasn't thinking about e‑mail as a conduit, I was just thinking about some automated system that sends a message from A to B, at lower cost than finding out e‑mail address and la la la. So ‑‑ I am not proposing that the NCC says something is wrong.
BRIAN NISBET: But the system would be the NCC whether it's require portal ‑‑ we will talk more about this because it's a very interesting position to put yourself in.
GERT DORING: Internet user, abuse reporter, abuse reporting receiver. I like this. Maybe not at 10 but at least a 7 .5 or something. And I like the way that it's not e‑mail‑based. There is lots of tricky details to be solved out like tagging the reporting of the message with, this is an operational problem or this is spam abuse, phishing, whatever, but also the structured querying of this, like, some sort of well‑defined data that you can then use in your own systems to value this, like I see this IP address, it's the same one and we talk to them again or this is our resolver, it should pop up far higher. So this has potential but tricky details.
CHAIR: So before we go to the back, just a reminder please, keep it very, very short, we are rung out of time for this part.
AUDIENCE SPEAKER: Marco of the RIPE NCC, full disclosure but this is on personal title. I like this idea, I like the spirit and I hear this a lot. I would want to point out that I know of several national initiatives, for instance, in the Netherlands, which abuse ‑‑ and that is currently being billed out to kind of do a bit of the same so I would recommend to talk to those people and see if we can align efforts there if this turns out to be a RIPE's service maybe we can benefit from each other's efforts.
DANIEL KARRENBERG: I think the RIPE NCC is uniquely placed here because we have the address registry and that is the key to this idea.
BENNO OVEREINDER: Depending on the feedback actually or the back‑end for this ‑‑ for the sake of this discussion, so how the operator can access the data, if you provide and I think you suggested something like a restful interface, not e‑mail, just restful interface for the operator to rate and to analyse the messages, I think a failure is an 8 or 9 so I appreciate ‑‑ and I don't think it's operational thing, it's ‑‑ it's making sure that the information goes from A to B, for me RIPE doesn't get into the operations of the networks.
CHAIR: The last question from Ruediger.
RUEDIGER VOLK: Daniel, I think I know the situation that you described. However, I think there are quite a number of very large LIRs where this is very unlikely to actually work. Because kind of, kind of, figuring out which organisational unit or subsidiary has to be poked or which of the 20,000 commercial customers is just something that is unlikely to actually be served by sufficient resources.
DANIEL KARRENBERG: I understand that bit. Let's take that off‑line. My answer to this would be of course purely technical is if you want to farm this out more, we have an IP registry where you can actually put it as finely granular as you want. And I know this has its own set of problems. Can I say, ten seconds, so the people on the mic phones who want to say something, see me privately. Also, we have a new product manager, she called these days, I think she is over there, Nathalie, she is in charge of the LIR partal so in case you think that is bad idea and you don't, cannot muster the courage to tell it to my face, you can tell it to her. Thank you.
(Applause)
CHAIR: Thank you very much.
Next up is a report, it's Mirjam and Shane.
MIRJAM KUEHNE: Good afternoon. And here is my co‑task force fellow member, Shane Kerr and we are doing this together as a bit of a tag team. So this is the bit of update of the diversity task force that we started at the last RIPE meeting, to tell you what is happening next.
Just as a recap, we have identified, we want to increase diversity here at the RIPE community, there was a ‑‑ for various reasons, it produces different results and discussions and possibly also other policy proposals. So there was an initiative by the Programme Committee of RIPE to look more into how to increase diversity and we organised a workshop at the last RIPE meeting and got some external experts into the RIPE meeting and had a whole day workshop to work on possible solutions for this. This was the outcome of that workshop. So we had a whole long list of potential actions and activities that we wanted to take on, we formed a small team, still looking for volunteers and we will get back to that. What have we done off that list since the last time?
We have a page on RIPE Labs with a number of diversity‑related labs articles and we published two articles since the last RIPE meeting specifically about the work of the tack force and some activities that we have been ‑‑ or actions we have been doing. We had two online meetings in the mean time with varying set of task force members and as an outcome of that, the discussion, we have published a draft charter on the RIPE website. You can review that, the still draft so we are still looking for input and feedback. We have received some and we will include that there.
Also in a suggestion was made last time to reach out more to newcomers and in addition to having a face‑to‑face newcomer tutorial here, maybe to provide a webinar prior to the RIPE meeting so people can come here and are more prepared and feel more comfortable and are already part of the community, so we started and this time we want to evaluate the results and possibly repeat it again next time, maybe make it a bit more widely known and learn from this pilot webinar. And we started, as one of the action points we took on is to collaborate more with local community and see how we can reach out and get more local community people into the RIPE meeting, as one experiment this time we are organising, it just wasn't technically speak a task force initially, it was also, it was the idea came from Salam, basically, to organise a women in tech lunch session here at the RIPE meeting, Hans Petter mentioned it earlier on, we will have some dates later on in the slide.
And also a more wider like RIPE initiative was now the code of conduct is more widely adopted, it also applies to mailing lists and we are also using it for the hackathons. And the RIPE fellowship is a great project to get to increase diversity in the RIPE meeting. I think this time, I forgot the numbers, is it five out of seven fellows are women, and also the academic initiative has higher number of women attending, which is great.
I think that is where you come in.
SHANE KERR: Yes. Thank you, Mirjam. So, one of the things that happened early on in this process, we started looking at try to figure out who the attendees are at the RIPE meeting and I had done some work to try to guess which were women and which were men. Starting with this meeting, you probably noticed when you registered we gave people the option to opt‑in to report their own gender online, via separate site. There is a labs article about that. I also took the opportunity to rerun those same kind of measurements for the previous RIPE meeting, RIPE 74, and I will continue to do that for RIPE 75, although it will be interesting to do a bit of a comparison because now we will have self reported statistics as the reverse engineering guessing what people are based on their names. Speaking of that, I also got some data from the IETF, is the Internet engineering task force, standards making body, and about five years ago they had a big discussion in their community about diversity in their region. This graph here doesn't show any numbers about how many attendees came, or anything like that. What this did is, I used my technique of looking at the names of the people attending the IETF and compared it with their self‑reporting and and the numbers are the differences between what the self‑reporting was and what the guest numbers are. And wheat we see is in the worst case we were off by less than 3%, which is not super great given the number of attendees is something around 10%. It's also not horrible. We can use this technique of trying to guess people to get a historical word of meetings like the IETF and our own RIPE meetings as well. So again I will do that comparison going forward in the future. I also have some other interesting things based on these numbers but that is kind of out of the context of RIPE and but we are going to also try to cooperate with other communities going forward.
So, at this meeting you saw in Hans Petter's opening talk to the meeting, we have this lightning talk. There is also a BoF later today. That is go going to be held next door, a discussion about what people find interesting or ideas they want to have. It will also go into a little more details about the stuff we have acomp published as well. There is a Women in Tech Lunch, during the normal lunchtime, in the room next door, you don't have to sign up for it. If you are interested, go to that. I don't believe there is going to be a net girls lunch, if you are a woman in tech and you want to meet other women in tech, this is a good opportunity, it is sponsored and there willing presentations which is slightly different than before.
MIRJAM KUEHNE: Presentations won't be by the sponsors though, local women talking about their work.
SHANE KERR: It's not a sales pitch. We have a meeting tomorrow night of the task force, so this will be more of a work‑orientated meeting. Getting stuff done. It's open and everyone is welcome to attend. If you want to join the task force that is a a great opportunity as well.
Finally, one more next step: We are looking for community feedback. We got a lot of positive in the previous meeting about the idea of providing child care so that people who have children might find it easier to attend the meetings. We want to hear from you if you are thinking about coming to RIPE 76 or 77 our know somebody who is who might be interested in this. And yeah, we have got a mailing list set up. And please, if you want to do something, that would be awesome and be the change you want to see in the world.
Questions? We probably have one or two minutes.
CHAIR: Are there any questions for Mirjam and Shane? I have a question. How many people did not answer the question about the gender? More or less in percentage?
SHANE KERR: So I actually don't know. We did see a weird thing which is that some people went to the page or they opted in and said they choose not to answer. Maybe it wasn't clear. I do know at the IETF in the early meetings they had a relatively high percentage of people who chose not to opt‑in. Something like 20%. That has gone down and more recent meetings it's 94%, people do provide this information even though they don't have to.
AUDIENCE SPEAKER: Alexander Isavnin from Russian Federation. You just talked about gender diversity. As far as I remember at presentations there were much more kind of diversities and in your documents are also there mentioned. But I have a question, you are mostly talking about gender diversity. Are there any witnesses that somebody at RIPE meetings are, at RIPE community or by RIPE NCC discriminated based on gender? So you are talking about this kind of diversity but I don't see any kind of discrimination. Maybe you can see.
MIRJAM KUEHNE: I don't think we talk about discrimination anywhere in the charter or on the website or in the articles. Once you tackle one part of the diversity, it kind of magically spreads over to other areas like culture, background, countries and so forth. And so we are starting it at this part.
AUDIENCE SPEAKER: Maybe my English is not excellent. I re‑ask, maybe somebody feels it's somebody based on gender is not welcomed here. I feel there is no difference, but you are talking about increasing diversity in a place when you are maybe not needed to be focused, on my point ‑‑ RIPE's rejoinder on diversity is much worse in this case and I would like to talk about this at BoF. Thanks.
SHANE KERR: Please come to the BoF, we can talk about this in a lot of detail.
CHAIR: We have birds of a feather after that, for diversity, so maybe we can take these questions for later because we are running out of time, I am sorry, and then we will meet at 6:00 again. Thank you.
And the last talk for today, it's Osama, talking about Riyadh Internet Exchange, better late than never.
OSAMA I AL‑DOSARY: I am not Mohammed, I am presenting on behalf of him, he wasn't able to make it. And I am going to be talking about the Riyadh Internet Exchange. I am going to try to go quickly, so slide number one. That was pretty easy, it just talks about how the Internet is growing, it's around 40% growth annually, but here I am going to spend a bit of time here but I am going to try to fit within my time. So Internet in Saudi Arabia started around '97 and in the beginning there was one ‑‑ there was just one international gateway, it was redundant but operated by the government so a division called the Internet Services Unit ‑‑ called KACST ‑‑ for short, and they give all the traffic to several Internet service providers, so all the Internet service providers would get their tax from KACST and the carrier was the incumbent which was Saudi telecom to get to the Internet. Now, so in the beginning when the Internet started there was 25 ISPs or so, and then there is something called, I need to have some definitions very clear to you so if you want to understand the rest. So FBP is facility based provider which is the providers that are allowed to lay fibre and provide fixed connectivity. Or DSPs as well, so that is near term. Something slightly different. In the beginning there was only one, which was Saudi telecom, and then later on the international gateway was kind of privatised, so several other organisations were allowed to have international Internet ‑‑ gateways and in fact, we had more facility based providers that were created primarily through other companies coming in and a bit of deregulation happening so you had Mobilie, you had Byana, you had also ITC, that came in. And then at this point you notice here everybody was, if you look ‑‑ think about it, at this, all through here we had one central point where all the traffic would go through, so if any users two users that are part of two different ISPs needed to interconnect they would ‑‑ did not need to leave the Saudi Arabia, they would always interconnect eventually through here. Even though it's seen as a transit uplink. But at this point, since we now have multiple facility based providers and each one has their own international uplink, what that meant is that we started seeing routes going out ‑‑ or trace routes going out and back, and that caused a very large delay. So at that point that is when the Internet Exchange point, a demand for Internet Exchange point existed. We did have something provided by this incumbent, they called it Internet Exchange point but it wasn't neutral and it was layer 3 and it only connected to their own customers. It didn't actually have, it wasn't able ‑‑ it wasn't available to other ‑‑ to their competitors.
There was an attempt that kind of failed to create an Internet Exchange point at that point ‑‑ at this point, we can talk about the history, but what ‑‑ it didn't actually work, but what ended up happening is we started seeing some providers do direct peering then.
And this is where we are hoping it's going to rap, we are hoping we are going to have an exchange point.
All right. So the current state is that now we have direct peering between, so we have about six facility based providers, we have direct peering between most much them. I say most, meaning some of them don't actually have direct peering links and so you do ‑‑ and even the ones that do have direct peering links not all of them have all the traffic going through those links because the links may be saturated they so they end sending their routes up through transit.
So, an Internet Exchange is now created, it's actually exists right now so from a facility perspective it exists, the location site is there, and we have our first Internet ‑‑ we have our first facility based provider connected which is ITC and it's also peering with ISU, and it is government‑driven, but it's not for profit, it's sponsored by a co‑location, provider called Tuchanea and the architecture is Layer 2 and we are hoping to launch by Q1, when we will at least have three providers connected.
So what I was hoping for is, I was hoping to solicit feedback from you guys to get your ideas, I know that ‑‑ we know that the first step that we need to take to get this up and running is to actually have content. So once we have content, that will make it much ‑‑ even more appearing for the providers to come and stay but I am hoping to hear feedback from you as to how do we sustain this in the long run. So since ‑‑ I have been involved in the Internet community for quite some time, when I first learned about IXPs informs APRICOT I think 2004 and I was told no, governments can't build IXPs. And we have to at the moment because nobody else did. And we are just hoping, I am hoping to hear from you guys what you think should be done so that okay, yes, the government backed this and drove this but then after that what needs to be done in the long run to have it sustainable. Thank you.
(Applause)
CHAIR: So we have a few minutes for questions and comments. Please try keep them short as we are slightly over time already.
DANIEL KARRENBERG: Speaking on my own behalf. Just to answer your question, I think from experience the essential ingredients for real IXP is neutrality and I don't know the market in Saudi Arabia and how many ISPs are there but if there is more than a due op plea what you need is that everybody in your local ISP community believes it's neutral and everybody has the same chance to connect ‑‑
OSAMA I AL‑DOSARY: That is a good point. The Internet services unit is a neutral body and doesn't belong to any service provider whatsoever ‑‑
DANIEL KARRENBERG: So you have to really live that, and also, it's service providers need to have the confidence that it's not going to be abused to coerce them into something as regards to their business practices and stuff like that. So again, I don't know the political situation in Saudi Arabia but if there is any ‑‑ the reason we said early on governments shouldn't be running IXPs is governments shouldn't get into the temptation to implement policies they can't implement in another legal way, i.e. if the IXPs have to believe that this is not a cold way of regulation, basically. So what I would say is, it's good that you started this but I would recommend to start a process by which this gets to be governed by the ISPs as a group. So that is my input.
OSAMA I AL‑DOSARY: Thank you.
AUDIENCE SPEAKER: Hi, Jad El Cham, I'm from the RIPE NCC, but I am also speaking in my own capacity. I would like to give you a comment because I come from Lebanon, and so it's the same part of the world and we had a similar situation, one international gateway, we still have the situation today. But because of the structure and the, you know, the internal politics we ended up with a lack of trust between the different ISP and the government and the ‑‑ in the Lebanon so now we have three IXPs but they don't talk to each other, even one is doing his own island, we always heard the government will be involved in one way or another with IXP because unfortunately in this part there is a lot of deep packet inspection and this kind of practice. So although it might not be the intent or the intention behind building this IXP you will have a problem of trust and again this is coming out from my personal experience. Thank you.
AUDIENCE SPEAKER: Thank you very much. Patrik Falstrom. I think this goes back to what Daniel said regarding trust. And to continue what he just said, I think that you should ask the ones that do not connect to you. It might be the case that they don't trust you and of course it might be the case that they don't want you to tell you that they don't trust you so you need to get the information out of them in one way or another, but it can also, as we heard from our friend from Lebanon, that they don't trust each other. It might be the case that they rather change traffic outside of the country for some reason. So there might be business models that not only trust behind that that, you should try ask the ones that should be connected what is wrong here, is it the price, is it technology, what is ‑‑ what is going on here? So of course asking in this community is a good thing but in each area, in each culture there might be different reasons. So just condition with socialising and talk with these parties that you expect to be connected.
And one thing that might happen is just by having you establishing an IX it might be the case that these parties might actually launch a different IX just because they want still ‑‑ they might not use yours but that might ultimately be a success any ways even though your IX is not in use given that that thank is your ultimate goal.
OSAMA I AL‑DOSARY: Yes, if anyone else has comments later on, please feel free to stop me in the hallways at any point.
(Applause)
CHAIR: Please remember to rate ‑‑ to login and rate all the presentations. For the PC elections, please send in yourself‑nominations, today or today. As a comment, one of the current members has chosen not to restand so there will be a new member. It could be you. Please sign up. As we heard earlier, the diversity BoF will be happening in the next room at 1800. At 18:30 we get to meet the RIPE Executive Board and at 1900 we have the welcome reception. Also on the 6th floor. Thank you.
(Applause)
We still need more lightning talks so please use the form to submit them. We will let you know as soon as we receive them. And that's it.
