 So now you will listen to Dima talking about Dragonflow. So Dima, the stage is yours. Thank you. Good morning, everyone. Today I'd like to talk about the Dragonflow project and our effort to make it into this open platform for network services. First about my stuff, as I was introduced, my name is Dima Kuznetsov. I work on the Dragonflow project. I'm the core developer there. I work for the cloud group for Huawei's Tel Aviv office. And I'd like to start by talking about software-defined networking. Now, I thought for a while how can I introduce software-defined networking because it's quite a broad concept, but basically I came to the definition of where we have a specific and unified interface for controlling and configuring the network fabric in the data center in the infrastructure. I think this definition would be quite suitable for this presentation. And what usually means is that we have a central component. This may be a single server or a cluster of servers that you can query or request changes to the network topology through this service. And it will take care of performing this configuration request. And it basically allows you to separate the network configuration problem from the actual forwarding and physical access problem where you want to configure a specific topology of the network and you don't have to bother with going to each of the switches and the routers and configuring them accordingly and you have this kind of software-defined network solution doing this for you. And what this allows us to do a lot of time is to do a thing called networking virtualization which can be sort of just like a regular virtualization where we have our physical machines and we have virtual machines and we can have several machines on a single physical host and we can have different kinds of machines on a single hypervisor. And networking virtualization allows us to do just about this. We have our data center or infrastructure and we may have a single physical network there connecting all the machines. But we may want to create an illusion for the VMs that we are in different networks, maybe different addresses. Maybe we have two VMs on different hosts but we want to create an illusion that they are connected one to another directly. And the SDN allows us to kind of create this illusion and show the VMs or the containers this virtual topology instead of the physical one where they can see how the data center is connected how the hosts are connected and how the switches and the routers are configured. Okay, and as we talked earlier, we have this network... We have this network service configuring network fabric, the routers, the switches and one popular way to do this is through an OpenFlow protocol. An OpenFlow protocol is an abstraction for configuring network appliances where each appliance is represented as a bridge or a switch or a router and it is basically a state machine for packets coming in. And the states are separated into tables where each table has a collection of flows and a packet coming in will land at some table and the switch will apply a specific flow to it and then if it decides it needs more processing it will apply another flow maybe from another table or the same one. Now each flow is composed of two things. A flow is a match which means what packet this flow should apply to. This can be on any from... OpenFlow allows you to do this with one through four levels. You can say I want all IPv4 packets or maybe I just want TCP packets targeted to port 80 or maybe even I want all the non-syn packets coming into the switch and when a packet is arrived to a specific table the switch will go through all of the flows in this table sorted by the priority and try to see the first one that applies to the packet. Now the second part of the flow are the instructions and the instructions basically say how the packet should be handled if the flow matches the packet. And they basically do I think three major things. One of them is modify the packet themselves. You can request a packet modification and say I want to replace the source MAC address of the packet. You can modify the state of the packet and say I want a next table to be table 20 or maybe I want to set some local register of the packet which is a state that the packet carries with itself through the switch and you can say that you want to drop a packet or output to a specific physical port of the switch. And this allows you basically to implement a lot of low-level networking functionality in the switches. Like you say, you can say that you want to receive a packet and see if it's on a specific network like by examining its VLAN 80 and then deciding what ports it can go out to and what ports it cannot. So this was quite a quick introduction to the overflow. We'll come back to it later. And I'd like to talk now about Dragonflow. Dragonflow is an open source project implementing a software-defined networking controller for OpenStack and Kubernetes at the moment. It is built on a few major principles. We wanted to try to make it as lightweight as possible and quite as simple. So if you have a small deployment, it won't be too much of a burden to run Dragonflow there but also we wanted to make it quite scalable. So if you have a huge deployment, you can still try to use Dragonflow and not be limited by its architecture. And additionally, we try to make everything pluggable. So we don't know how the deployment will look like in the end and you may have a single data center and a very converged infrastructure or maybe you have a distributed infrastructure. Maybe you have just a huge amount of nodes and you may want to use different features for different kinds of deployments. So we try to do a lot of things in a pluggable manner. And finally, we try to distribute a lot of stuff to the nodes meaning that many of the services we try to provide, we try to provide them in a distributed manner. For instance, one of them is DHCP. If you look at a traditional DHCP implementation in Neutron, you will see that it has a network node running a DNS mask answering all the DHCP requests from there. So if you have 10 machines and one network node, all of the DHCP requests will travel to the network node and if it is unavailable then none of the machines will be able to get DHCP. And we try to avoid these kind of points of failure by pushing the functionality towards the VM. So one example that we try to do is our DHCP server is handled by the controller itself. So if a packet of DHCP request comes out of the machine, then the controller will capture it, see it's a DHCP request packet and craft a specific reply packet inside it back. So there is no dependence on external server and the only reason that you won't get a DHCP request is that the machine is down. So the VM is down itself. So there's not much to do there. And some more trivia about Dragonflow. It is 100% upstream and open source projects. It was an official project in the OpenStack community. It was initiated by Iwawi a few years ago. It's in the OpenStack since the killer release and it is led entirely by community and not by a product. Okay, so here is a high level architecture overview of Dragonflow in an OpenStack deployment. We have three major components here. We have the Neutron server at the top in the middle in a nice orb there where we have our Dragonflow management code. In the center we have the Dragonflow distributed database. And on the side we have the computer running the virtual machines connected to the OBS bridge and Dragonflow controller controlling each local OBS bridge. And as I said earlier, Dragonflow can also be used in a Kubernetes environment. So here as well we have the control node at the top in the middle where we have the Kubernetes API and another service called OpenStack Career which is an OpenStack project for interfacing and allowing networking from Neutron or other providers towards containers. And inside Career we have our Dragonflow drivers that translate the requests from a career to Dragonflow. And those two are basically on the same orb but they don't have to run one next to another. They can be on different machines. The main point is that we have the Kubernetes API and then we have the career service subscribing to Kubernetes API events. So they don't have to run together but they act as a single unit for this purpose. And then again we have the Dragonflow database in the center and on the edges we have, now we have pods instead of VMs connecting to an OBS bridge instead of Linux bridges. And then we have our CNI and kublets running on the computer alongside with the Dragonflow controller controlling the OBS bridges. Now if we look back into a typical OpenStack Neutron deployment with Dragonflow, we'll see that on the lower level we have the Dragonflow part in the Neutron server and we have the Dragonflow part on the controller and they talk one to another through a distributed database and a published scribe interface. And one of the points of the applicability that I tried to talk about earlier is that we try to avoid being restricted to a single set of database and pops of mechanisms so we obstructed everything away through a driver layer. And there are really several drivers that we support and maintain our code for the database or ETCD and I think ZooKeeper and Cassandra. But what is common to all of those interfaces is that they are quite simple key value stores. So you can come up with your own driver if one of the database does not scale well enough for your deployment or does not answer specific requirements. So implementing a new driver is basically a matter of writing a few simple functions to store values from the database. And same with the PubSub mechanism, we use PubSub to facilitate faster updates between the management part and the database and the controller, excuse me. And again, we can use the distributed database mechanism here to implement the PubSub functionality or you can use any other kind of other database that you have deployed in your environment or you can use no broker solution at all, like zero amp here. The PubSub interface itself is also obstructed behind a driver so implementing a new mechanism should be quite simple. On the higher level of functionality we have the Dragonflow drivers and service plugins inside Neutron. Each one of those tiny little cubes at the top is a driver or a service plugin in Neutron that handles a specific segment of functionality. For instance, we have the L2 and the security groups handling a translation of incoming networks, ports and security group events and translating them into Dragonflow actions and state. And we have other plugins for handling L3 routers and service and service function chaining. Each of those cubes is a steved or entry point so it is dynamically loaded by Neutron so you don't have to write those stuff directly inside Neutron code you can just register it externally, install the plugin and set the configuration and it will be loaded. On the bottom we have the Dragonflow controller here connected to an OBS bridge that is connected to our VMs in the containers. Inside Dragonflow we also have those tiny cubes with names on them those are Dragonflow applications. Dragonflow controller itself is basically a mechanism for distributing events coming up from the Neutron server or any other kind of northbound API into the applications on the Dragonflow controllers. A major differentiation from the Neutron's open-view switch implementation is that we don't distribute flows and actions through RPC we basically push policy towards the controller so each of the controllers is the complete state that it requires to set the data path and modifies the data path according to the state that is required. For instance if such a method coming in from the server can be a new port is created and then the controller itself has to decide how the data path has to be modified to accommodate this port. As I said in the beginning of the talk one of the points that we try to address is to make Dragonflow a more of an environment or a platform so you can introduce your own network functionality because with the solution sort of time the data path is kind of a black box and you don't have much of a direct control over what happens there. You may be able to configure it through maybe to runtime or configuration but you don't have real control of what happens to the packets inside the data path and we try to actually enable this kind of change because no deployment is the same and you may have to tweak your data path to make stuff more fast or maybe more efficient in your data center. Now from the plugability standpoint as I said earlier in the Neutral Server a lot of the plugins and drivers are basically Stibler entry points and we didn't have to do a lot of there because we kind of got this for free from the way that Stibler works. By using configuration values you can enable or disable specific functionalities inside the Neutral Server and introduce any of those boxes and maybe other boxes down there to do specific functionality. Now on the controller side as I said earlier we have applications. A specific application is responsible for really a small piece of data path functionality for instance we have here port security. Port security is a quite simple application. It is responsible for a specific table where packets go through when they are coming out of a VM or container and this port security application will just filter all the packets that match the source IP and our MAC address of a specific port so the VM will not be able to max poof its packets in the bridge. And again we used Stibler here to allow dynamic registration of applications so you can write an application, put it outside of the project and it will be loaded and started by Dragonflow as if it were one of the core applications. So Stibler really helped us out on this aspect. And if we are going to talk a bit more about Dragonflow applications there are basically kind of three major types that can be classified into. We talked about Dragonflow earlier. So one simple example for applications are applications that just use flows. So the application receives events from the database and it will modify specific tables to match to the policy described by the table. This can be a port security as I mentioned earlier that it sees a new port created and it can create a new valid flow in the port security table. It can be routing that sees that a new router is created and it will create a new routing rule in a table. And this is kind of the best applications in terms of performance because the packet will be serviced entirely by the OBS and the packet does not have to travel anywhere and the problem is really constrained into this specific bridge. And some examples as I said earlier are port security, L2 forwarding, routing, responding to R-preqs and ICMP pings. Now second type of Dragonflow applications are a bit more complex. One of the things that OpenFlow allows is to send a packet to the controller of the bridge. So the second type is kind of applications that install flows but also send packets to the controller for handling. And this can be an issue for both the control plane perspective because your controller is now also dealing with the forwarding and data plane a bit. It has to process packets and also from the database perspective because now your controller has to... The packets have more latency because the packet has to go to the controller, controller has to treat it and send it back to the bridge. But it also allows you to implement a more complex functionality like the DHCP server. So the DHCP application will capture all the DHCP discover and request packets coming out of virtual machine and then it will see what port it is coming from and graph a specific reply packet and inject it back into the bridge. And there are other examples for why this can be useful. And finally the last type of applications are kind of the most complex where we have the application that installs flows but we also deploy an external service on the side. We attach an interface to our Tor switch and we configure an external service to listen on this interface and then we install the flows that route specific kinds of traffic into this service interface. And it allows us to do a lot of much more complex things like a metadata service which is basically HTTP proxy for some Nova API or maybe a DNS lookup or a load balancing by deploying HAProxy alongside the Dragonflow controller. And it basically allows us to take advantage of the protocol stack on the hypervisor because in the previous slide when we are packing in our packets to the controller we had to deal with the protocols ourselves and if you look at HTTP request it's quite harder to do this because there is a lot of state we have to implement TCP in our controller and we have to implement HTTP on top of that and by deploying a sidecar service and attaching it to the bridge we can just take advantage of the hypervisor TCP stack and use that for the controller. But there are also downsides to all of this because now we have to make sure our service is alive as well we have to deploy it, we have to configure it we have more moving parts on the computer and we have to make sure they are alive and behave well and now kind of the problems all three types of the applications they were doing one thing in common they were installing flows and as we saw earlier openflow is quite a low level API for a switch and forwarding configuration so this works well enough if you have your own applications and you can kind of coordinate what tables you will use and what registers you will use and you will make sure there is no application that steps on the toes of another application but this won't work well if you want to have third-party applications or maybe plug-in applications where you have two applications that have no notion of one of another and they want to use the same flows or maybe the same registers this will cause trouble and not just plug-able applications we have some of those flows inside Dragonflow code itself we have our table 55 with handles L2 forwarding and then we have some flows installed there by the forwarding application but also some flows installed by the 3-year-olding application and some flows by the DRAT application and now we have to coordinate the priorities of the flows of each application with all the application you will need and we have to make sure that when we delete flows we don't delete flows from another application and this basically means that a lot of care should be taken when adding and changing stuff there and debugging and troubleshooting is much harder than stuff don't work so it's really not a nice way to let people write plug-able applications but then run into this kind of trouble so what we came up with we decided that we are going to introduce something called application specifications so each application will specify what kind of interface it exposes to towards the data path and kind of wrap each application into a black box on the data path where the application itself will be responsible for whatever happens inside this black box but nothing of what happens outside so the basic specification of an application looks like how many tables it wants to use and what registers it is going to use to implement the functionality and what are the application entry points and the exit points now an application entry point is basically a callback into something that we want the application to do for instance here we have a security group example a security group application enforces network policies on the cloud network so we can have a network policy saying that for this VM we want to allow incoming ICB packets but we don't want any of UDP or something like that and here we have two entry points and two exit points now an entry point means that all packets coming into this entry point will be serviced as if they are ingress for a specific VM and the egress entry point will be handling all the packets coming out of the specific VM so if you want to use this kind of black box we'll have to wire all the packets coming out of the VM to the egress port and coming into the VM into the ingress entry point and the exit points are basically the same where each application is kind of taking packets in and outputs them out so if you have several entry points it may have sense to have several exit points but the relation is not always one to one for instance we may have L2 application that does forwarding so we may have only a single entry point but we have several exit points for instance one for unicast packets but also one for multicast packets and along with the specification we also introduced a more strict semantics for applications so this won't be for nothing we decided on a set of rules that an application should abide by and one of them is we said earlier that we require application to declare all the tables it's going to use so an application can only really interact with its own tables now and it can only access the registers that it declared it will use it will only go to between tables of its own or maybe to one of the exit points and if we talked earlier about this packet in packet out to the controller functionality then the application won't intercept packets from tables that belong to other applications and won't inject packets back to tables of other applications so basically confines itself into this kind of specification black box and now if we kind of zoom out of a single application we still have the data path and now it's built of those boxes so the controller itself is responsible for connecting all of those applications between themselves and on this level the connection is quite simple there's no branching each exit point goes to exactly one entry point and the controller also is responsible to swap the registers between the applications so if one application expects some value to be stored as rack 5 but other application expects it at track 7 and the controller will be responsible to move it between the registers and this also allows us kind of net functionality that now we can validate a lot of stuff about the data path we can see if there are any maybe unwired entry points or maybe applications that are at all not unreachable that are not reachable at all or maybe we are consuming a variable in application A but no application before it so we can run into some trouble there it allows us to assert more correctness on the data path now that we have those kind of contracts between the applications and finally to allow all of this integration between applications we wanted to make all this wiring configurable so the controller itself as we said earlier it handles the actual wiring between an exit point and an entry point but it does this by reading the configuration so if you want to plug in a new application you just have to edit as a stevedor entry point and you go to the configuration for the data path and you kind of insert it on one of the edges or maybe several ones and you don't have to modify the Dragonflow code itself what we try to achieve here is that we really try to be able to write a specific feature top to bottom from the management to the data path itself without being required to actually go into the Dragonflow code and modify internal functionality that's about all I have on this topic we are an open source project and we'd be happy if you see a new participate we have an IRC channel it's a hash-open-stack-drag-on-flow at Feynard and we have weekend meetings one for actually the times are bi-weekly we have one for for the Pacific time zone and one for the US and that's it, thank you if anyone has any questions I'd be happy to take them yes do you have plans to implement load balancers as a service? do we have plans to implement load balancers yes, actually we have a specification and design already done and we have someone working on that right now I think at the moment we don't plan to do L7 right off the bat we want to do L4 first and I think we will do L7 maybe with a proxy I don't know anything else?