 Okay. Hello, everybody. Can you hear me? Good. Thank you very much. Welcome to our presentation. I'm really excited to see that many people here. And our presentation is about the integration of OpenContrail and Open Daylight with OpenStack. We want to talk today about the pain, the gain and the lessons learned while integrating. So the contents of the presentation will start with general description of what to expect. Then we'll introduce ourselves and give credits to people who were very kind to help us with this presentation. We're going to talk about what SDN is and discuss the benefits of SDN in modern networks and touch on popular SDN controllers, which is in our presentation will be OpenContrail and Open Daylight. And we'll discuss the industry trends with regards to those SDN controllers. And we have a lab demo that will be used during the presentation to demonstrate different things we're talking about. So this is a tutorial style presentation mixed with some architectural descriptions. So we want you to have a recipe that works. And this was the goal of our presentation. There will be no focus on specific features of any particular SDN controller. And we are focusing on integration with DevStack today. We're assuming that everyone in this audience has basic understanding of OpenStack. And there will be no vendor-specific discussions. We do not go deep into protocol discussion. We're not going to talk about OpenFlow, SSMPP and stuff. And we'll avoid discussions about which SDN controller is the best, or which one should be and should not be used. It's not the point. We're here as we work for Ericsson. And we're here also as enthusiastic members of OpenStack community. And we strongly believe in open source collaboration and development in open source framework. So let me introduce myself. My name is Konstantin Kamaristi. I work for Ericsson. I'm in telecom industry more than 20 years. I worked on different projects with different products. And time came to get more familiar with software-defined networking. Hence we started working on this. And let me present my colleague, Syed. He's also a telecom veteran. He has vast experience in network equipment, network projects related and many other things. And would like to say special thanks to our colleagues from Ericsson, Team Inrich and François Limarchand, who have helped us a lot, inspired us, and shared their vast knowledge on the subject. The SDN is defined by Open Networking Forum. It's a long definition. You can read. But I would like to focus on the highlighted keywords. It's a dynamic solution. It's manageable solution and cost effective. This is very important and adoptable. If it's not cost effective, it's not going to be adopted. The solution should decouple the network control and forwarding functions. And it should allow direct programmability of networking devices. So this is in brief what SDN is. SDN comes to solve certain problems with traditional networks. We know that there are certain things that traditional networks are suffering from. I've listed a few points here. The traditional networks are mostly hardware oriented and static in nature. So any changes that needs to be done will require manual configuration. And sometimes it's difficult to achieve within short times. Maintenance windows required. And errors are possible. So the town times are possible. The distributed control plain-leg scaling. What does it mean is that the control decisions are distributed across the networks in different devices. So it's hard to synchronize that and keep everything under control. More than that, management plain sometimes uses proprietary implementations. So they're not always compatible and interoperability is not always great. So these are the shortcomings of traditional networking. So here's a great slide. It depicts two use cases on the top where something like cloud is. It's like a wide array network east to west with lots of routers and some networking equipment. Let's say if we need to introduce some changes or reconfiguration in the network. This requires work on all of those devices. And like I said before, it's going to cost a lot of time, effort, sometimes manual labor, and actually can lead to errors and town times. Or on the bottom part of this slide, there is a data-centric use case. For example, if we need to create another web server and provide a VPN tunnel for this server to be accessible from outside. So here's a bunch of configuration needs to be done, usually manually, usually time-consuming and all in all, dissatisfying the customer and making things more expensive. So the SDN is supposed to bring changes that will make life better in this respect. So the centralized management and control planes, that means that the control function that was previously divided between control and management plane now can be centralized in one controller, one system. Another benefit is that control and data plan, plane can scale independently. So you don't need to scale control plane just to be able to scale the data plan and the other ways. The interoperability is improved. That's the promise of SDN. The networking devices can be programmed automatically. And this is making operations cheaper and more efficient. It's possible to start using commodity hardware, also making operations more efficient. And the adoption of SDN would facilitate migration to software-based networking. Think of a paradigm shift that happens in the last decade in virtualization in computing domain. So the same thing is about or happening already in the networking domain. Finally, the wider adoption of SDN will enable also adoption of scalable and dynamic applications. So that's the next thing that's coming. There are many SDN controllers on the market. There's a long history behind it. We have put a link to some exhaustive list of SDN controllers available. You are very familiar with one of them, which is Neutron. And today, we're going to discuss open control and open daylight. In order to demonstrate this integration that we're going to talk about today, we have built a small lab. The purpose of this lab was exactly to show that this can be done in a very small environment, fairly easy, and it's easily reproducible and gives ability to experiment with SDN concepts in a small and cheap environment without big expense. So as you see, there is a Nuke Intel little box with 4 CPUs, 16 RAM, a gigabyte SSD, and 250 gigabyte SSD. So we put latest Ubuntu image on it and activated the nested virtualization. This is important. Most of the cookbooks miss to mention that step. Maybe everybody knows, but some don't know. So this is a nasty surprise when you deploy everything and you cannot run the VM on top of VM. So you need to enable it from the base up. Here's one of the views on architecture of open control. So I'll take over and we'll go over the architecture of open control. But before we do that, a word of caution. If you're trying to explore the integration of SDN controllers with OpenStack, and if you do it for two weeks, this is what you get. And by that, I mean gray here, and a little bit less here as well. So we'll try to make that pain easy for you. So the end result is not like this. Still bright and handsome, but black here. So let's maybe understand a bit about the architecture because what we want to do is we want to make it easy for you when you integrate the components and when it fails, where do you find the problem? I think that's one of the biggest challenges of open source and OpenStack and the integration. So let's take a familiar view and we start with the neutron. Someone told me that neutron is a poor man's choice of SDN controller. So if you don't have SDN at all, you still got neutron. So we've got the neutron which actually talks to the REST API in the management layer of the open control system. I was trying to move the mouse on my screen, but actually we don't see that there. So let's see if we can break it down. Okay. So the view is slightly smaller, but I think it will help us explain it a little better. So you've got neutron on the top left corner and you have your applications, OSS, BSS, GUI, etc. These are the ones that will actually want to create those dynamic networks, the virtualized networks. So they push in the request towards the REST API for your controller. Within the controller, you have three different main sub components. You've got the configuration node, the analytics node, and then the control node. The configuration node is responsible for receiving the request and doing a high level to a low level translation. Analytics is responsible for continuously monitoring and analyzing the current deployments and seeing what's going on in your forwarding plane. And the control plane is responsible for pushing the request. Another way to look at the same is to look at the flow control. So here we are trying to show that OpenStack sends the request towards Neutron server. Neutron servers talks to the control configuration node. Configuration node wants to make sure that whatever request has been sent is persistent. So it needs to store it in the database. Once that is done, it also pushes down to the control node and the control node is responsible for pushing it onto your forwarding plane. One last view about this and I promise I'm not going to drag this any further and we'll go directly into the installation. But this I find really interesting because here you can see the setup. So traditionally speaking, we come from the ODL family and ODL came more naturally to us because we worked with OVS for a long time. So the first thing we noticed when we were trying to deploy OpenContrail is where is my OVS? And there is no OVS. So you have these kernel modules which were built in and they're part of a kernel. So instead of the OVS agents, you have the Vrouter agent which replaces the OVS agent. And then instead of the data plane that you find in OVS, you have the V kernel module which does a forwarding part. The rest of the setup is very, very similar and this picture I think is a good depiction of what to expect when you're trying to analyze the call flow. So as a next step, we'll take you into the details of installation and Konstantin has a lot to talk to you about the pains, gains and what we've learned. Okay. Now it's not so a lot, so it's shorter. So we have installed a virtual machine on top of our KVM host. It's important to use exactly this version of Ubuntu 14.04.4. Most of the cookbooks that you can find, many of them on the internet, do not mention the last digit and this is the one that is in the details. The compatibility of libraries and image are very important and so far this is the only configuration that has worked for me and believe me, I tried a lot. So we've used this size, like a 15 gig of RAM and 4 CPUs, 70 gig of hard drive for the VM and we'll create two VMs basically on this host, one for OpenContrail and DevStack integration, the other one for ODL and DevStack, but we create them with the same size of the virtual machine and we can run them at the same time in parallel, so kind of over committing, but it's not a problem because there is no load in this environment, so they can coexist peacefully, which we'll show later. So again, we need to not to forget to configure nested KVM Intel nested feature. You need to edit the grab file, update grab reboot and verify that it is in place. So follow the steps as it's shown. To have more control of the installation, I usually disable resolveconf and the HCP components. So in the middle of installation, sometimes I've seen that resolveconf defines something different as a gateway or some other DNS servers and then the installation may fail. So I just delete that. And we need to install Git. We clone the JuniperContrailInstaller project. I recommend to clone at the same time OpenStack DevStack project. So we're pulling the master branch from Juniper OpenContrailInstaller and we're putting stable Mitaka branch from DevStack. You should create the two environmental variables, ContrailDeer and DevStackDeer for it somewhere. So it's always there when the user logs in. And now we're coming to configuration. We should have a local RC file which can be copied from samples. And I recommend to uncomment the line ContrailRepoProto equals HTTPS. So in this case, the getting of the packages that are needed during the installation will be done over HTTPS. So you would not need to configure SSH key. I recommend to change the number of jobs to maximum number of CPUs available on your KVM host or available to the VM. This is to make the build and installation a bit faster because it takes a long time. So we'll let four CPUs work at full speed. And something that I found during the installation, they need to enable multi-tendency in this file. Otherwise, the installation will fail because the some network for certain tenant ID cannot be created and the installation will fail. So this has to be done in two places. I'll show the later, I'll show the other one where it has to be done. So the steps to build OpenContrail are simple. So there is a file, the script Contrail.sh. So we need to build first. This takes the longest time, one hour, 12 minutes for my setup. And then we install. That's another half an hour. The other two steps are fast. As a result, if these two environmental variables were defined before and the DevStack GitHub project has been cloned already, then we will be able to run the OpenContrail status verification script. So you should see all the components in active state. And this is a good state. You should see that. Then we go into the next step, which is building DevStack. So we go into DevStack folder and copying the glue file that is provided with the Contrail installer project. We're copying it into DevStack Lib Neutron plugins folder. Then we create the local RC configuration file. And we need to change a little bit the configuration to match the environment. And disable this optional, but I recommend to disable Cinder service. So we don't need to change the volume at this time. And it's going to make things easier and faster. So when we run this StackSH script, it's always coming to an error very quickly because of unmet dependencies. Actually, the error prints out the recommendation how to fix that by forcing the installation. So I just chosen that method. And then we run the Stack.sh. After 20 minutes, we get another error. And this error is showing up in most of the cookbooks available on the internet. You will see that this is a popular fix. So it's also in this cookbook. Then I recommend to run the Unstack and rerun the Stack again. And yet we get another error after half an hour, which we can work around by restarting the whole system and rerunning the Stack again. So this takes another eight minutes for the Stack to start. And it's important to mention, I don't know if I can highlight it. No, I cannot. Before building the Stack, okay, one second. I wanted to highlight this section. Okay, so now can you switch back? Please. I found that if this is not done, then you would not be able to open the VNC consoles to the instances that you're running. Actually, you will be able to open the VNC consoles, but you cannot type anything there. It will get some keyboard errors. So this is a workaround to make it work. As a result, you get the functional environment with the Stack dashboard and OpenContrail GUI. And that is the working system. And now we can experiment with that. So now we're switching to ODEAL. I just wanted to highlight a few things quickly before we move on, because a lot of us overlook these things. First of all, why Nuke and why DevStack? We are lucky to be working for a company where if we want to do a project, we can get a lot of servers, but not everyone has that luxury. So we wanted to create a cookbook that can be used and deployed for anyone and set up the environment on their lab. So when your manager comes and asks you to evaluate these technologies, you don't have to rent out or get the equipment, a lot of service. The other thing that Constantine figured out, there's a lot of recipes that tell you how to deploy OpenContrail and ODEAL. And they tell you, okay, you need to use Linux or Ubuntu 14.04. But the amount of variation when you go from 14.04.1 to 14.04.2 to 14.04.3, all the way up to different stuff, it changes things beyond your imagination. So if someone comes and tells you that OpenContrail and integration of OpenStack was so 2014, you tell them to talk to us and we'll show them the logs that we actually produced trying to make it work on different integrations. So apparently it's very easy to do, but don't take it for granted. So we try to put in as many details as we can. So here you see the very specifics that you do. Also, it's worth it to mention that since we are taking the code directly from the repo, and repo is changing constantly. So whatever worked for you yesterday, it won't work for you tomorrow. These are the challenges that you need to be aware of. And that's why you see, so luckily the light is not that much. So you don't see the gray in my hair, but you would definitely see it next time if you're still doing this. And let's go into ODL. ODL was a little more natural to us because we've had a chance to work with it for a while. So apparently there's a lot more information that was easily available to us for ODL. It seems it's well documented. So perhaps a recommendation from us, from open source enthusiasts to open control community, please start producing the documentation that will attract more people to open control as well if you want it to be successful. Just like what ODL has done. So let's start without going into too much details of that, let's go into ODL. So the architecture of ODL is based on microservices. That gives you the ability and flexibility to add and remove services on the runtime. You don't need to reinstall, recompile and things like that. You want to add BGP. That's a component. You download, you deploy, and you're good to go. I love that aspect of it. Platform independent. I was having a conversation with Konstantin about it. And of course we say that ODL is platform independent because it's run as a JVM. And then we got into a different discussion of, well, okay, that can be argued. But this is the information that we found on the ODL.org. So we've decided to do a little bit of research on that. And I think it works pretty well. The other important thing is that it's at parity with reference to Neutron. A lot of us here because we are talking about open stack. So we are open stack centric. So when we start exploring SDN, we are more familiar with Neutron. So anything that claims and works actually and we've tested it, if it's at parity with what Neutron is, it's naturally more easy for us. Now let's get into the scary part of ODL. If you're trying to understand the architecture of ODL, and this is a diagram that you see, it might look a little overwhelming for you at the start, but we've tried to break it down. And I'll try to explain it in a way that I can explain it to my five-year-old nephew and he kind of understood. So if he can understand it, I'm sure you guys can understand it too. So let's take a top-to-bottom approach. You've got the northbound interface. The northbound interface is where you'll receive the request from OpenStack. You'll receive the request from OSSBSS. And that's where you can actually deploy the application to ask ODL to do what you want it to do. On the center there, you've got the control part. So this whole part, this is where you deploy your, this is the modular MD-SAL architecture. And you have the microservices running here. So you receive the request, and then depending on what the request is, you forward that request to that particular module. That module does what it needs to do and converts that onto the hardware equipment or virtualized equipment that you're working with. So if you're working with the typical hardware deployed, Junipers or Cisco or Sianas, and you have a plug-in for those using protocols like XMPB, actually OVSTB, OpenFlow, BGP and things like that, then it will get translated here and it will get pushed down towards the southbound interface. One last thing about this architecture before we go and see how we've done it in our lab. So this is the diagram that you actually see. These are the different connections between different services. I will talk only about the OpenStack aspect because I think that makes more sense instead of talking about other things. So here you see that the OpenStack is sending a request towards the Neutron API. Neutron API sends a request to OpenStack Neutron services running in the Open Daylight Controller platform. Now here you have the option of using VTN, which is a new feature, and that sends a request down to your OVSTB. OVSTB is responsible for talking to your different OVST or host servers and pushing the configuration and the flows with OpenFlow onto your hosts. And if you're looking for the plugin architecture, this basically shows you the plugin architecture where you have the Neutron. We've eliminated NOVA and Cinder, et cetera, et cetera. It makes life easier. It makes it easier to understand as well. And then you have the ODEAL controller in the center. And we see that everything actually is going through the MD cell data center. So you receive the request, and then this is the controller for the OpenStack services, and then you have the OVSTB and the OpenFlow talking to your compute host. So now let's go ahead and look at the installation that we have in the lab, and Konstantin will walk you through that. Thank you. The five-year-old nephew that understands the concept of Northbound Interface is a little bit scary, but... You have the genes in the family. Okay. So the OpenDay Lite and DevStack integration is also running as a virtual machine. We've used the Ubuntu 17.04, and the size of the VM, the same size as the OpenContrail VM. Same trick is used for controlling the IP environment, no resolve conf, no DHCP components. We're installing Git, and we're creating a special user that will be needed for building and running OpenDay Lite and DevStack. So the user is called Stack. So you will find these instructions in absolutely every cookbook that you can find on the Internet and in the official ODEAL documentation. So we clone the OpenStack DevStack and proceed with configuring the installation with local confile. I have found the very detailed instructions in the link provided on top of the slide, and I advise you to read through and try to understand all of the options available. You probably don't need all of them, but it's good to understand what they are before spending hours in reinstalling the system and finding that you're missing something that was important. But for your convenience, I've compiled a list of parameters that you should configure in order to get a working installation. So on the top, we configured the IP connectivity. And on the middle of the slide, there's lines starting with ODEAL underscore. We specifically want to install the Boron SR3 release. And these features that are listed below and these are the features that will be available in the deluxe GUI. And by default, the ODEAL deluxe core is installed. And that will not let you see all the possibilities in the deluxe GUI. So I recommend to put ODEAL deluxe all during the installation. And also, we've added ODEAL layer 2 switch all. So just use that and that should work. And there is a bunch of services that we need to enable and disable for just to fit them on one slide, I've listed them in a line format. But in the configuration file, each parameter needs to be in a separate line. So these are the configurations. Running stack.sh takes approximately 20 minutes. At the end, you will get the URL for dashboard and credentials. And also, I've added this boxed text at the bottom of the slide. This is the URL to log into deluxe GUI and credentials. So as a result, you have dashboard and the deluxe GUI. So if the parameters were not correctly set in the configuration file, you will end up only with the topology view. And the rest of the views will be missing. So if you use the configuration as specified on the slides before, you will get these views in the GUI. So there is a nodes view and Yang UI, which I understand is kind of SDK with the possibility to send rest API requests to different services and parameterize them. And it's interesting to experiment with that. And there is also a young visualizer which helps to visualize the data models and objects created in the configuration. So as a result, we have this environment with a host running two virtual machines. We've noticed that running side by side, the OpenContrail virtual machine consumes more CPU than the ODEAL without any load in idle state. So it's something interesting. We don't know. We never tested yet the system under any kind of load, not in this environment for sure, but this is interesting to get these metrics in future exploration. And now we're getting to the end of the presentation. And we'd like to discuss the industry trends in terms of adoption of SDN controllers discussed today. We have a list of operators and vendors on this page that are using OpenContrail. And they are listed on the OpenContrail website. And these are big companies. And we have a list of operators and vendors that are involved with Open Daylight. It's interesting to see that AT&T and Juniper are also involved in this project. So it's not an indication of good and bad. It's an indication of specific need, use case, scenario. And so it's good to understand the difference. So also I would like to say that on this summit, there are many very knowledgeable people presenting the SDN controllers. Do you want to say? No, no, go for it. So we've seen the Juniper booth. And it would be interesting to talk to engineers from Juniper about this. And you can ask them more questions. And for sure they will give you more details. And add something exactly. Thank you. And yes, I'll give the mic to Mike. So yeah, we've tried to be, as we were explaining before, we want to be vendor neutral. We are not here to compare one with the other. So Konstantin here is telling you guys to go and talk to the guys in Juniper. I'm here representing Ericsson and ODL side of it. So make sure to drop by the Ericsson booth as well. We've got some really fantastic people who know a lot more about ODL than ourselves. So this is something I promised the marketing guy, so that is taken care of. I forgot to mention that Ericsson is actively involved with Open Daylight project and makes a lot of code contributions upstreaming into Open Daylight project. So this is important to mention. So we have, I think we started a bit late because of the setup. So we have an option to, or actually we could have shown you the lab setup, but I think we should give time for the next presentation presenters to come in. Can I ask a quick question? Sure. Actually, two. One is, did you do Apple to Apple comparison in terms of the performance? Absolutely not. So that was the whole idea. We're not here to talk about the advanced Apple to Apple comparison. We are here for the people who actually want to start the exploration of SDN with OpenStack. Next question, please. And let's make it quick, please. Okay. So in terms, you showed ML2 path, the Neutron path as well as the monolithic ODL. Correct. So the backend is exactly identical or are there any differences? So the thing is architecture is changing from one release to the other. For example, ODL last time had a rev one for the ML2 side and they realized that somebody in Japan was doing testing and they found out that it can actually cause an event where you have parallel threads that can try to register the same network in the database. Now, in order to resolve that, they had to change the architecture and now there's a rev two available. So as we move forward, we are actually trying to analyze different paths of what is the optimal way. So it's not a set architecture. It will not be final. It will continue to evolve. Guys, thank you very much. Thank you very much for your attention. Thank you very much.