 If you are using OSPF, OSPF implements shortest pass routing. So if a router is using OSPF, you know that even in an input, what will be the output? You know this in the end. And also, the implementation are widely available. Again, if you think, for instance, a normal network, most of the bugs speak OSPF already. So if you can use OSPF as an API, it means that you can already program all the network today. So how does it work? Well, again, let's abstract a bit. Routing protocol takes as input routing messages, execute a function, and then outputs forwarding pass. This is really a function, actually. So you take inputs and you have a run. But we know it's a function. We know that this is the extra. We know that this is the BGP decision process that is running. This is not. What is known as well is the forwarding pass. We know this by traffic engineering or capacity plan. So we have a function, and we know the output. So what do we want to do? We want to find the input that, shown to the router, will give me the appropriate output. If I can do that, I have an API that I can use today. And this will be the goal of the project. The type of input that we need to compute will depend on the protocol. So if we are using an IGP, link state IGP, a router takes as input the entire network typology. So we have to compute the entire network typology. It's the input that the router takes. If we are using BGP, BGP is a pass vector protocol. So it takes as input a bunch of routes that it receives from its neighbors. And then it computes a decision process. So we see these two cases in the rest of the book. So let's start with S-gen control IGP. So an interesting use case for S-gen is traffic engineering. You have probably all heard the Google kids why they moved to S-gen once because traffic engineering was a problem for them, and S-gen served that problem. So if we look today, there are basically three ways to do traffic engineering. You can either use the current IGP, so our SPN, for instance. And here you do traffic engineering by just tweaking the weights so that you will have an influence on the shortest pass and the pass that are taken by all the flows in the network. You can use another protocol, MPLS, or RZPT, in this case. And here you have a protocol which includes a pass signal so that you can give a pass and then the router will signal that pass through the network. This will enable you to forward along any pass signal. Or you can use SDF. And here you just go to pass, you give that to the controller, and then the controller does the magic and push the forward eventually signal. I would like to compare these three techniques along three axes, signaling, expressiveness, and device support. So here is the classification. In terms of signaling, there is really only MPLS and RZPT that does signaling. So this is the only protocol that requires the router to synchronize. And here they will synchronize on their labor they need to use in order to forward along these pass signals. This is the reason why, one of the reason why Google moved the weight actually from RZPT. They were using that, and now they are using SDF. And the reason why was when there is a failure, the routers need to re-synchronize themselves. And they are in competition to do that. And that takes a long time, or could take a long time, in the case of Google conversion. They say, we can know whenever there is a failure, we can recompute that centrally and then just push the reserve in one go. So this is why they are moved to SDF. In terms of expressiveness, now, when clearly here, IGP is using. On an IGP, if you are using shortest pass routing, you can only do shortest pass routing. You cannot forward on the pass, it is not the shortest pass. We see several examples of that. In terms of device support, IGP is excellent. Really, if you take any Cisco box, even the cracker, it will support OSPF, right away. For NGLS, it's good. You still require NGLS support in the data plane, but it's widely available. For SDN, you require a new hardware, or at least you require Cisco to open up its interface to the fib and support OpenFlow. And I'm not seeing this coming tomorrow. So what if we have an SDN control IGP? First of all, what is an SDN control IGP? Well, it's like in an SDN network. You have a controller. But instead of using OpenFlow to program an entry, it will compute a virtual topology. So it will take the current existing IGP topology, and it will augment it with virtual nodes, virtual links, and virtual destination. And it will do that, such that when it presents that topology to the router, the router will be tricked in computing the pass that you want. So it's kind of reverting the user processing. So you start with forwarding pass. So it's a declarative way of managing the network, as in an SDN. And then the SDN control will automatically find this topology for you. So what does it give you? Well, it gives you kind of the best of all the three techniques. So you have no signaling. You have no high expressiveness. And you have an excellent device control. So what do I mean by high expressiveness? Well, now you can steal traffic on non-shortest pass, like MPLS, like SDN. You can forward along multiple pass on a per destination basis. And you can also provision backup pass. So you can say, I want to forward along this pass. And if this pass fails, I want to forward along that pass. So you can do kind of capacity planning quickly. And you do that in a centralized manner, just as SDN, on an existing network. So let's consider a simple example. So I have four routers here, A, B, C, and D, and I have a bunch of weights along the list. So I have a source here and two destination here. And with this weights, what is going on is that all the traffic is going along the direct link CD. So now what can go wrong with this network? I have a lot of traffic between these forms. And so I will start to see congestion on the link between C. So if you are an operator, what you want to do, what you will say, basically I want one of the flow to go up and I want the other flow to go straight to the destination. You cannot do that with an IGP. It's impossible to do. And the intuition to understand that is that in an IGP, you compute the shortest pass towards a router. And then you have all the destination behind this router. So here what you want to do is to have two different shortest paths towards the same router. And you cannot do that in an IGP. It's impossible. So what if you have this ability to virtualize a topology and to present a virtual topology to the router? Well, then you can do it. So this is the virtual topology that encodes the recall. So you have a virtual node, V1, that you will connect to A and C. And then you will have as weight 1 here and 10 here. So what is going on? Now C has a new way to reach the orange destination. It's via V1. So C will prefer that pass because it's shorter. But the stuff is that that node, V1, does not really exist. It's a virtual node. So when it will send traffic to V1, actually it sends traffic to A. And once you are at A, A will just follow the initial shortest pass and will reach the destination. So you implement by using this, you implement the requirements of the operation. So let's look at a slightly more interesting example. So you have four routers now, five routers, a square and a triangle. So here, what is going on is that you have two flows from these two sources in the bottom of the slide that are reaching the two destination nodes. And these are the link capacities of the network. So you see that in this network, the two flows are limited to 100 megabits per second. So as you probably know, traffic in the network is bursty. So it's likely that you will have a burst on the orange flow and a burst on the red flow. And this is likely not to happen at the same time. So what is a smart move to do if you are an operator? It's basically to balance the flow on the two pass that you have. Because what will happen then is that if there is only one flow, you can get 200 megabits per second. And if there is the two flow at the same time, then they will just share the bandwidth. And then you will have 100 megabits per second. So in the best case, you double the bandwidth. And the worst case, you have the same bandwidth as today. So there is really only gate in this case. So you would have to do this for the orange flow and that for the red flow. The problem, again, if you do that, is that you basically create a loop between D and E. Because as I told you, when you computer shows the space in OSPF, you computer shows the space towards a node. So here D and E computer shows the space towards A. And what you are asking the network to do is to have a pass from D to reach A that goes via E. And a pass from E to reach A that goes via D. So you basically want a loop, which is impossible to do in an IGP. So what about using an asian control IGP again? Well, if you do that, this is the real-threat technology that you can present to the router to trick them. So I'm adding two nodes now, V1 and V2. And V1 is connected to the orange destination and V2 to the red destination. Let's see if I get it right. So E, to reach the red destination, it has two ways to reach the destination. 10, 5, so it's 15, or 5, 10, or 5. So it's 25. So 15 is less than 25. So I'm using that pass, which is a pass I'm using here. So it's up here for the red flow. What about for the orange flow? What about for the orange flow? Again, two ways. 10, 5, 5 is 20 here. Or here, 5, 10, 5, which is 20 as well. So indeed, that guy, for the orange flow, will use this pass and that pass at the same time. So indeed, I'm implementing the pass that I want using this simple trim. So when you say trick the router, you're actually trying to trick all the routers, right? Yes, except that I'm configuring the way so that I'm only tricking these two guys. So these two guys will not change their shortest pass, I think. They will send to this guy. And actually, that guy does not exist. But it's a red. Well, I mean, all the routers will become red of all V1, V2, and everything. We do not change OSPF. So in OSPF, you are aware of the entire network topology, including the VFRs, and the VFRs. That is correct. So it's not only about these two simple examples. Actually, we have a theorem that shows you that you can actually trick the router in using any set of non-contradictory pass. Obviously, your question would be, what is a contradictory pass? There are two ways to create a contradictory pass. If it contains a loop, so this will not work in our scheme. So if you want to traffic from S1 to D to go via A, then B, then A, then this will not work. Because you cannot create a loop in the router. Or when the pass are inconsistent. So for instance here, between S1 and D, I want to go via A and B. And between S2 and D, I want to go via B and A. So if I look at each pass, there is no loop. If I combine them together, I create a loop. It was at A, B, B, A. So again, if you have this, you cannot do that with an IGP. It's true you can do that with SDN, for instance. But we think it's not a reasonable requirement anyway. So if you really want to do that, then SDN control IGP is not your tool. But for most of the people out there, it's already good enough if they can create non-contradictory pass. So most of these protocols, do they do just destination-based forwarding? Yes, I do destination-based forwarding. Yeah, that is correct. So you're right that in an ISP, for instance, everything is IP, so it's OK. If you are in a campus network, or where you want to do some crazy stuff based, for instance, on the destination floor, then this technique will not work. So it's really on destination-based IP. And you can handle the two protocols. Do you want to save from that? One knows and another knows. You don't have to do some access control. You don't have to do that. So I'm looking at the routing protocols, so they are free. I'm not doing anything up there. But there are ways to provision routing apps. But it's not outside of the Routemap. I mean, talk about how, in practice, you inject that virtual node. Yes, I was trying that. So you're going to get to that now? Yeah. So a lot of providers have the concept of loop-free alternatives for backup. So will that continue to work in this way? And actually, it will even improve the behavior. Because loop-free alternates. You are dependent on the topology. And in some topology, you have not 100% coverage. And actually, with the virtual topology, you can treat the router, again, believing that there is an alternate pass and use that pass. So you can get 100% coverage with this. So it's actually better, if you have this than if you want that, and improve the coverage. How are you exploiting the traffic across those two equal paths? So that's just a router that is doing this normal ECMP. So the router will just compute the hash and the five-stepper. And we send one flow on the left, one flow on the right. And hopefully, roughly, we get to 50%. But I'm not doing that. That's the router that is doing this. So no SPF router, when it has two or three equal scores, shortest pass, we just use them using the hash function. OK. So how does it work in practice? Well, in practice, we get the physical topology, a set of pass requirement. So you want the traffic between A and B to go by and B and C, for instance. Or you tell me that you want ECMP pass between X and Z. We feed that to an optimizer. So why an optimizer? Well, because the extra algorithm scales in terms of the number of loads and links. So you want to reduce that. You want to reduce the size of the virtual topology. And this is what the optimizer is. And then at the end of the day, we get the virtual topology. And this is what we present to the router. So now to go back to your question, what do you need to do that in practice? Well, you need basically three things. You need to be able to listen to the IGP traffic. So this is easy because you can just establish an IGP adjacency and just listen to that. Most of the network are doing this just for monitoring. You need to be able to inject a fake packet. So how do you do that? You establish an adjacency. And then you just need a daemon or whatever can create this fake packet. So you just need, for instance, you can use SCAPI, which is a Python library that enables you to create whatever packet you want. And then you just create an IGP packet that represents the effect of a router. And then you just send that to one router. And since the SPF works by flooding everything to the network, you just need to inject the packet at one point, and then everything will be flooded to the internet. So you do not need to, like, in open field, do some entries anywhere. But in practice, and I don't know how much, you went to really emulate a protocol, these are either point-to-point links in which case I wonder how you inject it, or they're multi-access links like an ethernet. And you need to add in extra adjacency. But you need to circumvent the different games of designated router who aggregates the LSTs. So let's say I have a controller, I have a Cisco box. So there is a management interface. So I just put a gaver between the two. And I establish an IGP at the top of the extra interface. So I'm not in the IGP, I'm just external to the IGP, and then I'm injecting my packets from there. So I do not need to be in the network to do that. I just need an injection point. So your injection is really never seen on this network, is actually directly into the box? Yes. Yes. So you've used a pretty spacial voice? Yeah. I think it's minute and liquid. Yes. How hard is it to, like, in a real network and a huge network, how hard is it to compute the liquids appropriately as you get the desired practice? Yeah, so we are using an integral line-up program. So in the worst case, it might be exponential to compute the liquids. In practice, though, it's not exponential. But I cannot give you a bound, if you want, right now on the computation. But people have looked at these problem computing link weights. And yeah, it's in the hard to compute. But in practice, it works well. I mean, how much human is it? No, you're thinking. But also, this is the optimization. So actually what you can do is it's very easy to compute a non-optimized class, a non-optimized topology. So this is polynomial. So I can, given a bunch of requirements, I can compute non-optimized topology. And then run on the big server every now and then the optimization process. So I can react quickly and then just optimize once in a while. So I'm not computing the weights. You give me the pass, and I'm computing with topology. There is a trick. You need to map data nodes on physically. So this is something that we need to solve. And the idea here is that when the router is tricked in using a virtual pass, we don't want the router to actually send traffic on the virtual topology. We want traffic to be sent on the physical topology. So we need a way to map the virtual node on the physical input. And here are basically two solutions right now. Either we have a simple protocol change, but this is annoying because we need to change the SPI. So we need to go to the idea or more. So this is annoying. Or we can use a bunch of SDN-enabled devices. And here the idea is that if you have a bunch of switch in your network, you can establish SPF adjacency on top of them, send the traffic to the SDN box, and then bounce back the traffic after. And what is cool, actually, is that if you give me a bunch of pass requirements, I can compute where you should boost the SDN box and how you should connect them. So we can minimize the amount of SDN box that you require. Any more questions before I start the YouTube part? Yes. Is there, did you find that for many different configurations, like the SDN boxes that you've been rotating, and what it says, or every different configuration you ended? We haven't done the evaluation about that yet, so I cannot answer this question with accurate data. But I think, so top of my head, I would say that most of the time, you will want a fine-grained control, maybe, for instance, in the core of the network, and not at the edge. So what the optimization would be is, basically, you deploy more SDN switch there, and not at the edge of the network. Because this is where you have the most traffic, because it's aggregated there. So this is, for instance, I guess, one of the most result that we would see for a few days. So those are all these practice data saving? Yes, the rest would be the same. Depending on the possible comment, if you want to do something crazy at the edge, then we need something crazy, but we need a single SDN at the edge. Are we implementing it? We are implementing it. We have the Integral INA program, and we are evaluating it right now. But the part in which we inject the LSA, we are working on that, but this, we don't have to. So there's a really nice parallel here to the Panopticon work from, as in Berlin, where the idea is to present a logical SDN abstraction on top of physical, actually, layer two, doing purveillance spanning trees. This is like the layer three version. Exactly. And so I'm wondering, what are the requirements for where you place switches? With Panopticon, it's that every port, every input port, must eventually make its way to an SDN switch so that you can get the SDN management control. This little difference is about paths. So what are the restrictions on the SDN switches that need to be added if you're going that route to deploy this? Yeah, so I would rather you go the first route, because then you do not need an SDN-enabled switch. If I can change the protocol, it's really a simple change, then I do not need any open flow switch to do this. If you cannot change the USB protocol, and we have to deploy an open flow switch, then I will still require, as in Panopticon, traffic to eat the switch if I want to do something like that. So I will still require between two points to do that. So you can create deflection, but then it's become nasty, because what you want then is attract the traffic, and then you know that when the traffic is going there, it will eat another router that they like to attract traffic elsewhere. But then it becomes really nasty. I would not recommend it to do this. It may be kind of a nasty question, but if you're going to change something in OSPF, why not just incorporate something that allows you to change the sort of table energy? So what's the difficulty in deploying that on a bunch of existing routers? You're changing the OSPF versus something that actually allows you to do this? Well, actually, I wanted to build on that. So if you can change it, then you might as well. The other is OSPF as is today, and true also, ISS and what others, have the notion of building multiple topologies that you could then, if you wanted to, in every node map different subsets of flow to use topology blue versus red versus yellow. And for the finalities that you've listed, either to force the non-shortest path, you can liquidate the path costs in order to achieve that for the yellow topology. So first answer to your question, you need to configure the multiple topologies. You need to go through the pain of configuring that. So you do not have an open API to deploy the multiple topologies. And if you have a Cisco, Juniper, and Alcatel box, it's likely that these guys will not agree on how to multiple IGB topologies are a thing. You have to go through vendors by vendors. It's not something that is widely available across multiple vendors. So here it's vanilla OSPF, so I did this video trick. And I can use that on any vendor. So this might be my answer for this point, committed multiple topologies. I don't want to use configuration language. I want to use an SDN controller that is programming in that point. Now for your point that if I need to change OSPF, why don't I change the router so that it's also open for instance? I think there is an interesting design point here is that I'm basically computing, I've only centralized the management play. So this controller is computing this topology. And then it gives a reason to the router. And the router are doing all the heavy work. So they will compute the passcode that will deal with failures for me. They will deal with this crazy race condition distributed system or things done by the router. And my controller is extremely simple. I don't need distributed system. And so I think it's interesting this design space. So this is why we went to that. And also, for instance, let's say that you want to change. So you have a network, and you have a bunch of routers here that are connected to E. And E is basically the exit point. And now you would like to change all these guys and point them to another exit point. So if you are open flow, you need to go and first change all the entries in these guys. And maybe you have hundreds of routers and you need to change all these entries. Here what I can do is that I will announce a destination from the exit point with a lower weight. And automatically all the routers will move to that. So it's also interesting from the performance point of view, because I control the distributed system. So I've already distributed system. I'm just controlling it in a different way. This is why we think it's still interesting. Do you know what percentage of ISPs continue to use link weights as a means to do graphic engineering as opposed to ampillus T? Not a lot of them are. And the reason why is that. Genotes ampillus T. Yeah. And why? Because this won't work with ampillus T. This is a replacement. This is completely different. Yes. But there is a lot of problems. This is why people are moving away. Google has moved away from RZP. The problem is the synchronization of what there is a player. They're the only ones. They are not the only ones who are experiencing problems. Who are complaining about what there is a VP. I agree with that. Yes. So what is the way you program your friends? What kind of questions do you have? How much time do you have? So let's take it offline. Because I have still a big lot of stuff to say. But basically, just to give a short answer is that what we minimize is the amount of virtual nodes or virtual links that are across. So this is the objective function. And how we work is that we basically use Dijkstra on the graph in order to compute the constraint that the IGP maintains. And then we add constraint. So for instance, if we know that the current shortest pass between two nodes is this one. So I know that I have, for instance, so I know that the shortest pass, that this pass is shorter than all the other ones in the network. So if I want to treat that, I need to add a new node that would be shorter for these two guys. So I have constraint that is less than that. So you're pushing for every pass? No. We don't have constraint for every pass. Because we can miss the pass before. And then we only have a constraint to be shorter than the current shortest pass. OK, good. BGP now. I was not expecting that any question on the IGP part. So let's hope we finish on that. I didn't know whether you guys knew BGP or not. So I have BGP in three slides. BGP is the glue that holds the internet together. Just remember that, and then you'll find. So BGP is a protocol that will run between different networks. And this network will use BGP in order to exchange reachability information. So there are two flavors of BGP. The first one is EBG. EBGP runs really between different autonomous systems. And this is where, for instance, ES10 with ES40 that is able to reach a destination. And then you have IBGP sessions. And IBGP sessions are used within a network to distribute the routes that have been learned externally. So if you have routes that are coming here, these routers will use IBGP to propagate the route through the network and then EBGP to announce the route to the other network. So unlike the IGP, which was kind of new to use an IGP to do SDN, BGP has been used before and is actually used right now to be an SDN as API. So here are three examples of SDN enabled BGP. So route control platform is SDI-2005. It's kind of one of the paper actually behind the SDN, as we know it. You have BGP route injection. And this is using another variant of BGP which enables you to provide route maps, the router as well. And most recently, I think it's Microsoft, who proposes to use BGP as the only SDN control for route scale data center. And they are not the only one using BGP there. So what is common to all these initiatives? Well, they are all using IBGP. And EBGP is actually pretty broken as well. And people are experiencing a problem in maintaining their clearance. So EBGP, again, is between different networks. So you have these policies that you need to make. So why is EBGP complex? Why it's inflexible? You are tied to the BGP decision process. So our BGP is ranking drops. And you are also limited to destination base forwarding for the comeback to PMS score. It's non-deterministic, especially for inbound traffic engineering. So if I want to receive traffic on the left, I need to trick your decision in sending me the traffic on the left, that maybe you want to send the traffic on the right, because it's less expensive for you. And so we have a tussle here. And usually, you will win, because you are in charge of where you send the traffic. And my objective will not win. And BGP is also geographically limited. So you can only do something in BGP if you have an EBGP session, otherwise you're going to win. So what do we do? Well, we combine BGP with SDN-enabled device. And we do that at internet exchange point. So an internet exchange point is basically these points in the internet where people connect together and exchange data. So just remember that. So what we do is we go there and we deploy as we end there. Why we do that? Because these points are really highly concentrated. So there are, for instance, 600 participants that are using BGP to peer in Amsterdam, which is the largest exchange point in the world. And there is an insane amount of traffic going on there. More than 2,000 gigabits per second is crossing Amsterdam at big time. So if we can have a single deployment, we can have a huge impact. But obviously, because of that, we need to do everything with scalability in mind. Because we need to support an insane amount of traffic and insane amount of process. So IXP 101, how does it work? Well, an IXP is nothing more than a large layer 2 domain, a switch. So you have a switch here. And participants come and bring their huge router. And then they get an IP address. Everyone is in the same sednet. And they just use that IP address to create EBGP session. And then they just exchange routes over that platform. If you are on Facebook, and you want to peer with as many people as possible, because you want to reduce the cost of your transit. And you have 600 experience to maintain. Well, that's basically a full-time job just to do that. So what IXP does is it gives you the ability to use a route server. And basically, a route server is a multiplexer. So Facebook will announce 10 slash 8 to the route server. And then the route server will propagate that update to everyone. So it's a way to alleviate the need to configure all these sessions. And people are using that a lot. And the traffic will flow directly from one router to another. So this is really important. The IXP does not want to be involved in the whole process. So whether we change here, when two things, we change the data plane, because we want to deploy SDN over there, and we change the contract plane. Here, basically, we want an SDN controller since we have an SDN switch. And in our case, the SDN controller will also be a route server. So if you give 600 participants an open flow API, and you ask them, go while you can push rules in that switch and do something, that will never work. So that will fail directly. The traffic will never do what you want. The traffic will just funny. It's probable that even the traffic will not reach the destination network. So instead of giving the participants direct access to the open flow API of the switch, we ask them to write their policies using a high-level language. In this case, we use Paratik, which belongs to the friendly family of languages. And Paratik is a high-level network program. There is a Triton program. So what does a Paratik policy looks like? Well, it's actually pretty close to an actual open flow policy. You match an apartment, and the apartment is basically the 12-bit, and you can do conjection, disjunction. And then you do some actions on the packet that you have selected in the first place, and drop forward and we run. So this is just a basic step. So everyone will use Paratik to write their policies. Everyone will do that independently. There is no exchange of the policy of this thing. And then everyone gives that to the SDN controller. And now, the SDN controller business is all to compile these down to actual open flow rules. And you need to do that, ensuring isolation, resolving any policy conflict that there might be, and also ensuring scalability. But let's look at how we do that. So how do we ensure isolation? Well, in order to ensure isolation, we use a virtual interpreter. So every participant will have a virtual switch. Google will have a virtual switch. Facebook will have a virtual switch. Google and Facebook can only push rule in their virtual switch. They're not allowed to push rules in the other switch. It means that they can only have an impact on the traffic that they send to the switch, or to the traffic that is received by the switch. But otherwise, they have no impact on the platform. And the switches are connected together only if there is a peering relationship between them. So if Google and Facebook have a peering relationship, then the two switches will be connected together. Otherwise, they won't be connected together. OK, how do we resolve policy conflict? So let's say that Google and Facebook peer together. And Google has an inbound policy for Facebook traffic. And Facebook has an outbound policy for Facebook traffic. So here, we have a policy conflict, because we have these two participants that want to push a policy that will match the same traffic. So we need to resolve that conflict. So how do we do that? Well, this is the advantage of using a high-level language, is that we have this composition operator. And the composition operator enables to take different policies, and then to combine them. There are two types of composition operator, sequential. I do policy one as a result, and then I do policy two as a result. And parallel composition, which I'm doing P1 and P2. And I'm doing them at the same time. So these are the two composition operators. And here, we do a sequential composition. So we take an inbound policy, and then we compose that with these policies. And we do that in another. And we do that in another that respects distance range. And finally, we need to ensure scalability. So we only want to push the minimum amount of rule in the data bin. So you must know that today in BGP, you have half a million rub. So if you have half a million rub, and hundreds of participants, you can end up with tens of millions of flows. And this will never work in an SDN switch or in any equipment. So we need to do something there. The load is too hard. So let's take a look at this architecture. So we have an SDN switch here. And then we have an edge router. And edge router, Cisco, has been optimizing basically the router for like 25 years. So an edge router is extremely good at doing IP prefixes. So we have something that is very good at doing IP prefixes. And we have something that is very bad at doing IP prefixes. What about using the two together? So what we would like to do is using the edge router to basically do interesting stuff once. And what we do is that we consider, actually, the fabric of the XP as being composed of two tables. The first table would be in the edge router, and the second table would be in the SDN switch. And what we want is the edge router to actually match on the destination prefix a set of tag. And then we want to match on the tag in the SDN switch. So it's really similar to MPLS. If you think about it, you have traffic that arrives here. That router put a label based on whatever you want here, the destination IP. And then you only match on that tag here. And the idea is that there will be way more prefixes than that. So this is why it is interesting to do that. The problem is that we do not control that guy. That guy is, for instance, Facebook router. And we have no way to control Facebook router. I don't want to control Facebook router. So we want, basically, to treat that router again. It's like the IGP want to treat the router in doing something interesting for us. So we need a provision interface. And we need something that can act as a tag. And it turns out that we have actually everything that we need. So BGP is the provisioning interface. And the layer 2 address of the BGP next up would be the label. So what does it work? So you are a BGP router. I'm sending you a route for Google. And you pick that route as best. So what do you do? You put that route in your feed. And you will direct the traffic for Google towards what? Towards the BGP next up I'm giving you. And actually, you will reserve that next up to a layer 2 address. So I'm giving you the next up. And you are directing the traffic to the next up that I'm giving you. So if I can have an impact on the next up that I'm giving you, I can have an impact on the label that you are sending on the packet. And boom, I have my provisioning interface. And I have my data. So we can tweak the IP and the layer 2 next up because we have this route server. It's receiving all these routes. And then we'll text them. So we are right in the middle of the action here. And we can actually do that. So let's look at a simple example. You have B. There is a provider of A and C. And B, A and C are all connected to the XB. Everyone is there. And these policies is basically to match half of the prefix tree and send it to B1 here. And the remaining half and send it to B2. So this is two lines, a policy that makes two lines. If you have to do that with BGP, you may have to write route maps that will match on a perfect basis. And that will be an insane configuration, really hard. And it will be non-deterministic. So you are not sure that all the traffic will actually do that. So how do we do that? Well, we take the policy. We split it into match, forward. We take the distinct forwarding action. And we assign a next stop for each of them. So we have for forward B1, we assign next stop 1, 1, for forward B2, next stop 2, max. Then ESDXController will push that in the data plane. So it will push two routes, match destination Mach 1, forward B1, mass destination Mach 2, forward B2. And that's it in the data plane. There is nothing more going on in the data plane. So now what I want is I want A and C when they send traffic to match either one of these routes. And we do that with BGP. So now we take the match part here. And when B announced a route, the ESDXController will rewrite the next stop. So for all the routes for which the first bit is 0, it will rewrite the next stop to next stop 1. For all the routes for which the first bit is 1, it will rewrite the next stop 2. If A and C picks these routes as best, they will reserve that, they will issue an RFP request that will be catched by ESDXController. And that will give Mach 1 and Mach 2. And boom, I've done a policy that matches half a million routes with only two routes in the data plane. And I've done that without any collaboration of A and C. So there are other stuff that you can do with ESDX. This is only one example. You can basically do security application, forwarding optimization application, tiering application, remote control application. So security, you can prevent participants' communication altogether. You can do leaderbox traffic tiering, for instance. So your Facebook, you see that you have something fishy going on for one IP, one port. You just match on that IP that port to send that to a leaderbox that happens to be connected to the XP. Inbound traffic engineering, I'll just give you the example. Fast conversion is cool. I don't have the time to explain it, but if you're interested, we can converge after a peering fader in less than one second using ESDX because we have these two tables. Application-specific peering, you can pair with Netflix only for the video track. And finally, remote control. So I can give access to remote participants to the ESDXController. So that, for instance, even if they are not physically connected, they can block the data set that is going to them. And they can block the data set that's going to one single server. In BGP, you are limited to have a policy that matches on the slash 24. So it's an entire subnet that you need to discard. Here, you can discard really one IP, one port if you want. And wide area of advancing, I would like quickly to describe this. So if you are on Netflix or Facebook, you do wide area of advancing using the DNS. And for instance, www.facebook.com. And then you will map this to one IP, depending on where the user goes. The problem is setting the TTL there. If you set the TTL to high, you will have slow recovery when there is a failure. If you set the TTL to low, then you will have your clients that will time out all the time. And then they will have to contact you all the time to get the IP. So this is clearly annoying because it's very hard to set the right value. And to make matter worse, low balancing is based not on the IP client, but based on the resolver. And so there are proposals to change that, I know. But it's still a problem today because the solution is not good. So what do you do with SDX? You are on Facebook again. You have a service, a chat service that can be reached on DC on two data centers, one and two. So what you do, you have IP preferences that are assigned to this data center. You take one of your address block and you dedicate that block to be a service prefix. And to the chat service, you only assign one single IP. So everything that is chat.facebook.com will be that IP. You put that in a DNS and you set an extremely high TTL value. You announce that prefix from the XP. So all the traffic to that prefix will go there because there is this is the only place you announce the prefix. And then you put that as a SDX policy. So you match on the service IP. And then you do your load balancing the way you want. So for instance, you want to send half of the traffic to that center one and the remaining half to that center two. You can do something way more clever than that. You can take into account the load in the center, for instance. Or you can go way beyond just splitting it two. You can split it in hundreds if you want. So with respect to using the DNS, it's fast because you have absolutely no DNS cache. I can change this policy every second if I want. And I will move automatically the traffic. Do that with the DNS is way harder. It's very flexible as well because you are not limited to the load balancing algorithm that is there in your DNS server. And it's efficient because you actually see the IPFs. So it's like good. So final slide on the conclusion. So what we think is that SDN control routing is actually interesting because it brings SDN to this network. So it facilitated the transition because you have one interface to rule them all. Now you can program your Cisco box and you can also program an open-core switch so you can use this. It simplified the control documentation, as I said earlier. Most of the artwork is done by the router. The router is matching on destination IP. The router is computing the pass in IGP. I'm only doing the management using SDN. And something that is important really in IGP and in network in general is to maintain, at least at the beginning, the operator's manager model. So we still have the same good old protocols that are running, and it's easier for them to troubleshoot. So this is kind of hard to understand for academia. But when we discuss with networkers, they tell us, yeah, OK, but if my SDN is going wide and I have a problem, how to debug it? Well, here, if there is a problem, it's still OSPF that is running, it's still BGP. I can still go on my router and my network engineer that is knowing BGP for 20 years can do show IP BGP and then have at least a feeling of what is going on. So the operator did not completely lose the grasp with the network. And that is important at the beginning at first. And then you can gradually increase the level of SDN to go completely SDN at the end of the day. But doing the shift one day will be hard. We think there is also an interesting point. And now I've finished, so thanks. Do you have anything to make it so? Is there going to be a ton of new entries in the BGP? People for the operator look at me like more, I don't quite understand which is all right, they make them, et cetera. So do you do anything so like to indicate these are like separate entries that are from our system so we can certainly do that. We can, for instance, use dedicated preferences to do this trick. And so the operator will know that these addresses are set by the SDN controller so that you will be able to know that. You can do that. I didn't have a chance to read your paper, but I read a couple of paragraphs. And there were two objectives. One was removing the loops or avoiding the loops, and two was security. And routing in SDN is relatively new to me, but I kind of was hoping you would think and talk about how hypervisors are being used or could be used for access control. And if there was a way for hypervisors to communicate with each other, they could sort of decide who talks to whom and they could avoid. The main thing that I'm saying is why did you not think about is strategy, an approach which eliminated network dependence? I'm not sure to what paper you refer to, to be honest, because nothing has been perfect. Some of the papers which are on your website. So maybe we can take the question back because it's a long question. Because some of the research that came out of Princeton talks about, but those are mostly VLAN or E. And that's the reason I'm saying is if there is an approach which limits dependency on network, it sort of avoids the problem, the risk, which people would have and they migrate to these kinds of architectures. But you can certainly virtualize everything. You just rely on the network to provide any to any connectivity, and you do SDN and DH. This is the zero approach, right? You can certainly do that if you want to have the network out of the way. If you really want this. So here it's more targeted that classical network operators still want to do something in the network. So it's less applicable to the center, for instance, where you can actually go SDN directly. But for an ISP, I think this makes sense. Or for an ISP, in this case. Any more questions? Yes. It sounds like you have a good handle in Tricking Unicast, rather. Tell us, Multicast. We did not look at Multicast yet, but if you are an interesting use case, you have to be interesting. So I know you're in the stages of implementing it, but do you have any initial performance numbers to share or performance insights? Which is the linear program? How long are they taking to run? Or what factors does its runtime depend on? I don't have numbers now. I should have numbers in SDN. And so I can. Yes, why? Yeah. I can't get it out of the way. But my take is that I think it would work very well. So I've used this kind of integrated linear programming my thesis on big network, pure one network. And what we saw is that it was taking only minutes to compute it. But as I say, you can go very fast by computing another maximum quality, and then optimize it in every test you go at your own. But actual numbers, that's it. So yes. Because the LPX is pretty cool, you really can try it and do it again. Yeah. Yeah. So again, we are. So this is very much research in progress. So again, two months I expect to have. I hope to have an implementation. And so what is cool with the SDX is that we have actually an XP deployment, which is in Atlanta. There is an XP that accepts the deployment. And we are not wearing a hearing over the platform. So hopefully we have live traffic, very well. And we are building the route server right now, who are using Quagga. And I'm in the process of implementing the virtual next-door application. Do you want details? Yes. So we have any views on, right now you can control the paths of that package with the page, but you didn't mention anything about QoS. And in the Google database, for example, one of the main things that we mentioned, so any ideas on how you can have them on top of it. Yeah, I don't see. So why I can't control the pass, because I'm using the routing protocols. And the routing protocols are just computing pass in Atlanta. For QoS, the problem is that I don't see any way to program the QoS in the router. We're not going through the CLI, at least not like this stuff on my head. So unfortunately there, I think you need to go through the usual way of configuring the router using, maybe, a software to do that, you just need it. More questions? Otherwise there is more in the story. All right, that's since the speaker is here.