CHAIR: Welcome to the last Plenary session of today. First. Administrative matters of first five minutes will ‑‑ the five nominees will present themselves for the RIPE PC elections, so, you have a face with the name.
To be clear, the RIPE PC elections are starting from today. They are electorally votes, you can find the biographies on the website, and you can vote from today, from this very moment, until Thursday afternoon, 5:30 I believe, in the evening. The NRO elections are on Friday morning, these are paper, with paper ballots, traceable, and they are ‑‑ the NRO elections are from 9:00 to 10:30, 10:45.
So, can I ask the nominees to present themselves, to come here on stage and have a one‑minute pitch.
One minute, five candidates. Go ahead, please.
SPEAKER: Thank you for the opportunity to introduce myself to this community. I am Riccardo Gori, I am running a small service provider in Italy and I am also involved with the education processes with collaboration with the University of Bologna, and technical training centre in my area. I am formally what the community calls a new entrant, and I can see that I expected more incentives to IPv6 adoption, and so my decision to offer my collaboration in Programme Committee is to do my best, to have relevant content and attractive content for future meetings to see for those who want to see IPv6 bringing in this time. Thank you for your support.
(Applause)
SPEAKER: Hello, I am Thomas King, I am the guy from Monday who gave the talk about traffic volume dependencies on ‑‑ between IXPs. My motivation to serve the Programme Committee member is that I would like to solicit important and relevant work for Internet infrastructure and Internet security. From my point of view, as I'm the head of research and development at DE‑CIX, I hope that we can ‑‑ or I can contribute to the selection of an interesting programme for the next upcoming RIPE meetings. So, if you have any questions, please come to me and please vote for me. Thank you.
(Applause)
SPEAKER: You hear people talk about appealing to a wide audience and I have never seen it taken this literally. So to the people on the left and to the people on the right and to the people in the middle. I am a research engineer at SIDN. In my position I hover between software development and protocol issues and operations, and lately since I am also part of the privacy board, privacy issues and policy issues, I hope that that qualifies me to be a good member for the Programme Committee, and I think this is a great community where you meet people of all these groups. I must say that I think that the last few meetings have had brilliant programmes, so I can't say that I will definitely improve it, but I will be honoured if I would be given a chance to try. Thank you.
(Applause)
SPEAKER: Hi. For the ones who don't know me Martin Winter, I am also Working Group Chair for the Open Source Working Group, so I figured maybe I should propose up here too, I don't know what you think about our candidates or if you think Working Group Chairs should actually have another role on the PC. So, for the ones who don't know me, I work on Open Source, I work for non‑profit, and you can see in your networks always how much more important Open Source is becoming so I think it would be quite good to support that and like see how the role of the RIPE in that direction, I also have a few ideas about more from tutorials because I see RIPE really a great place for exchanging ideas, sharing ideas there and it's not just a peering conference like some of the other meetings in other regions. Thank you.
(Applause)
SPEAKER: I am not Mike Hughes. However, as one of the unelected members of the PC, I was asked, as Mike is standing, so very briefly just speak as him, if you can imagine me a bit shorter, same amount of hair, an English accent. Mike is a current member of the PC, he wishes to get another term on the PC. For those of you who don't know him he has been around the RIPE community and technical community for a very long time. Still working hard, not the things he started with but still doing lots of interesting stuff with lots of interesting people and giving lots of interesting ideas to the PC. So, unfortunately, he can't make it this week, but this is the first RIPE meeting he has missed in a very long time. So, yes, his bio is up on the page as well, and I will now return to being Brian Nisbet. Thank you.
(Applause)
CHAIR: Hi, my name is [Sergey], I am chairing this session. Our first speaker is George Michaelson, with the topic of look under the hood of devices with IPv6. He is welcome.
GEORGE MICHAELSON: Hello. So, as you know, we have been doing measurements with adverts for a very long time. I actually went out looking to see if I could find other own ad and I couldn't but I did find an mazing YouTube video about an Android device that I'd like to buy. If any of you know stocks I'd like it. The reason I put the slide up is it shows exactly where the adverts appear that we are using as our active measurement and we take information from these ads and we use it to draw graphs like this that I think you might have seen. We have been doing this for a long time. There is about five years of data here. We like to think of this as it's what people really do, measurement. It's not an estimation. It's not a model. Actually going out and seeing what happens when people do things on net and we are currently gathering somewhere between 12 and 15 million a day of which about 8 to ten million are usable. That is a very large amount of data. When we started this, there was probably more like 250,000. So we'd got a solid amount of data coming in, we are doing an adjustment based on the variance of placement of the ads to try and account for a reflection of what the real effects of deployment of systems like DNSSEC and v6 is like in the world. So we were using Flash. And Flash, as it turns out, is not actually a very good basis of a long‑term measurement nowadays. The first thing is that it's increasingly not there. Users are consciously turning it off. It's got a huge list of exploits. I don't know if any of you have looked at the various databases of CVEs as against Flash. It's depressing. There is something like 160 of them in this year alone and more every day. It's become a bit of a problem. And Google, whose primary income stream is advertising, has been responsive about this and they actually responded to the community and said okay, that's it, from September we're turning off this mechanism for advertising which, after all, is their primary income method. They just said it's over.
Now, that's really not very good for us as measurement people because we really depended on this. So, it's kind of, oh, my God, is everything over?
But we had a plan because we had been working for a while on some new technology using Java script with quite a lot of work went into developing this to deploy in different ways and we had code ready to run. So, we went ahead with the deployment. We actually went through certification with Google on this and we have been running it in parallel and then finally in September we cut over and have within measuring almost exclusively using this new framework. There are some issues in the graph. I think people that have looked in our data there are some discontinuities but we do believe fundamentally the story has remained the same. There is this thing in the background, the Flash it turns out was basically measuring Windows devices. Yes, it was available on other platforms but in practice, it had stopped measuring them, so to a certain extent we were really tracking deployment of DNSSEC v6 in the network using Windows.
And because Windows doesn't run on cellular very much except for this indirect method through things like Wi‑Fi portable basis station, we weren't table to talk about what was going on in the world of cellular. We now see that. We see a lot more devices. We see a lot more information about what's going on out there.
So, just to be quite clear, we sometimes ‑‑ I know I have been very bad about this. Use sloppy language. It's easy to fall in saying market share, the amount of market this thing is doing. We're not really seeing market share as much as eyeball share, we depending on a random placement and we have a very strong belief that we're seeing random fresh IP addresses. But it's not necessarily the same as market share in the sense a lot of other people talk about it. It's the distribution of effective eyes in a browser looking at services online.
So, it's a first approximation, it's relative. There are some economies where it's not really a very good fit at all, but overall, it is a remarkably good fit for the kind of relativities of use of different providers that you guys are used to. I get a sense of this because I have spoken to a lot of you about it and said look are these charts reflecting what you believe about your own economy? By and large you say yes.
What are we seeing there? Well let's take this one, take Sky UK, a big nationwide cable provider, they are not doing cellular but they have a lot of home Wi‑Fi and they have been absolutely remorseless about deploying Ipv6, they are doing huge numbers of people. So, on our chart of eyeball share they are approximately 20% of the UK market. They are the top of the top three and, between them, these three have 60% of the whole of the UK view of activity on YouTube. It's a fairly good approximation of what's going on in the distribution of market share in that economy. So here is the overall view of v6, very, very nice rapid up take from June, July, through to kind of September when things tail off a bit. It turns out that this is actually quite mechanistically related to how these guys are engineering deployment they have paused in order to assess what's gone on. They are still committed to a full scale deployment and they expect to be complete in 2016. So this is the level of v6 capability for the non mobile devices. It's actually higher than the average figure. It's more like 25%.
This is the mobile device component and you have got to remember that a lot of these devices are connecting through older base stations at home that maybe can't actually do v6 slack properly, although there is v6 being presented to the door it doesn't necessarily mean that in the home they have got exposure to 6.
If you look here at the distinction between iOS and Android, there is an anomaly that appears. The essential quality is the mobile devices are being seen broadly doing the same behaviour. So, in cable, we're not seeing any bias on type. There is a certain amount, will these mobile devices have a lower intensity but, in general, if you can do 6 at home and you have modern equipment you can do 6 on any device. This is a really significant deployment. The UK has been lagging for v6 up take, they are going to be at 20% by the end of of 2016 from this single deployment nationwide and it's a really interesting question what it's going to do to the rest of the market.
What about the places that are doing address translation models? Because we know Apple made a very conscious decision not to support one of the primary translation mechanisms. So, if we know there's a lot of iOS we can say, well, are we going to see this when we know the deployment is using the transition technology? But we know, it mobile is using this technology and we know that they are predominantly in cellular. So, we should be able to see this fairly clearly.
This is the overall level of penetration of v6 capability in T‑Mobile and you can see that it's pretty much holding somewhere north of 60%, bit of a tail‑off at the end. Well this is the amount that's coming from DNSSEC top devices which is really quite high when you think they don't traditionally have direct presence on a carrier. But this is how many of of it is coming from the mobile sector, which is pretty much all of the visible v6 capability. And if you divide it by type, it's significantly higher in Android and there is virtually no iOS which is exactly what you expect from this transition technology. So there is a quality that when we look at end user capability using a mechanism we know cannot work in iOS, that's exactly what we see.
Okay, the mechanism is also clearly working. I mean 80% v6 capability across the board, that's phenomenal and that means now for a significant amount of the day to day traffic that people are doing, because pretty much everything people do is going to these core content providers that are now dual stack, it's happening over 6. So, if you're in a world where it makes sense to do this, if you don't have a large amount of iOS device, this technology could work for you really, really well.
Korea: Korea has been moving. We know there's been a significant deployment of broadband in that country that was using technology which just can't upgrade. It's very specific CPE technology built in‑house, it's never going to get upgraded in the field. But in cellular it's a different story. There is nothing which is so concretely a road‑blocker, you can decide to deploy the intermediate equipment in your cellular technology that supports translation. So we have seen that, this is S‑K Telecom, they are about 50% of the national market in Korea. They have actually more mobile devices than broadband at home. It's reached the point that they now have more mobile devices than the population. And they already have about 4 million people converted over using the 464 translate technology. They are using a specific APN and are kind of doing this the rational way to prevent people getting blocked by a network of v6 that they can't use. This is the overall penetration that we are seeing which is tracking at 20%, somewhere around the percentage we would expect from 20 million customers, 4 million of them enabled, that looks about right.
So if we look at non‑mobile devices, there are virtually none. If we look at the overall mobile rate it's tracking, and if we look at the Android verse iOS again we get a really nice clear signal, there is no functional v6 capability happening in this carrier using that technology. So we are getting a nice clear signal we can see this.
Okay, so, can we see this anywhere else? If we see high Android capability, low iOS capability, it's probably a nice strong signal. What can we see?
This is the overall figure in America. We are seeing somewhere around 25% of the US market is now v6‑capable. Now, just think about that. America is 300 million people. And they are already at 25% penetration. So I think we can kind of go with the sense there's a lot of v6 in the US.
This is the top view, the top ten of the ASN that we're seeing by eyeball share and you can see that the players at the top league here are very well understood. AT&T, they are across both cellular and home service, we think they are doing a true dual stack deployment. Verizon, through dual stack, mainly cellular and Wi‑Fi, Comcast, they are a huge national cable provider, they have got a massive triple play model they are doing in 6, they are committed to this. There is sprint in there with a mix of different technology. So here is AT&T.
Well, there is no clear distinction between mobile and non‑mobile device. So whatever they're doing in their 6 story it's pretty clear they are not using 464 translation.
But, there's another division of AT&T. There is the AT&T mobility AS and this one has a very clear separation. Now I have no idea what they are doing, I have not spoken to anyone from this AS but it looks to me this is quite a strong candidate for some kind of transition technology. It might be about an APN, it might be a number things but it looks compelling.
This is Verizon. This is kind of this weird signal that there is a lower level of intensity on non‑mobile devices but that's to be expected if their predominant presence is in cellular. Again, it's really strongly grouped. There is no clear statement that they are using a transition mechanism.
Comcast: Well we know they are a cable plan, they are not using transition mechanism, really strong grouping. No sense that it's kind of differentiated by device. It is below the threshold that we saw on T‑Mobile but they have a lot of legacy equipment so there's this whole thing of home networks that aren't capable of using 6 even though 6 is being delivered to the door.
Sprint: Well, Sprint is kind of funny. There is qualities there that it's a differential but I would be really hard‑pressed to say I understood what's going on there.
How about anywhere else? I thought this one was a lovely clear signal. I wanted to believe this. I mean, look at that. This is just heading to exactly where you'd want to be. Okay, maybe not. That was kind of a strange moment there. I have no idea what happened in our data stream, but the thing you should notice here is when we had this huge surge of v6 capability in the mobile device class, it tracked one for one Working Group Android. There was no real increase in iOS. So, again, I think it's very likely that Orange Poland is using a transition technology like 464 translate.
So, how about other big places? Well, this is Equador, it's about a 20 million population. It's had a really noticeable v6 uptake. And if you look here you can see that about 40% of the eyeball share is coming from a single provider who have obviously made a large commitment to v6.
There's a fairly strong grouping. There's no real sense that they are engaging in any kind of transition mechanism. This is Brazil. Top two providers that we see in our data who are probably providing about 30 to 40% of the whole economy's share of customers. Again, it's noisy but there's no real sense that these guys are using transition technology. This is just Claro. I chose one of them. Peru, another big provider. This one is Telefonica. This is fascinating because Telefonica are everywhere, they have made huge inroads across south and central America but they are also big in Europe. The thing is, they all run independently as completely separate individuals but they share the supply chain. This came up in the LACNIC meeting. If one Telefonica division makes a decision to do something in v6, you can be confident that the same equipment is being acquired by other Telefonica divisions, because they centralise the purchasing and these guys, they have done a fairly big deployment and there's no sense of bias against iOS, so in principle this could be happening anywhere, Telefonica's running service.
Now, the weird thing here is, that I have got a fairly strong sense from talking with people in central and South America, people can't afford to buy Apple devices, there is a huge Apple tax consequence, of flat Apple pricing because a lot of these economies have issues with foreign currency and so they don't want you to buy devices at a high US‑dollar rate. People actually deliberately go and fly to America to do shopping for goods, and they told me, I spoke to people in LACNIC when I was there, they said it's quite normal to have a huge shopping list, and when you fly into Washington for a meeting, or California, you spend thousands of dollars and buy goods that you cannot routinely get in your own economy because things are just really expensive there. Now, Android has a massive price difference. You can buy cheap Android devices, you can buy expensive ones. So, you would expect that there would be a very low level of penetration in South America, which means 464 translation could work really well in that economy. But there's no sign of it. It looks like they are not doing it which is kind of interesting.
Okay. Canada is another economy that moved recently. This is pretty much down to one provider: [Teelus], again strong grouping. There is no sense they are in any gang.
This is Finland, and this is coming from their second ranked provider, DNA, now, this is really bizarre because they show next to no Android capability compared to iOS. Why would that be? IOS is the one that doesn't like transition mechanism. Why would you not have functional v6 over Android? So it did occur to me this might relate to a decision inside the Android OS development to only do DHCPv6 prefix distribution and not do it straight. Maybe there's something about how that provider has enabled v6, I don't know I I would have thought they'd do SLAAC but it's possible that something is going on there that functionally suppressing the v6 capability in Android. Because it's working fine for everyone else.
Norway: I know the trend line looks down. This is the Internet. All graphs should go up and to the right. It's a short‑term thing.
Again this is pretty much down to a single provider. You can see that Telenor is showing up as 50% of the visible presentations of our ad. Now, they kind of have this weird signal going all over the place but there is some functional separation between the two operationing systems in mobiles, it looks to me like transition mechanism. I don't know.
For the local hosts I thought I'd put up a couple of cases to give you a sense of what's going on in this economy. Now both of these are showing really significant deployment, again this is a 20‑million‑person economy, so this is quite a large economy to have a functional v6 deployment. This is RCS and RDS, they moved a long time ago. Interestingly, they show a lower level of penetration into mobile devices compared to the desktop. I suspect this is going to ‑‑ they are doing something that's predominantly in a home‑use case and most of the Wi‑Fi stations sold here that are older are probably not going to be doing 6.
Voxility is another one that's amazing, they have had a massive uptake, they are right up at 80, 90% capability. Not in mobile devices. Again I know nothing about the technology bases these guys are using but this is a large significant deployment of 6 that's happened very, very rapidly.
So, we have moved away from Flash, we no longer have a dependency on a mechanism that's ageing out. We are seeing inside the networks, we are getting some sense of what people are actually doing, seeing different deployment techniques and I kind of want to say even if you don't like transition mechanisms like 464 translate they obviously work and in the right circumstances, they can reduce pressure on the CGN you are inevitably going to have to deploy but they don't work with iOS. That may not matter depending on your local economic conditions.
I'd like to thank the obvious people, Google for helping us with this measurement, ISC for hosting equipment, the RIPE NCC for helping with hosting and if you are interested in any of these measurements you should talk to me or Geoff at the bar about this, there is lots of stuff we can do. Thank you.
CHAIR: Thank you very much. Questions?
AUDIENCE SPEAKER: Hi, Daniel Karrenberg, RIPE NCC. I'm really intrigued by some of the strange signals that you get there of a general level of X and then suddenly like a couple of weeks it's X divided by 5 or something. Did you look at the, you know, other signals such as absolute number of results you get and things like that?
GEORGE MICHAELSON: Yes, and it is, unfortunately, very related. There are places where the sample‑set is small and the divergence is really strongly correlated for some of these ASs by huge variances in the volume. The thing with Google is that they do ‑‑ they try really hard to be an honest broker for fresh eyeballs but they have these other dimensionses. You said you wanted to be on mobiles and we have a belief about the mix of mobile devices, so in a day we have to try to achieve that mix which by the way we, APNIC, can't easily control. So if they think they have already achieved 10% presentation on Apple they might choose not to show any more and that kind of effect can have a huge disparity at an AS level on the number of devices seen of which category. So yes, there is an effect that relates to volume and also some of the tuning we can't control.
DANIEL KARRENBERG: But it would be really interesting to hear a presentation about those limitations of this particular method, you know, both as a disclaimer and also as a means of understanding whether it's valid or not.
GEORGE MICHAELSON: Point taken. That's one for discussion. Thank you.
AUDIENCE SPEAKER: I guess the lack of Android support is because users need to turn IPv6 in their devices, in older ‑‑
GEORGE MICHAELSON: In the older Android versions pre‑4.1. So you think you have quite a high population of the older Android.
AUDIENCE SPEAKER: I guess so.
GEORGE MICHAELSON: That could well be the case because it's very surprising.
AUDIENCE SPEAKER: And also for some newer equipment also, I guess only the latest models have it on by default.
GEORGE MICHAELSON: I should say, by the way, it's a very impressive deployment. You have had a massive effect on the overall national figures in your economy, so well done.
(Applause)
CHAIR: Thank you very much. The next speaker is Yves Vanaubel.
YVES VANAUBEL: So this is a joint work with Paschal and George from the University of Strasbourg and my super advisor.
So this presentation will be about MPLS. So, I will give you a small background about this protocol.
After this, I will explain to you how we are able to reveal MPLS from trace router.
After having introduced our newer algorithm, which is able to reveal the usage of MPLS nodes in autonomous systems and finally I conclude this presentation.
Let's talk about the background. So, MPLS was designed in order to improve the speed in the Internet. Everything is based on labels, it is easier and faster to compare a fixed‑line label than IP prefixes. So, let's define label stack entry. It's composed 32 bits, inserted between Mac and IP layer and it's composed of 20 bit labels. Used for the type of service, but term of stack because in MPLS, in a packet you may have multiple labels, so a stack of labels for example in VPNs. The bottom of stack is used to say okay, here this is the last label in the stack. And finally a time to reveal a bit, it has the same aim at ITTL field.
So let's speak about the network architecture, let's admit we have the packet and this packet must be sent in the network. I do not see the packet, sorry, so focused on the architecture, so here we have the ingress, LSR, that is the first router that will push the first label in the packet. At the opposite we have the egress LSR, it's the one that will pop the label stack. These are called label edge routers, because they are at the edges of the channel. Inside the channel, in the core we have the first hop, the first router which will only work with MPLS label, so, this is done based on the labels. And the last hop is the last one.
The difference core routers from what we called the label searching paths. In MPLS, we have a special behaviour which is PHP, penultimate hop popping. It is activated. The last hop will hop the label stack, before the egress and only to improve the speed because in this case the egress receives only an IP packet and make the other packets directly based on the IP address.
So, I don't know why it is not in the right order. So here the packets arrives at the ingress LSR. Based on its label information base, so it's table containing different information, so, based on the input interface and the input labels, the router will check the table and know the outward labels and the next hop in the MPLS network. So, in this case, based on the destination and the ingress knows it must push label 4, for example. And the packet is sent to the first hop. Is sent to the first hop. The first hop will check its table and see, okay, I must switch, swap the label by label 5 and then forward it to the next hop, and so on. Until the packet reaches the last hop. If PHP is activated, in most of the cases we consider it's activated because it's the default behaviour in Cisco routers, the label is hopped and the packet is forwarded to the destination.
If we need to, we need to create and to fill the label information base at each router, so we need the protocol to distribute the different MPLS labels amongst the different MPLS routers. This is done thanks to the label distribution protocol. LDP, this allows the distribution amongst the different routers. So here, FEC, a FEC, it's the set of packets that are forwarded in the same way. So here, with LDP FECs are, in fact, iBGP routing tables. Labels are distributed down stream, meaning the first router that will associate a label to the FEC is the egress router. Then it forwards, it says, for example, the ICS label is to this FEC and then forwards the information to the previous hop, which is the last hop. The last hop will choose the label 4 in the FEC and forward the information, and so on, until it reaches the ingress router. Every message follows the IP route.
There is another protocol called RSVP, with a traffic engineering extension. In this case, the ingress is able to pre‑calculate a route which may be different from the IP route. Moreover, multiple resources may be allocated on the path. So it is used for traffic engineering.
So, let's focus on how we are able to reveal MPLS from traceroute attack. We need two options because, as you know, trace route works with ‑‑ and MPLS are labels. These are not activated.
Here, the first option is an ICMP extension, RFC 4950, if it is activated and MPLS router that must generate a time‑exceeded message, should quote the MPLS tack inside this packet.
The second option is the TTL propagation. As you know, the ingress router must initialise the LSE TTL field. However, if the option is activated, the ingress will check the value inside the IPT TTL and copy this value in the LSE TTL.
The opposite operation is done by the egress LER.
Let's see what's happening. So, here we have a trace. And once we enter the MPLS channels, we have the IP addresses, the different routers will reveal themselves thanks to the TTL propagation, and we know that these are MPLS routers because they return the label stack.
Okay. Let's think about our new algorithm. What are our motivations in fact between an entry and exit point in an MPLS trace route, you must have multiple paths. These paths may be different in terms of IP addresses, for example, the blue and the red label passage on the screen. Or in terms of labels. So the IP addresses are the same, but the labels are different. For example, for ‑‑ you have different resource allocations depending on the path. So here we have, for example, the blue and the orange paths.
LPR is the label pattern recognition algorithm. It's allows to distinguish the usage of LDP versus ‑‑ the behaviour of LDP and RSVP‑TE based on labels and IP addresses. So we will in fact observe if we have load balancing or a basic usage of MPLS, or traffic engineering. It's a method, so you collect your trace route and then off‑line you apply on the data and we do not require another proposing than trace route.
LPR applies on transitionals because we want to be able to realise a per AS [duty], so we focus on transit channels and it's set over kind of channels were negligible. So let's define an IOTP ‑‑ it's an increase/egress peer, meaning a set of export channels having the same entry and exit points.
So, LPR will classify each IOTP depending on the address and levers, meaning we observed always the same IP addresses and same labels so we only have one LSP. Multi‑storey FEC, we have multiple LSPs and they are used for traffic engineering. Mono‑FEC, load balancing, and finally, the unclassified class, if we did not succeed in classifying the channel in one of the three first classes.
LPR works in two main steps. First, we have a data filtering and formatting so we focus on transit channels so the filters will delete over times of channels form and also delete routing instabilities that we may take as engineering. Then we have the classification step.
Let's focus on the first class. Here is the Mono‑LSP class. Here, the grey dots mean an interface. So, let's say we have two traces. Here, we have the blue trace with the different IP addresses, A, B, C and D, and two labels, L1 and L2, here we admit we have kind of PHP which is activated. And the orange trace, and if we compare the labels from the two traces we see that they are identical. So we always have the same IP addresses, the same labels, okay, it's Mono‑LSP, we only have one LSP.
Let's focus on traffic engineering, the multi‑FEC class. Here, something important, that if LDP is used in transit channels, in fact the egress will announce its look‑back address and bind a labels with look‑back address. It's because core routers, core MPLS routers will not know about external destinations, they are ‑‑ IP‑routing table are limited. So, the ingress will, based on the BGP next hop, simply know the exit point, so the egress, and, based on it, will associate the right label it has chosen. So here, knowing this, we have two traces, in this case we have different IP addresses, and we will focus on the common IP addresses. Why? Because if the IP is common in the two traces, it means that we have a given router and because it's a look back address which is announced because we only have one destination, it should always announce the same label. If the label is not identical, it means it was not LDP, but RFDP, the distinction must be verified for at least one common IP address in the path.
Here, for the third class, load balancing. Again, you have our two traces, but here at the common IP, we have common labels. And if this condition is verified for each common IP on the two traces, we can see that it's load balancing.
With the road balancing class we have a special case which is parallel links, so if we observed different IP addresses at each hop but however the labels are identical, we know that in fact thanks to the look‑back address and mapping to a label, we know that okay, here, these addresses in fact belong to the same router, so, these addresses are aliases, it's a technique we know that we are in a paralleling architecture.
Last class, in the case of PHP, the last hop will pop the label and if the common IP addresses is, in fact, only the ingress and the egress, we do not have any labels to compare, and so cannot take any decision and we arbitrarily check the channel and classify.
We realise data collection so thanks to the ‑‑ this platform, it's more than 100 monitors scattered all around the world, they are divided into three teams. These notes realise Paris traceroute to all routed /24 prefixes.
We worked on five years of data collected between January 2010 and December 2014. We defined a cycle as the first monthly run of each team. So we gathered the three teams together and so we have one cycle per month, we have 60 months, so 60 cycles. For each cycle, we realised an IP 2 as mapping using route views data and extracted the channels. Let's define some basic metrics before talking about results. The length of an IOTP. It's another of LSRs in the longest path. The width is the number of branches in the IOTP, these may be logical or physical. And the symmetry, is the difference between the IOTP length and the number of LSRs in the shortest LSB.
Here is the PDF for the length of the channels, for December 2014. And what we observe is that channels are rather short, in more than 65% of the cases, they are maximum three addresses.
Let's focus on the width. So, again, a PDF and we see that in more than 50% of the cases, it's only a length of 1 ‑‑ a width of one, sorry, one branch. However, by definition only the Mono‑LSP class force into this category so we delete it and we observed only the two other classes. And what we observed is that the distribution is identical. It may be surprising because we could say okay, here for traffic engineering we will have multiple paths that will be different, depending on the policies, but here we see that the distribution is identical to load balancing. If you focus on the symmetry. If the symmetry is zero it means that the channel is set balanced, meaning that we have the number of LSRs in each branch. Again, we have identical distributions between paths, load balancing and traffic engineering and knowing also our results with the length ends and the width, we can say that in over provision network where [bound] is efficiently evident, in fact, doing traffic engineering it's more like results reservation than taking different paths.
Let's focus on the classification for well‑known autonomous systems. Here, at the bottom, you have the number of that were classified by our algorithm. And on the top we have a PDF for different classes. On the X axis, these are the different cycles.
For Vodafone we observed that they attempted to use quite a lot of traffic engineering. And some Mono‑LSP class meaning basic usage for forwarding. Then, for NCT, we observed, most of the time, channels, Mono‑LSP class, so a basic usage MPLS. For at that time a communications, more load balancing. And some basic usage and for AT&T, we have kind of ‑‑ so, at the beginning, simple usage with a load balancing, but at some point we have a change in the behaviour and some traffic engineering tends to appear in this autonomous system.
So, let's conclude. We presented a new algorithm called LPR which is able to reveal MPLS usage in autonomous systems. We find three types of usage, so basic usage always the same path. Traffic engineering and load balancing with two cases, the ‑‑ all paralleling architecture.
What we observed is that MPLS usage increases over time. Most operators seems to deploy MPLS, but its usage depends on the autonomous system. Most of the time you have a basic usage, with load balancing but sometimes they try to deploy some traffic engineering. Which is less common.
We observed that when we have load balancing, the parallel architecture is quite often used. When we have traffic engineering, in many cases, it's more something like results reservation than defining multiple paths between an entry and exit points.
So, okay, that's all from me. Thank you.
(Applause)
CHAIR: Any questions?
Are you also in contact with the industry, with ISPs operators, looking at your algorithm and they see a use case for their networks?
YVES VANAUBEL: I don't have any contact, but I would be very happy to have some label information basis or things like that to be able to prove our algorithm.
CHAIR: So an open invitation here to the room. Talk with Yves about his work and if you have any interest in looking into his work. Thank you again.
(Applause)
So for the people who monitor the agenda, they can see there are four lightning talks on the agenda. So either we are very enthusiastic and accepted or we just erred and cannot count. Well, maybe I can tell you that over a beer. For now, I do appeal to your stamina and stay here in the room for another four lightning talks, so, Massimo...
MASSIMO CANDELA: So, good afternoon everybody. My name is Massimo Candela I work for RIPE NCC in the science division. My role is to create application for the analysis and visualisation of networking data. And today, I want to show you a new version of BGPlay that I did.
This is this tool that allows you to BGP data, so basically you provide the resource and it gives you a graph about the visibility of the research. The screen‑shot that you see here is the version installed in RIPE Stat. It basically has been implemented by the Computer Net Research Group in collaboration with RIPE NCC, at the time I was in Roma Tre and basically it uses the routing information of RIPE NCC.
How does it work? You imagine there was an outage yesterday between 3 and 4 p.m.. you provide ‑‑ you going on RIPE Stat, you write the prefix was affected by the outage, you provide the time range, and this application is going to download all the data available on RIS and will show you this graph of visibility plus all the status of the graph in the time range. So, this is nice, because you can analyse past BGP events, or verify BGP configuration but there is something missing. So, usually one of the feedbacks that we get often is like, well the operator needs to understand and respond quickly to ongoing BGP issues. So, we have to provide some kind of realtime.
It's also the time is also mature because they are collecting projects about BGP data, they are moving words to this direction. So, for example, the new routing information service, there would be an update on Thursday in the routing session. The Isolario project, that's from the Italian National Research Council. They have already a production version that streams BGP data with web sockets, and also on Thursday in the routing session, there is another ‑‑ there is a presentation. BGPstream from CAIDA and BGPMon from Colorado State University. It's also time to update the tool.
So, that's what I'm presenting to you today, is ‑‑ let's say, the main goal of this version is that you are in your data centre, you use this application, you put it on a wall mounted monitor and you monitor in realtime your prefix or prefixes or autonomous system. So, it's based on web socket in a browser with no third‑party plug‑ins, no Java, you can use your data, your private one if you want.
It's currently integrated in Isolario, so you can ‑‑ and that's the platform that I used for my experiments so you can go there and have fun.
It's almost integrated in BGPstream. It's ongoing. And it's in RIPE Stat, but also in the new realtime RIS service is going to be published, you will be able to have fun also in RIPE Stat.
So, just to show you something a bit more practical. This is the interface is basically the same. There is a new button on the top right where you can toggle on and off the streaming. One of the differences that, at the bottom, the time‑lines are completely empty because they are going to be filled in with samples. So, what you see here in this assimilated hijack, all the autonomous systems are fake; it's just a simulated environment. You have the autonomous system in red in the centre is the one originating a /24, and the blue autonomous systems are the one ‑‑ they are doing a peering session with our route collectors. The black one are other autonomous systems involved in the routing.
So, what is going to happen now, this is situation is completely stable, so I'm going to type something in the shell and I will create another autonomous system, and I will announce the same exactly the same prefix, the same /24. As I do it, the path should converge. Let's see... it should work...
The path should appear in another autonomous system and all the paths should converge to the new autonomous system but it's working. Oh, there we go... it's working...
So, they are slow in moving to the new autonomous system that's doing this hijack. So, now to bring back the visibility I just start announcing to the original AS, the two some more specific /25 and slowly the path will converge back to the other autonomous system. This is ‑‑ you see this green stuff are the new events recollect the new announcement. This is completely in realtime, using the streaming and the Isolario prototype. And basically you see the slowly the path will converge back. This is a kind of hijack similar to the Pakistan Telekom in YouTube of 2008. There we go... so the visibility of the other one is going to be almost nil at the end.
So, I'm not going to do now a live demo, but you can have fun with that, so if you try to use your prefix, it's not going to be fun for you, I hope, because basically it's probably stable, so you are not going to see too many stuff so a nice way for doing a nice demo is to use this awesome resource provided from Geoff Huston, so there is this most active prefix, you copy one of these prefix, you put it in there and you just enjoy the streaming of the realtime events.
So, this presentation is mostly to inform you that this is an Open Source project, it's on GIT up, you can use it, use your data, embed in your page, and, if you want to, there are already other applications built on top of this. So if you want to collaborate or receive information how to use it with your data or you want to send me feedback, please don't hesitate. This is my e‑mail, and basically that's all. And it was a short presentation. So, if you have questions, that's the right moment.
(Applause)
CHAIR: Thank you Massimo. Questions? No questions. Everyone knows what BGPlay is. Thank you very much again.
So, the next speaker is Emile Aben from the NCC, to talk on measuring multiCDNs.
EMILE ABEN: This lightning talk is about measuring multi‑CDNs and I hope by the end of this talk they look like jelly fish.
So, a little bit of background. You all know BGP, you can steer traffic wherever you want. You can also use DNS, but if you use DNS that's under the control of whoever controls the host name and what I'm talking about is people that use host names and map these two IPs differential for different hosts, so an example is Wikipedia that we measured where you can see, depending on where you are, the answer you get, you are going to be directed to either Amsterdam or one of the US coasts. That's what I mean by a DNS‑based traffic steering, it's fairly common.
Another thing is CDNs versus multiCDNs, I guess everyone knows what it is. You can use multiple of these and that's been going on for a while already. And what you can do with that is you can leverage the strength of each single one. And why I'm interested in this is that there's really big deployments of this, and the special case there is the operating system updates that Microsoft and Apple do. These are multi‑CDN based. You as an operator, right before one of these big updates, do you know where the traffic is actually going to go? What CDN is going to be hit? Because these are fairly ‑‑ I think it's the biggest spikes you are typically going to get on networks.
So, the logical question is: Can we measure this? And yes, we can. With RIPE Atlas. But only if you have a steering host name. You have to have this little bit of magic that, where the host name that actually controls where ‑‑ what multiCDN is going to be hit and that CDN is going to then distribute that further. For instance, this is one for Apple. So, if you have these host names and you can only do this in these cases, so if there's application logic involved into the distribution, this technique won't work because RIPE Atlas doesn't do that.
You can just do a measurement towards these host names, resolve the IP ‑‑ that measurements is going to resolve the IP addresses if you configure it correctly, or resolve the host name to IP addresses, these are going to be a lots of different IP addresses and you can map both the hosts, so the RIPE Atlas hosts and the IP addresses you get back two ASNs and then you have your mappings, right. So the result of doing this measurement and I did a couple of these for all of the RIPE Atlas probes, is pairs of source destinations autonomous systems.
And then you can make pretty pictures. This is the Apple multiCDN around ‑‑ a little bit after the iOS update 8 and it looks like a jelly fish. So what you see here actually is ‑‑ and I don't think it comes across on here ‑‑ so, if you really want to see... do the download to the PDF on the programme, is, these are blue nodes, that's the sources of the measurements, so the RIPE Atlas probes. And there is an orange node, so that's the CDN, that's where you get your content from. And there's also blue nodes that are both source and destination, so if you have a local cache, your probe resolves towards something in the same way as, you'll have a green node. And what you'll see here is multiCDN. Apple has its own CDN. You'll see Limelight. You'll see Akamai, level 3, these, I'm not sure, I think they are large caches but it could also be very local CDN products. So it's a fair number of nodes hitting a single other AS and you see the local caches and this is actually a forward‑directed graph so that all makes it nice and pretty. And, as with jelly fish, this thing also evolves, so here we have iOS 9. Apple, they have been working really hard to ‑‑ what you see here is basically a lot of probes hitting the Apple CDN. Level 3, Akamai, and the local caches, of course, around, and so, can we also do this technique for other multiCDNs? And of course Microsoft, because that's the next big ‑‑ the other really big thing. Same type of visualisation, Akamai here, level 3 there, Microsoft there. I have a little problem with this one because I think Limelight is also heavily involved and I don't see them in the measurements, so it could be that I have the wrong host name, so if anybody has a better intelligence on that, I tried to ask around but I haven't found the answer, why it's missing. But you can still see multiple CDNs and you see IPv4 here so that means the next slide is an IPv6 slide. And yes, they have IPv6 enabled their CDN. But you'll see level 3 and Akamai and Microsoft, the Microsoft CDN itself is missing so you can actually do funky things with that.
So, now, we have made nice and pretty pictures, but ‑‑ and here I have to thank Randy Bush who has been coming to the RIPE NCC office to hammer the sense into me that how can you make stuff useful for operators? Because these pictures are probably not that useful to you. So, here I need your input. How can we make this most useful to you? Awareness? I have actually prototyped a little tool, you say multiCDN, you say an AS, in this case the AS where my home connection is, you say the CDN, and you give it a date and then it will just output you what percentage of lookups it saw going through what other ASs. So, you can help there figure out what ‑‑ if the next thing is happening, where that traffic is probably going to go. Of course it could switch the date. Would people want alerts? And of course which multiCDNs and host names to follow? I'm this small potato and I hope there is a lot of others and together we can find whatever useful set of host names we can just do the RIPE Atlas measurements and make this like a community resource on actually seeing where these really big flows of traffic go.
If other people have ideas, I'm happy to hear and my plan is, after collecting, some feedback, writing this up on RIPE Labs and make this, if you look hard on my GitHub account you'll actually find it. It's really prototypey, it's RIPE Atlas tools‑based, but it's buggy, so if you want to help debug, that's appreciated.
Well, that's the end of it for me. If people have questions, I'd happily take them.
(Applause)
AUDIENCE SPEAKER: Rudiger Volk, Deutsche Telekom. Have you verified with any significant service provider that your picture actually tracks most of the actual traffic flows? My understanding of how the more sophisticated, say, larger CDNs are controlling the interesting traffic flow is in what you said, what you classified as application logic, and that essentially means my understanding is well, okay, they are looking which resolver is asking and figuring out in the application logic what server to send the actual content requests to.
EMILE ABEN: I, for one of the two multiCDN deployments that I have been in contact with them to actually verify what's being done there. So, for the others, I tried and I haven't made contact yet. So... certainly there's limitations to doing it like this. But maybe it's also a call to whoever uses multiCDNs, if you want to provide everybody who is ‑‑ whose traffic you're steering, it's nice to give them some visibility into whatever you are doing.
RUDIGER VOLK: Sure. I would always expect that having both ‑‑ well, okay, the content providers quite certainly are seeing what requests are coming in and controlling stuff. Of course, them optimising things in their way and us, as network providers, trying to do our optmisation in the ships‑in‑the‑night mode, of course usually does not really result in good coordination and good resource use.
EMILE ABEN: Maybe that's this, this is a call for measurement data to actually help you make the best of the Internet.
CHAIR: The last speaker.
CIPRIAN MARGINEAN: Hello everyone. I am a network engineer for Amsterdam internet exchange. Today, I'm going to introduce you to the newest addition to our family, the Falcons.
Earlier this year, in May, my colleagues have presented to the [more] IP event our intention to joining the fight against BGP prefix hijacking by building a system of tools that enable our members and customers to quickly set up policies on their routers without the need of going to the effort of installing and setting up the required infrastructure on their side.
The Falcons are a code name for a new pair of route servers based on BIRD version 1.5, hence the name, and are available for new only at the.Amsterdam exchange point. We chose BIRD for this new implementation because of the stability so far, and because the other vendors' equipment does not scale to over 700 peers, or didn't support all the features we needed.
After attending yesterday's presentations, it's become clear to me that most of you present here are aware that the Internet is far from being a perfect place in terms of security, and that Internet service providers are confronted daily with prefix hijacking. It's not only our customers that are affected by these events; in fact, we're all suffering because of them. Some will lose customers, some lose revenue and some of us lose sleep and gain grey hairs.
How does this system work? We basically have two ways of checking for prefix validity. This is the RPKI information and the IRRdb. The BGP forces each incoming announcement and checks the prefix against the ROA entry or against the route objects for IRRdb. Depending on the result we tag the prefix with the the unique BGP communities, corresponding to the valid, invalid or unknown state.
Apart from the RPKI and IRRdb prefix validation features, we have added to the Falcons some other exciting ones like BGP community‑based route policy and per neighbour AS path depending.
So, how does it work?
In order for a customer to peer with the Falcons, they just need to log into the AMS‑IX portal, scroll down to the IP configuration section, then click the "enable peering" ‑‑ "enable Falcon peering" button. Once you do this, you are going to be presented with a drop‑down menu from where you can choose to receive only valid prefixes, filtered by either the RPKI or the IRRdb info, or both, and if you fancy doing the filtering yourself, select "no prefix filtering," just tagging, and the Falcon will send you everything tagged with communities.
The Falcons have been up and running for the past two‑and‑a‑half months and, by now, we have 35 peers, and a total of roughly 1,600 prefixes. As you can see on the pie‑chart the RPKI adoption is quite low; less than 6% of the advertised prefixes have ROA entries and about 1% of them are invalid. On the IRRdb side, things are looking a bit better. Roughly, 70% of the prefixes are valid.
So, what do we want to accomplish with this? If you are a service provider and want to implement RPKI, you would need to do some or all of the following:
Install and run an RPKI validator instance; upgrade your equipment to a recent software version and rethink your routing policy configuration.
For example, if your router is running IS, if you want to get a solid implementation, you would need to upgrade to 15.2 or above. If you are running XR, you need 4.3.2 or above. And Junos works with version 12.2 or above.
So, why not letting us be your sherpa and carry the heavy stuff up the mountain while you concentrate on what you do best? Drive the network. You know, in a safe and responsible manner that is.
You may ask, why not just the back board the RPKI and IRRdb functionality, the additional features to the legacy route servers, instead of providing another set.
Okay, well, this pertains to our philosophy of maintaining our neutrality as an entity, at the same time we aim to avoid forcing the service to customers who potentially would consider it intrusive, other scope or even harmful to their operations.
Okay, I'm going to wrap up on the further development slide. We are thinking of implementing, in the near future, some more useful features for BGP traffic engineering, like per‑peer attribute manipulation using communities, BGP add path and DDoS attack mitigation and filtering.
Okay, closing, I want to emphasise that this is still a work in progress and any suggestions are much appreciated. Thank you all for listening. If you have any questions or comments...
(Applause)
AUDIENCE SPEAKER: I am Marco d'Itri from Seeweb. I have a comment, I believe that adopting a voluntary approach is a bad idea because if you accept validation and then you lose 25% of your routes, nobody, more or less nobody will accept these so other IXs are forcing validation on the route servers. I suggest you do the same because it's the only thing that can work.
CIPRIAN MARGINEAN: Okay. Thank you.
AUDIENCE SPEAKER: Rudiger Volk. Well a couple of questions. For the RPKI, are you using Trust Anchors for all the RIRs?
CIPRIAN MARGINEAN: Yes, yes.
RUDIGER VOLK: You signed the RPA?
CIPRIAN MARGINEAN: Sorry?
AUDIENCE SPEAKER: There is supposed to be one that is held as a secret.
CIPRIAN MARGINEAN: Okay, I'm not familiar with the specific implementation of that, but maybe we can get back to you, or [Aris] can add further information.
AUDIENCE SPEAKER: You are thinking about the ‑‑ we are in the process of doing that. I'm not sure if there is any considerable legal implication about that, but, so far, we haven't seen any.
RUDIGER VOLK: Well, okay, it's just liability.
SPEAKER: Right. So I don't think it's something that that's much problematic, so I think we are in the process of doing it.
REMCO: Thank you for your presentation. I consider it a very positive development in Amsterdam region that this service has become available. I encourage the room, if you peer with route servers, set up sessions with this one. This one is clearly better. However, this is one small remark that I have. As far as I know, the service as of this moment, is advertised as beta.
CIPRIAN MARGINEAN: Yes.
REMCO: I have heard from people their reluctance to set up with something that is labelled at beta and I would expect a little bit more uptake if AMS‑IX makes a decision to either commit to the Falcon platform and offer it just as a full fledged service like others, or ‑‑ so, can you comment on when you will remove the beta label?
CIPRIAN MARGINEAN: Not really... we don't have like specific plans for that at the moment. But I'm sure we're going to get back with that as soon as we make a decision.
CHAIR: I will close the mics, so you can give a comment.
AUDIENCE SPEAKER: Actually, if I may comment on that question. This is a little bit of a double‑edged sword there, because if you take away the beta name, then people would start peering, but then, of course, if you would have a massive uptake, then you probably would be forced to overcome situations that otherwise you would be dealing with slowly, and I'm not sure if we're willing to take that risk. We have discussed it internally and we think we'll probably do another call for people to participate, and if we don't see people do that, then we'll go ahead and put it in production.
AUDIENCE SPEAKER: Peter Hessler with OpenBSD. For your invalid ROAs that you are seeing, do you have any data about why they are invalid? Like, is it a valid key but it's outside the prefix line, or if it's an invalid key or if there is no key or any sort of data about that?
CIPRIAN MARGINEAN: Yeah, we can check that. But, from what I have seen, mostly they are more specific prefixes that are getting announced and don't have the ROA backing entries.
AUDIENCE SPEAKER: Thomas King, DE‑CIX. I have a question. You do the application validation at the route server and then you transform the results into BGP communities, I assume. And then you forward this message to the other peers out there?
CIPRIAN MARGINEAN: Yes.
AUDIENCE SPEAKER: Actually, then I have a question to all other people in here in the room, because DE‑CIX is also working on more or less the same thing you do with RPKI, and I would like to know if it makes sense that IXPs standardise the communities that are used for the RPKI information forwarding so that all the BGP communities that are using IXPs are the same wherever you are. Is that of interest for you guys?
SPEAKER: If you know the routes is invalid, why forward it then?
RUEDIGER VOLK: Actually, there is an unwanted RFC that already specifies communities for the three classifications.
THOMAS KING: Okay. Can you forward me this RFC?
RUDIGER VOLK: Okay, it's a draft.
THOMAS KING: Please forward it to me.
CHAIR: Final comment, Gert.
GERT DÖRING: I think you should not forward invalid, because it's invalid. For unknown, tag it with a community, perfectly fine, but invalid is invalid. Let the people that send it to you know that they are sending invalid objects, that would be very useful. But do not forward to third parties because it's an invalid prefix. Do not forward.
CIPRIAN MARGINEAN: We give the customer ‑‑ our customers the options to choose how the route server is behaving, so you, as a peer, connecting to the route server, you can choose between either having the route server filtering everything for you based on those criteria, RPKI or IRRdb, or just forward everything to you and then you can make the decision of filtering or whatever you want to do with the prefixes.
GERT DÖRING: So that's a receiver side ‑‑
CIPRIAN MARGINEAN: Yes.
GERT DÖRING: That wasn't fully clear to me, I had a feeling it was on sender‑side setting.
CIPRIAN MARGINEAN: Sorry for that.
CHAIR: I have to close the discussion. Very good. Please take it to the breaks or any other BoF. Thank you.
Our final lightning talk will be by Marco Canini on Endeavour and he is whetting our appetite for the birds of a feather on Thursday.
MARCO CANINI: I work as a professor at the university. I realise I am the only one standing between you and the next break and the end of the day, so I will try to really be having not just a lightning talk but a lightweight talk, and short.
Right. I am here on actually behalf of a fairly large number of partners, they are listed here, and I want to tell you about our efforts towords to a flexible software‑defined network ecosystem. So the project which is is called Endeavour. You see the website here. I encourage you to go there after the talk.
Our goal, in a nutshell, is to bring SDN to the inter‑domain settings. Why do we want to do this? Fundamentally, we want to try addressing, from a research perspective, limitations at the inter‑domain level, things that essentially have prevented certain innovation from happening over the past few decades. Now, one of the problems that we are having a struggle with at the inter‑domain level, we can say that inter‑domain is fairly static. We have contracts that are lengthy to set up, all these commercial agreements, they operate over long time frames, and, in contrast, we have a world out there that knows things like infrastructure as a service, platform as a service, anything as a service, which delivers services at much faster rapidity.
We can see that inter‑domain routing is also myopic. We don't really have global visibility into what's going on everywhere in the network and this affects our ability to choose the best paths and most often we end up having some optimal paths.
Furthermore, inter‑domain is also constrained specifically. You can imagine all the occasions in which the only discriminator that you have is essentially the destination decision that you can make. However, you would like to decide on other things rather than destinations. Well, please don't tell me that the best solution that we have is to yet put another type of middle boxes in the network.
And I'm not even going to enter security, because I don't want to turn this into a much larger discussion. But that's also a problem.
So, the question that we ask is, what can SDN do for us at the inter‑domain level? The context in which we explore this question is that of the internet exchange points. The reason we think is strategically sound and has a great potential. You can think, for instance, that the fact that even one single deployment inside one internet exchange points can provide benefits for potentially hundreds of networks without the need for any type of uplift deployment or overall major networks. So this is the context in which our research takes place. However, we don't want this to be just a revolutionary type of proposal. We want to start with something that is rather evolutionary. And for our starting point, therefore, is to attempt to enhance what we already have and what we recognise as being matured over time and to, you know, to a good extent, already works for the larger majority of times.
Therefore, we would like to basically focus on IXPs and imagine how we can use SDN to simplify network management or how to bring around better safety and security for the networks or how to leverage the key position of an IXP to introduce more fine‑grained monitoring in the capability of gaining better understanding on the network behaviour at large.
However, we don't want to stop at just announcing what we have. We want to be brave. Some of us, perhaps most of us, are academic so we have the desire to also look at the longer term. And we feel that the SDN, within the context of an IXP, can bring about novel services for IXP members and, in fact, enlarge the quality and the improvement of the Internet.
Here, I would just refer to some simple concepts that we have in mind and are working with. For instance, enabling a better type of traffic engineering allowing IXP members to decide how the traffic should enter the ports, or deciding how the traffic should leave at different paths, depending on congestion levels that are observed. Or perhaps how to do better type of inbound filtering managing broadcast and Arp traffic. From the point of view of security, having advanced ways of blackholing based on arbitrary fields of the packet address rather than just having to dump the entire traffic words to a sub‑net.
Now, we're working towards a concrete set of used cases and we have many more than this, I will just give you a gist of two to make the discussion a little bit more concrete.
So the first one we have is this destination congestion notification where we imagine that it might be desirable to overcome some of the limitations that BGP does not carry information about whether a certain port is congested or not. We feel that a solution might be to have some binary congestion, state, say, something that notifies whether the egress port in IXP has exceeded a certain threshold and push the statistics around without however disclosing any more sensitive information than that. Providing this information could be enabling the IXP members to then decide whether they still want to use the path or not.
As another use case, consider that of essentially deciding on which particular capacity you want to sign up on a contract when connecting to IXP? Should it be a 1 gig, 10 gig and so on? We think that it might be valuable to provide for capacity as a service where IXP members may have the ability to, in an elastic and scaleable fashion, provision more extra bandwidth on demand, but without necessarily needing to sign up on a long term basis, but say for just a few days or weeks at the time that is needed.
We also have several more open questions of course. And we basically just want to tease out that we are organising a BoF session on Thursday at 6 p.m. where we hope to receive your feedback, specifically, which, you know, use cases you feel would be most useful for you, which ones wouldn't work, as well as help us figure out what represents the red lines in IXP.
In addition to this, we come here to ask also for your help. We have set up a short survey, it's not going to take very much time of yours, but will help us towards our goal in understanding what current limitations you are facing when setting up peering at IXPs and interconnecting, as well as what are the services you would expect from IXPs in the next years. We hope very much to receive your feedback on this and we ensure that this these results will be very helpful for our efforts. We will use them in a confidential manner and also, if you prefer to do so, you can leave all this information in an anonymous fashion.
So, with this, I have concluded this very light talk. I do have some time to take any questions, or if you want to go a little bit more into detail in the discussion, then please come on Thursday. Thank you.
(Applause)
CHAIR: Thank you very much. Questions...
No questions. Thank you again.
Well, before closing the session, I have two announcements. First of all, in this, the main room, there is a Plenary session, I just want to remember that RIS is the RIPE academic initiative, so there will be some interesting presentations. In the side room, there will be a BoF session called at this spoof BoF, please attend anything you like.
Another announcement is that today we will have a party at [Marble Coopen] Lounge. The buses will depart from the main entrance of this hotel at 7:45 p.m. till 8:55, and come back to the hotel at 9 p.m. That's all. Thank you very much for attending.
(Applause)
