 Hello, thanks for joining me. I know I stand between you and lunch, so I'll try to stick to the time that I have. My name is Valentina Larry, and I work for Plumgrid. And if you don't know Plumgrid, we are a software-finding networking company, and we have a Neutron plug-in. And that's the end of the pitch. I'm not going to talk product today. Just a little bit about myself. I've been a member of the OpenStyle community for a number of years. My first summit was the Santa Clara Summit, so it's pretty amazing to see the evolution of us as a community. We have come a long way. I've been very lucky to work with customers since the early days of software-finding networks and OpenStack, helping them through the deployments. So working with users as they learn how to leverage this technology, how to leverage the products that are part of the OpenStack ecosystem. And I do quite a bit of work with customers today in terms of helping them getting educated on the technology and how it works, what are some of the challenges, and the architectural considerations that they need to go through as they consider adopting OpenStack in their environments. And you can find my content information there. Before we jump into the presentation, I want to get just a feel for how many of you have OpenStack deployed with either Nova Network or Neutron today? Quite a few. So I'll try to take everybody else along and cut to the point of making some interesting considerations here. Just want to know, there's been so many interesting, great sessions around what is Neutron and Neutron 101 throughout the week. So I'm going to try to give it a little bit of a different spin and talk about architectural considerations throughout your design phase. So just to get everybody on the same page, obviously, we're talking OpenStack. We've been here for four days. It's been a great summit. But I just want to put this one slide up one more time to remember all of you that what OpenStack is aiming at doing, and this is particularly true for the natural component, is to provide an API, so an abstraction layer that users, whether this user is a cloud operator or this user is a tenant, can then leverage to solve service provision resources. And this API should be able to abstract what the resource underneath is. And this is particularly important for networking because there is so many implementations. And we're going to touch upon some of those. But there's so many different implementations of the actual backend. And it's fundamental that as a user, especially the tenant, so the end consumer of the cloud, is not exposed to that complexity. And they can just consume it as a very simple self-service kind of model. Now, I've been working on networking for a number of years. And I'm sorry about that. This slide is moving on me. I've been working on networking for a number of years. And when I talked to customers, they asked me, why is it so complicated to actually get my network infrastructure up and running? And I was talking with one of them a couple of weeks back. And they were sharing with me that whenever they need to bring up a new customer environment, it takes them anywhere from 60 to 80 tickets to be open to imagine the process of getting, logging into whatever ticketing system they have and creating all these 75 tickets. And then somebody has to get in there and process all of them and provision all the resources the tickets request. And it takes them about four weeks to go through this process. And obviously, the ideal state is what you see on the other side of this slide, which is being able to bring up the infrastructure that is needed for the tenants of a cloud in zero tickets and zero time. Now, we all know that that doesn't exist, but we certainly want to converge that number. So what I'll try to cover today is how can we get there as a community and as users of OpenStack? So when you look at leveraging OpenStack in your environment, certainly you can go through your trials, POC, pilot kind of phases. And if you have a very small number of nodes and servers, most of the options out there will probably work for you. And so what I'm going to try to concentrate on today instead is when you get to the peak of that mountain, when you get to the production phase of your cloud, what is it that you need to worry about? And it's quite different deploying four nodes to deploying 100 or 1,000 nodes in your cloud environment. And so sometimes I talk to people and they're like, hey, I brought up my cloud and I can do anything I want with four nodes. Is that a cloud? And don't know offense, but let's look at what it takes to get to much larger numbers. So a few things, again, that I discuss with the users I work with on a daily basis is certainly as a first mandatory item is you're building a cloud environment. And cloud by definition means multi-tenant. So obviously it's built into Neutron and I'll touch upon how that's built, but that's a fundamental principle of your cloud infrastructures. Being able to isolate effectively tenants, call it microsegmentation, call it virtual domains, call it tenant environments, call it logical networks, whatever it's a terminology that you want to use, but you want to make sure that the traffic from one tenant has nothing to do with the traffic from another tenant. And we'll talk about how Neutron achieves that and how Nova Networks has used that as well. The second point becomes more and more relevant as you scale out your environment. What are the performance of the backend implementation that you're leveraging? How is it going to scale and change as you throw more nodes into your cloud? And the third bullet is something I'm particularly passionate about because that's a big transformation. High availability in this new cloud model of everything software defined, it's very, very different from what we're all used to in a hardware network model. So what are the principle of high availability? How does the Neutron abstraction help you with and what are some of the considerations that you need to keep in mind as you evaluate different backend options? Extensibility, all of you today might have a specific set of use cases in mind, but you're building this crowd for the future. So how can you choose components that can be easily extended to enable you to then roll out new use cases on top of it? And last but not least, it's everything that has to do with a production environment, right? Is it stable? Can you troubleshoot it? I'm not gonna touch upon the last two bullets, but I'll spend quite a bit of time on the performance and scale and the extensibility aspects. Now, before I jump into that, let me just take you through a journey, the journey of OpenStack Networking. It all started with Nova Networks. As some of you that were part of the OpenStack community before the fall-sum release know that there's been some functionality in terms of networking that has been present within the Nova project. So Nova is the compute aspect, right? And until fall-sum, that was the only option for defining and consuming network resources. Nova has, let's call it a basic support for networking and I'll elaborate more on what I mean by that. And certainly, since the inception of Neutron, the development on the Nova front is less than. It hasn't stopped and that's a very important point that I want to cover. And as part of this summit, if you have walked into any of the rooms where the design summit is happening, there's been a lot of discussion around the migration path. This has been a big topic for a number of summits. How do we take users that are on Nova Networks today all the way to Neutron? So the first consideration that I wanna make here is that there's certainly nothing wrong with starting with Nova Networks, but what I wanna help you with is to understand where Nova Network can take you and what Neutron is building on top of that. So the first model for Nova Network, it's the very plain vanilla flat networking. Now, this is certainly not something that I would ever recommend for a cloud production environment because the principle underneath is that you're just mapping everything into a shared segment, right? So it's great to get started, great to learn about how everything works, but there's really no way for you to segment and isolate workloads in this environment. Whether it be virtual machines, containers, bare metals, it doesn't matter. This is a flat model, so you're stuck with it. We're just having everyone talk to everyone. The next step, which is something that it supported both in Nova Networks as well as obviously in Neutron is the ability to isolate tenants' workloads once more using VLANs. VLANs should be a concept that is very familiar to all of you, it's the ability to just logically carve your network into partitions, they are two segments that can then be used by different users of your infrastructure. VLANs have to be configured on your physical network. So this is one of the big challenges as you start scaling and growing your infrastructure, brought from a scalability perspective as well as from an operational perspective of having to go and maintain and configure these VLANs everywhere in your network, meaning every switch, every router, the traffic will go through. If you want to isolate VM traffic, you're gonna have to have this VLAN properly configured. So this kind of networking, 1.0, and if you're here and you've been exposed to some of the concepts of software defined networks, one of the big promises of that approach is to take you past this limitation of VLANs and enable you to create multi-titan constructs. There are a lot more powerful, a lot more scalable, and allow your fabric, your physical network to take you to much larger deployments. There's nothing wrong once more to start with this model. Just keep in mind that VLANs have a limit, it's a hard limit, there's only 4,000, and you're gonna have to deal with just keeping your physical network configuration in sync and taking care of throughout your entire cloud deployment. Now if you have taken a look at the recent user survey that came out on Monday, or Tuesday whenever it was Monday, there's a staggering 24% of users that is still using Nova Networks. So it's important as a community that all of you is familiar with Nova Networks, how they work, what they can give you, and a big question mark is how do we take these users forward? So I find very intriguing that pretty high numbers say, hey, yeah, I will consider moving to Neutron once two things have to happen. One, there has to be a clear migration path, and two, there has to be a simplification of Neutron itself. So Neutron has been for a number of releases, the number one concern for users is they are actually deploying an open stack cloud. So it's complex, it's hard to understand, there's a lot of moving parts, there's enhancements that have to come into the picture for it to become easy to deploy in a production environment. But keep in mind, again, that there is a very large number of users, and some of you have probably heard of some of those, some of the largest deployments are still running on Nova Networks. So don't underwrite the fact that that's certainly an option there. It wouldn't be my recommendation to start from Nova Networks. So if you're starting from scratch, if you're just embarking your journey, you know, in deploying an open stack cloud, you will certainly want to look at Neutron as your starting point. So Neutron was introduced with the Falsum release, before that, as I said, it was in part of open stack, and its mandate from the very beginning was to deliver on the promise of network as a service. So the ability for tenants, cloud operators to log into a dashboard, to use an API, to self-service provision network resources. It's a big mandate, and there's been a huge effort from all of us as a community to deliver on that. The other mandate for Neutron was to be a technology agnostic layer. What it means is that Neutron promises to provide an API layer that abstracts network resources to such a simple concept that each and every one can consume those resources without having to worry about whether it's implemented using venance or overlay networks, or whatever other magic, black magic you wanna use under the covers, okay? And these abstraction layer, it's important for each and every user because it gives you the ability to swap vendors in the backend. You have consistent API, consistent integration, and as you go through your evaluation of the different options, you can swap and replace components in the backend. And you see that each and every one of the options in the backend will give you different performance, different scales, different feature set. The other thing for Neutron is that from the beginning, it was designed to not just provide the basic network functionalities of layer two and layer three, but to allow users to define very rich and complex network topologies. Once more, because we wanna enable each and every user to bring each and every kind of application into cloud. And just a simple kind of Amazon model doesn't fit your enterprise application, doesn't fit your best practices of deploying applications on top of layer two, layer three, NAT, security, and so on and so forth. So Neutron from the beginning promises to deliver not just the basic network functionalities, but advanced services. There's been a lot of changes around advanced services with Kilo, and I'm not gonna cover much around what's changing in Kilo, but there is lots of references, and I'll post my slides on that sure, and there's gonna be a slide that points you to all the new features there, but certainly lots of changes happening around the advanced services area. Now, we talked about this already, but just to recap it once more, what is Neutron? It's an API layer. It's an API that allows you to manage network resources and allow for workloads to consume those resources. Those workloads can be virtual machines, they can be containers, they can be bare metal. There's obviously different integration models, and your network layer should be able to span across each and every one of you. And I mentioned earlier, the promise was to be technology agnostic, and the modular design of Neutron is what allows this being agnostic and enabling each and every vendor to provide a solution in the backend. The third bullet point, it's the promise of multi-tenancy and isolation. So Neutron, from the beginning, was designed with multi-tenant constructs embedded, so the ability for tenants of a cloud to self-service provision an environment and not have to worry about, is my IP address, oops, sorry guys, it's my IP address going to conflict with somebody else's IP address. It's your own bubble, it's your own private environment, and you can do as you wish within that. So this is just a reference architecture design of Neutron. And as you can see, it's really simple. There's a Neutron server that just really is exposing the API layer to whether it's a dashboard or directly the API to the user. And then under the covers, there's a plugin. And the plugin is how each vendor interacts and interfaces with Neutron. We'll talk a lot more about the different architectures and how different solutions in the backend change this kind of impact design. Again, I'm not gonna go into all the details of the different plugins, but I really like this slide, I really like this representation. So as you can see here, when you go and select plugins, there's tens and tens of plugins that are available today. Some of those are monolithic plugins. What it means is when you select one of these plugin, you just have kind of one backend that gets plugged into Neutron, and that's gonna be responsible for taking all the API calls that come from the top, from the dashboard or from the API itself, and satisfy the creation of all the network resources that are needed for the workloads. The ML2 plugin instead, it's a different, slightly different architecture where you can have multiple plugins that can coexist together. Use cases for this might be that you want to be able to control, let's say in a KVM environment and a Hyper-V environment at the same time, or you might wanna be able to control kind of your virtual network infrastructure, so your SDN layer, as well as your physical network infrastructure at the same time for some basic configuration, maybe in the physical network and some more advanced configuration in the virtual network. And then you have the advanced services, whether it's your load balancer, your VPN, your firewall. Neutron, from the beginning again, has an architecture that allows for those advanced services to be consumed as part of this network creation from the tenant. Now, I get a lot of questions about, is Neutron actually, you know, OBS, is Neutron implementing the Ligar 2? Now, the way to think about Neutron is that, as I said probably too many times already, it's really just an abstraction layer. It's a very thin layer. And all it does is to pass whatever API call and definition you make down into the backend. So if you're backend, it's an SDN kind of solution where you have a controller, what's gonna happen is you're gonna make an API call, the API call is gonna go through the Neutron server and it's gonna get pushed down into the SDN controller. And that's where then things will get implemented. If you're using kind of OBS and the network node, then that's where the functionality will be implemented. Some of it will happen inside the compute node, some of it will happen in the network node itself. Now, where the confusion comes from is because there's some reference architectures that are built on, for example, OBS and the network node that you should look at and you should certainly use as a starting point. But that Neutron again, it's vendor agnostic and you can use any backend implementation as you wish. Now what can you do with Neutron? That's where it gets interesting, right? So this is the representation of an open stack network. If you've ever, some of you that raised your hands and obviously have a deployment are very familiar with this. This is the dashboard horizon representation of a network in an open stack. Each of this bar is a network and each of this bar represents connectivity, whether it's internal connectivity between the ends that belong to the same tenant as well as external connectivity. So here we have a few internal networks, the web and the DB network, the green and the orange one that you see in this picture. And those are networks that a tenant was able to create just by logging into the dashboard without any understanding of the backend implementation underneath. So they created these networks, they define a subnet for it and what they can do is they can create, they can connect virtual machines to that network. Now, once you've done that, once you've created your two networks, what you can do next is you can interconnect your networks. So in this example here, you see we have the green and the orange network and then what the tenant decided to do was to interconnect them with a router. So this is kind of the simple abstraction the newsroom provides. And once you have defined your internal topology, what the network looks like, the next step is to define what the external connectivity looks like. So you can say, oh, my tenant network wants to connect to the outside world. Now, this is where things get interesting and that's a whole topic of provider networks, which I'm very passionate about and there's a lot of interesting things that you can do there but in a nutshell, the concept of provider networks is the ability for a tenant network to be connected with the external world. Now, if you look at this picture, this net that you see there, the blue one, is actually something that the cloud operator will create. The cloud operator will define this external connectivity construct that then the tenant can come and consume. So from an operational perspective, there's like an invisible boundary between the blue and the orange. Everything that it's right of the router, it's owned by the tenant. Anything that it's left of the router, it's owned by the cloud operator. But as you can see, the abstraction model, it's extremely simple, extremely easy to consume. Now, let's talk backend for a second. Something that Neutron really enabled was for each and every user to consume software-defined networks, overlay models. As I said earlier, the need for those new models comes from the limitations that are implicit in leveraging VLANs to isolate your infrastructure. So in an overlay model, what happens is that you are creating isolated environments by encapsulating frames, packets that come from the virtual machine into some form of tunnel. Whether it's VXLAN, MVGRE, or whatever other tunnel you wish to use, this encapsulation provides the isolation and the segmentation between tenants. The beauty of this model is that because you're using an encapsulation, you are decoupling your logical virtual plane from your physical network. So every time a tenant comes into a horizon and consumes resources, they're doing something that it's expressed in the virtual network. And your physical network, it's very stable and doesn't require too much changes, which is important for your business because changes are risky and you don't want to take down your network. All right, so this is how Neutron changes the rules of the game. Now, because of all these changes and all these options in the backend, users ask me, okay, how do I go about evaluating skills and performance? What are the things that I need to keep in mind? So I'm gonna quickly walk you through some of the considerations here and I wanna make sure I leave some time for Q and A. Sure. So when you talk about extensibility and performance, there's one piece of the puzzle that it's very important and that's a data plane. So your data plane means quite a bit in terms of giving you different performance and scalability, all right? That's right. So if you look at the different options that you have there, I like to put them on kind of an evolution scale because really they provide different set of functionalities. So if you start from the left, you have kind of the concept of a V-switch. You know, this is the concept of bringing the network layer all the way within your hypervisor and providing some layer two functionalities in software right within the kernel or the user space of a server so that VMs can interconnect and talk to each other without having to go into the physical infrastructure. Now that's great, but what about, you know, what if I want to connect with a VM that sits on another server? That's where the concept of a distributed virtual switch comes into the picture. So the DVS kind of construct is the ability to have a V-switch that spans multiple physical servers. Very often this spanning across physical servers comes in conjunction with the overlay model that I described previously. So the ability to stretch this layer to construct across your physical infrastructure. But hey, what if I want routing? Let's plug a router into it, right? And then you can evolve all the way to the place where you have kind of your entire logical topology that can be stretched across your physical infrastructure and can live across multiple servers. Now there's been a lot of innovation in data planes and this is really, you know, what you need to look at and there's more and more that is being done around building extensible data planes. And what I mean by that is the ability to have a programmable data plane where you can load dynamically new features and functionalities in there. So when you look at selecting different vendors, different options, whether it's vendors or open source doesn't really matter there. You should look at where do you want to be in this evolution. And each of those will give you a different set of features and more importantly, a different set of scalability properties and performance. Now, let me just give you an example. It's a very ugly representation, sorry about that, but it kind of, you know, makes the point that I want to bring here, which is if you look inside a compute node and you break it in a very simplistic way into two parts, you have your kernel and your user space. Kernel fast, user space lower, all right? Now, when you look at where your functionality, network functionality, whether it's layer two or layer three or not, or security or whatever else leaves, it can live in two places, one of two places or a combination of two. It can live in the kernel, meaning that VMs will be able to switch traffic right from a kernel perspective or especially for higher functionality like layer three and not and security, it might leave as a user space component. So to access that resource, the VM traffic needs to go through the kernel, up to the user space, back down to the kernel, back up to the VM. So much slower in terms of performance. So when you look at the different options, consider where the features and functionalities are implemented. And for some of the different implementations for Neutron and the references implementations to use network nodes, the functionalities that you have, whether it's layer two, layer three, the ACP advanced services are often implemented as agents. Those agents can live on the network node. Think about the network node as an additional network component which is deployed in a central location that can help you with the more advanced functionality or as agents inside each hypervisor like the layer two agent. Now why does this matter? The reason why it matters is because when you look at your virtual machine traffic, if you're leveraging agents, you're gonna look at some pretty odd behaviors where some of the traffic gets switched locally within a server. Some of the traffic gets punted up all the way to the network node. Now there's more and more improvements that are coming, more and more and more advances in the architectures of the different solutions where a lot of these functions are getting pushed down into the servers itself inside the kernel. But if you're using implementations where there is a component like the network node, what it's important to understand is that some of your data traffic will actually go up to that network node. So placement, sizing, bandwidth considerations are imperative when you look at deploying an infrastructure that has that. And as you skate out, the need for that network node will change. Now if you're instead using an agent-less kind of implementation, which is for the most part a case where you're using, when you're using a SDN solution with a controller, what happens is most of those agents are gone. You're just gonna talk to the controller and say, hey, I need these network functionalities to be created for me. And then the controller will go and get it instantiated in the data planes. Now assuming you're using a data plane that it's capable of giving you all the features and functionality layer two to four that you need for your applications, what's gonna happen is that the traffic between virtual machines will be all local within each server. And because all the features and functionality live within each compute node, as you add more of those compute nodes, your network functionality would just automatically scale out and extend from one server to four to 10 to 50 to 100 and beyond. And the network node doesn't exist anymore. And you're just looking at having kind of a controller which only hosts management and control plane functionality. And it has nothing to do with data plane traffic. So the sizing, the placement changes drastically. And you can look at deploying that controller in a management rack and have higher security around it. You can deploy it as a container, an LXC kind of container within, within the open side controller itself and so on and so forth. So a lot more flexibility and a much better design because you can just automatically scale out your infrastructure by adding more servers into it. All right, now the last point that I want to make and then I'll wrap up quickly, it's around high availability. When you move, and again today I've been concentrating mostly on this software model of delivering networks, which is what Neutron really unleashes and enables. But when you move from consuming networks in hardware to consuming networks in software, the high availability model, it's probably the one that it's the most impacted. All of us are familiar with how you can make a network highly available. Yeah, bunch of links and redundant, if you have a moderate switch, you have redundant supervisors, and if you have a tour, you have dual tours and so on and so forth, nick bonding and a-dee-a-dee-a-dee, right? All things that we very well understand. But what if you move to this software model? When you move to the software model, that's where you start looking at making the control plane and the data plane components are highly available, right? So again, we're not gonna have the time to go through each and every of those, but the idea is that you wanna look at how to have a control plane that it's self-healing and redundant, so that even if something fails, it's gonna be able to come back online and keep all the state. You wanna look at having a data plane that is capable of non-stop forwarding. What I mean is, you chock the head out, data plane still sends packets. If you're using some form of overlay, you always have kind of a translation point from virtual to physical, and that's a concept of a gateway. So how do you make this translation point highly redundant, highly available? And then what if something happens in my open stack controller, in my cloud management system? How am I gonna interact with faders with that layer? So you see that the HA considerations are very, very different when you talk virtual versus physical, right? So this is just kind of a summary of what I just discussed with the ability for the control plane to recover, for the data plane to be independently capable of forwarding packets, and just an overall system that it's capable of recovering from faders. So what next? The open stack networking journey, it's a long journey, and I myself keep learning every day. So I personally spend quite a bit of time, as I mentioned at the beginning, just educating users. And if you haven't, you should go and track the open stack marketplace and the training tab. There is a lot of very interesting trainings there that you can consume. Some for free, some you pay for it, but it's a great resource for anyone that it's starting down the journey of open stack as well as for those that are pretty familiar with it. We personally help users get started just by providing some hands-on environments in the cloud. So if you just wanna learn about open stack networking, come see me and I can help you get one of those going and just play with some of those constructs that we have just discussed, I highly recommend getting your hands on an open stack environment. Theory is great. Hands-on for me is the most important thing ever. And obviously this is my content information and I'm happy to answer any question and continue the dialogue here. I made it with six minutes left. Awesome. So any question, comment? Anybody that wants to share? What was your journey? Getting through the selection process and understanding how to design your open stack network. There's a mic there. Don't be shy. All right. Then thanks for coming.