 I'd like to take a second to introduce myself. My name is Mark McClain. This is Salvatore Orlando. We are both core team members for the Neutron team and have been involved with the project for probably way too long. So what we're going to do as we go through, we're going to go through and kind of give you an overview and kind of take a tour through Neutron, what it is, how it's made up, take a look at what the reference architecture looks like. And so fundamentally, when we first started taking a look at why do we want to create Neutron, we had several things we needed to solve. And one of those things, we needed the ability to create rich topologies. We needed the ability to be technology agnostic. You don't want to be locked into a particular vendor, especially as technology changes over time or as you change and build out data centers differently or maybe stand up new data centers, you want to have the opportunity to reexamine your technology choices, as well as make sure it's extensible. One of the challenges when making any kind of service is that if you want it to be backed by multiple vendors, how do you expose all the different features and short answers you can't, unless you have the ability to extend it. And then lastly, how do we provide advanced services support? So some examples of those would be like load balancing, VPN, firewall. And then we're trying to balance those is whether you're taking a look at some of the challenges in the cloud of how you do high density multi-tenancy. VLANs have trouble scaling. You have a limited number of VLANs. So if you have 5,000 tenants, VLANs aren't necessarily going to be your solution. Also the ability to do on-demand provisioning that you want to be able to move and migrate workloads around the data center, as well as maybe you have legacy applications which are tied to static IPs. So when tackling those challenges, you know, we need to provide different solutions whether it's network virtualization, we can do overlay tunneling with VXLAN, SCT, GRE, as well as use other SDN constructs like OpenFlow, L2 Fabric solution or even question marks. Always include this because you never quite know what the next thing in networking is going to be and so we need to have that ability to leverage it. So the basics of Neutron, what we're taking a look at is primarily if you were to say have your typical user and the font again. So we have our typical user where you have like compute API, the networking API and the storage API. It's traditionally the user's going to see the same API regardless of whether you're back in KVM, the NL2 plugin or maybe it's a proprietary plugin or some other storage technology. And so that's what when we created Neutron, we're gonna provide that same similar generic API that you would find say in Nova that you would find in sender. And so with that, we created several basic abstractions. Neutron really has fundamentally has a very small core of you're going to have a L2 virtual network which is a shared broadcast domain, a layer three subnet and then you have a virtual port which is basically like a port on the switch which you connect into the VIF on the VM. So using the API and these really basic constructs, you can create richer technologies in this case. It's a tenant's created two different isolated segments. So our design goal was we wanted to have like I said earlier, a unified API, a small core mainly keep, we kept the core small so that all implementers and it would cover the broadest range of offerings from the different vendors, a pluggable open architecture so that way you can plug in different vendor different vendor implementations and the players have a choice of which vendors they use, whether they use a proprietary open source and also extensible so the option to have the opportunity to gain access to new features. So when we did that, some of the common features we baked in was we baked in support for overlapping IPs and traditional data center, if you have overlapping IPs, you have problems in terms of routing, you have special routing rules, but to say a use case where you'd want overlapping IPs is maybe you're doing CICD pipelines, you want to have the ability to stand up the application in the exact environment. With this, you can have two tenants can have the exact same address space. As well as the ability for configuration and metadata with DHCP is typical to a fine. Also can we enable support for config drive via the integration with Nova and so that you have those are the common features you'll find across the different plugins. As well as the ability to have floating IPs. So if you have RFC 1918 space, you want to expose different VMs to the public internet, you have the ability to provide and added floated traffic, as well as provide support for security groups whether it's support for over and one of the differences between the neutron implementation of security groups in the Nova and original Nova network one is provided support for overlapping IPs. Also provides the ability to create security rules for ingress and egress of traffic, as well as IPv6 support and support VMs with multiple VIFs so that you can have the ability to apply different security group policies to the VIFs. So do you want to dive into architecture? Yeah, so thanks Mark for this introduction. Now it's up to me to talk about apparently common features, design goals and using the API. Where we supposed to have different slides? Green button. And it's up to me to talk about the architecture. And as you can see, this is the operator view of the OpenStack architecture. As you can see, it's very simple and not confusing at all. Anyway, neutron is that, this is going backwards. Green. Neutron is that little bit on the right side. Still, if we look at it from the high level perspective, it's relatively simple. Still, we really want you to make things difficult for you by using such a small font. So since I don't think anybody can actually read anything in there. 31. So what is neutron? Neutron is just a set of colorful boxes. That's it. And that's pretty much a really accurate description. The only problem is that they're not even colored. It's just black and white. But you, all right. Now, so on a neutron still at a high, at least from a high level perspective, it's a relatively simple system because on one side you have a neutron server which is a REST API server. Which receives API calls directly from tenants or other applications, but also uses the REST API endpoint to communicate with other projects such as NOVA. It has a database, an internet database. And then on the other end, there are the agents which do the data plan slash control plane operations. So there are L-layered two agents which are relatively simple. They pretty much just do created broadcast domains. L-three agents which take care of router forwarding and nothing features. Then DHCP agent, obviously, is quite self-explicative. And then we have several other possibility of binding neutron to several advanced services, namely load balancing, VPN, and firewall. And all these things are connected through a message queue. Then the server runs a plugin. A plugin can be monolithic. Monolithic plugins are mostly two kinds. Either it's either a proxy towards a third-party system like, for instance, an open control or even VMware NSX if you want. And then all can be a direct control. Like the plugin implements the management and the control plane for your network solution, for your network virtualization solution. If you don't want to use a monolithic plugin, there is also the option of using the ML2 plugin called Modular Rear2 plugin, which is still a full plugin implementation. So from the outside, let's say it could be considered as a monolithic full control plugin. But inside, it can run several drivers that allow you to plug different technologies. And this could be either type manager driver or mechanism manager driver. The former are for managing, let's say, transport types like VXLAN or VLAN, GRE or whatever you want. And the other are for attaching mechanism, which could be, let's say, physical controlling physical switches or controlling virtual switches. For instance, the OVS OpenVswitch is a mechanism driver and there are mechanism drivers for a lot of, let's say, third-party solutions. And basically this is just, if you want, an implementation of a strategy pattern that allows us to be very flexible and modular. The ML2 plugin can be also extended. I mean, extensions apply not just to ML2 plugin, but to all plugins. These allow us to extend the API in several ways, either adding completely new resources to the API endpoints or extending the features and capability of existing API resources. So you can have, you can list all the extensions that are available querying that endpoint. We don't have a laser pointer here, but the endpoint is v2 slash extensions. And there are two types of extensions, if you want. One are common extensions that, like, you know, extensions for doing layer three, provider networks for managing quotas or security groups. Some of these, I would say, are so common that are probably not even extension, so they de facto they are part of the core API. And then the other extensions, which are a little bit less used with, like, allowed us to spare extra routes. Some extensions are a little bit more particular because they are served by the so-called service plugins. And this means that these extensions, like metering, are actually not routed to the main plugin, but they're routed to another plugin, which is called a service plugin, which extends the capabilities provided by the neutron plugin that we just seen in the previous slide. And then this is probably the picture that gives the title to the presentation, I guess, Marc. Yes. So it's bridges and tunnels. And, I mean, apparently, Marc went to trip to Budapest and fell in love with Budapest. So it took these pictures, and one is a bridge, the other is a roundabout, and then there is the tunnel. Marc explained the thing to me a little bit, and basically you get into a tunnel, and then you have a roundabout that dispatches traffic, and then you first get into a bridge, then a roundabout that dispatches traffic, and then you end up in a tunnel, which is pretty much what happens to neutron. The only thing that's the traffic is not orderly at all. And so what are the components that allow us to do so? First, there is the layer two agents. The task of the layer two agents is very simple. It's just to creating an isolated broadcast domain. It runs on the hypervisor, and it communicates, obviously, with the server through the message bus, as we've seen before. And basically it's just there, sitting there, and watching when new devices appear on the bridge, and a new device pops up on the bridge, and say, oh, here you are, you're a device. Do you belong to this particular VM? I'm going to wire you to go into the network for that particular VM. And it's pretty much it, it's very simple, and the only thing that it has to do, the layer of this agent, is being extremely scalable and fast and secure, yeah. Also, it has to be secure, and that's why it does not just wire the interface, but it also apply security groups rules and anti-spoofing rules to make sure, you know, that in theory nobody should be able to sniff your traffic. Right, so this is an example for the OVS layer two agent where you have the server, the agent, and OVS itself, which is not yet in the picture, but as well it will appear up here soon. So the neutron server communicates over the message bus with the agent, for instance for notifying of a new security group update, and the agent then talks to OVS using the OVS-DB interface and programs it accordingly. So actually there is also another thing in the picture which is IP tables perhaps. So when you have for instance a security group update where the agent doesn't talk to OVS for programming OVS-DB, but it configures IP tables. Then we have isolation, we have different kinds of isolations which are supported. So you can do VLANs, but as you can say, as you know VLANs have several limitations and when people usually mention that the limitation of VLAN is of the 4K number, actually that's not the real limitation. The real limitation of VLAN is that the underlay and all the bits that you come of the underlay must support continuous VLAN segments and that's not always possible. Then you have other solutions which are based on tunneling which are my preferred solutions. I know that most people don't think they're good solutions but I prefer them. And you can do either GRE or VXLAN where layer two is encapsulated in a higher level protocol. In the case of GRE, for instance, L2 is encapsulated in an L3 IP fragment and it's rootable and you get overlay is independent for the underlay because everything that the underlay has just to provide IP connectivity, nothing else. So as long as you can reach the other endpoint through its IP, so as long as the IP is rootable, you're fine. You can establish a tunnel. And yeah, we're talking about tunneling. So here we have four, these are like four holes and we are going to show how this tunneling works. So here you have a VM-A that wants to communicate with VM-D and so it sends a broadcast message across all tunnels to find where the receiver is. So as you can see, BC, there's no connection in BC to the tunnel because they had a fight a few years ago and they've not talked to each other since then. But the problem here is that when you go to large networks, you get like a lot of broadcasts sent over the various tunnels which is probably not ideal. Imagine if you have not four but a thousand source there. So for this reason, the OVM with which agent implements a mechanism which is called L2 Population. L2 Population allows us to know exactly where the destination host is sitting. In this case, so host A knows where the destination VM, this one, this little red dot here is sitting and so it will send the message only on the appropriate tunnel. And I mean here it would be like one, just one channel employed rather than three tunnels. But in this case, it's not a lot of gain, but just imagine if you had like 100 hosts here instead of just four hosts. So the last bit is the, I'll talk about you, are the L3 agents. The L3 agents don't run on the hypervisor, they run on the dedicated network node and their task is obviously all that forwarding traffic and layer three. They do traffic forwarding for east-west and traffic forwarding for north-south traffic. They use IP name spaces. They use IP name spaces and they have, if you enable it, they allow communication with the Nova Metadata Server through the Metadata Agent if you enable them. So this remote is not working anymore. So it's implemented as we said, using IP name spaces and the concept of IP name space is fairly simple. So you have the main host, let's say the main name space, which is the host name space, which is hosting the integration bridge, the open-b-switch integration bridge. And the various isolated name spaces where you have, let's say, a different name space for each different neutron virtual router are then all connected to this integration bridge. But they all have like the same full networking stack. So you have each name space as different network interfaces, as different IP tables, different root tables, and they don't interfere each other. So for instance, you can achieve, this is what allows you to achieve overlapping IPs, for instance, because you can have the same IP address, configured multiple times in different IP name spaces. And then these name spaces are bridged to the main integration bridge to provide the connectivity to outside the host. So basically, this is our, I mean, very high level, how the L3 agent is implemented, and yeah. And then we move to advanced services. I'm sorry, we don't have time in this talk to talk about all the advanced services that we have. We just mentioned a bit the load balancing service because it's undergoing like major refurbishment. And the load balancing service is one of those service plugins that I previously mentioned. So at the management layer is a service plugin, and then at the control plane layer, it's implemented with an agent and a driver. The agent communicates over RPC with a driver which is running as a part of the plugin. And you can have, it's I think in the Neutron Source 3, you have an implementation which is entirely based on HA proxy, but you can also leverage several third party drivers which are like available as remote systems that the load balancing plugin can configure. So this is, I hope that I managed to do my job of confusing you and giving you a bad headache. So I think it's all for me and I'll hand it over to Mark to finish giving you that by PowerPoint. So we wanna take a look at what's new in Juno. So one of the biggest changes in Juno is we've finished our work in enabling IPv6 support. It is the future, it's here. So we have a couple basics. What we've added is we've added router advertisement support into the network nodes. We've also supplied with a couple different algorithms. We've called them either Slack or the default algorithm is some people refer to as sequential. Essentially it's the same algorithm that you would find in our V4 IPam today which is just keeps assigning the lowest number to a pool exhaust and compacts the pool and recycles. As well as one of the things when you're doing an IPv6 network you wanna make sure that you secure RA announcements because the last thing you want is for a VM to come up and start hijacking all your traffic. So we take a look at some of the different ways we do it. With IPv6 Slack basically this configuration is where you enable RA auto configuration. You have a delegated prefix for the tenants network and the IP address is generated using a EUI 64 or basically on a MAC address. It's a well-known algorithm for generating the addresses. Nice thing about this is that as you generate MAC addresses for your VMs or even hardware in the cloud the addresses are, you don't have to go through the in terms of detecting for collisions because the IPv6 protocol will do it for you. You do not run, we don't run DHCP in this situation. In some cases though Slack doesn't give you the ability to pass enough options to the host. So some people want to refer to what we call which is we refer to as DHCP v6 stateless. In this case you have essentially the same configuration as you did before with Slack but you have the ability to, we stand up a DHCP v6 server and you can pass the options which are not available via the router advertisement. And then the last mode is you can actually run DHCP v6 stateful. It's basically very similar to how we do IPv4 today. It's full DHCP services, you can configure options for those. And so as the VMs boot, it can request any of the options as needed. In this case we use RADVD on the router and we use DNSMAS to provide DHCP services. One of the things that comes up is should I run IPv6 if I'm building out a new data center should I run it today in a dual stack or single stack? So if you're standing up a green filled deployment which you know you're going full v6. If you, for dual stack, nice thing about that is your applications have the ability to address both v4 and v6. The support, this will be supported by the latest long-term support releases almost all the operating systems. When you do single stack v6, it gets a little bit more interesting because one of the problems you have is that if your application requires that the open stack metadata service works, CloudNet only makes v4 requests to the metadata service. So one of those things is in order to work around that you have to have config drive enabled in your deployment. Generally config drive will give you more stability but the reason I put the star beside it is you have to have an operating system image that's configured to use config drive. If you have a CloudNet based operating system image this will work but if you're using a different operating system not based on CloudNet you have to write the scripts necessary to read the config drive information. Another big change we made is into distributed virtual routing. So as Salvador talked a little bit before we have a typical architecture where you see the core, you have a network node, you have VMs and hypervisors. All the L3 services are on a network node or a collection of network nodes. We use namespaces but what happens if you have a really noisy hypervisor? So our hypervisor starts, it starts generating lots of traffic, eventually we could saturate our network node to the point that we've now saturated our core link and so now all of our traffic and data centers not only going through a single point of failure but we've also saturated the link. What if we had an option to actually route directly from that hypervisor into our core without having to go through the network node without having to process the NAT traffic in the network node and do it directly on the hypervisor? Essentially this is how DVR works. So we take a look at it, typically three-step process if you're a deployer for rolling out DVR is you want to install it, you're going to enable an agent that runs on each hypervisor so we're now running both an L2 agent and a DVR L3 agent on each hypervisor. You're going to associate a floating IP with the address, profit, right? Actually really in reality you're going to get all North-South traffic is going to be added directly from the hypervisor and skip the network node. So going back to it, so that fixes North-South traffic but what about East-West traffic? So if we have two instances running and it wants to talk, the East-West will typically traverse the network node when you have DVR enabled we can actually talk directly hypervisor or hypervisor because we can directly tunnel using L2 population. With North-South if you don't have a floating IP so the key component for getting full North-South bandwidth is having a floating IP. So if you don't have a floating IP it's going to go out through the network node if you do have a floating IP it's going to go around the network node. One of the other improvements we have is we've improved security groups tremendously in Juno. Salve and I were talking over lunch and that the efficiencies of implementation have made in terms of security groups have actually made it easier to boot. One of the things we changed is we started using IP sets. So kind of like if you looked at Ponto Musee where you have lots of locks on it if you know they put so many locks on the bridge panels started falling off. Same thing with IP tables if you put too many rules in there IP tables becomes very slow. It starts breaking down in some cases. So with IP sets we can actually speed up their ability to process security group rules by aggregator. Last thing is we provided L3HA. So now when you have a network node we can actually run them in pairs. Using connection tracking we can share states and so if a network node were to die the other network node would take over and basically seamlessly transition your traffic. And kind of opening up and looking on the horizon for looking ahead into Kilo. Some of the things the team is going to be working on over the next cycle is paying down our technical debt. Neutron being a project. It's been around for three and a half years, right? Yeah, three and a half years. So three and a half years and so as we've grown we made some choices that over the time that were good at the time but as we've grown the project and as we've learned it's time to go through and revisit some of those choices. So we're gonna pay down some of that debt and we're gonna take a look at some of the initial choices we made. We're also going to continue work on IPv6. One of the abilities we need is the ability to prefix delegation. So if you have a large public address block which you don't want as you won't, you don't want tenant self selecting what their prefix they're going to use for their network. So make that configurable by the deployer as well as improve our IPAM service. Our IPAM service was something we initially made very simple always said we'd come back and revisit and now we're coming back to finally revisit it. Another one is facilitate dynamic routing. As Salvatore said Neutron does very static routing what we want to have the ability to do is to speak BGP so that within the data center fabric you can express the routes that are available and the locations within your deployment as well as enabling NFV applications. The NFV sub team which is kind of cuts across several disciplines and several projects within the open stack community. We have to go through and make a few enhancements to make their job easier. So in summary Neutron really is about a small unified API has a small core essentially we have three main resources. We have several extended resources as Salvatore said and many of them are common that you find in almost every implementation. Plugable open architecture that has multi-vendor support. So if you take a look you'll see many well-known names on the slide and it's extensible so that as a vendor or as the open source community dreams up a new feature we have the ability to export that and make that available to deployers who choose to deploy it. And then lastly for more information the cloud administrator guides available as well as the V2 API. So with that thanks for listening. Does anybody have any questions for us? I think there are a microphone there. Nova has availability zones and Neutron have no idea about them. When instance start it's router go to random network node and there is no way to group compute and networking to single availability zone. I saw something about agent scheduling in new versions but will that scheduling supports for some kind of separation of faults in OpenStack? Thanks. Currently right now it's come up only briefly but as far as real community drive for implementing availability zones in Neutron that's not something that's bubbled up too high. Yeah I do agree with the point that you wanna have the ability to at least ensure that your network node and your VMs are spread out. One of the things that you could possibly do is with the at least with network nodes and high availability you can and this would be future work on the high availability schedule or the ability to put the instances of the network nodes into different availability zones that you would have increase your uptime. But mainly I don't anticipate we'll get to that in Kilo that's probably an LM in kind of thing. But there is no way to say where the pair of Neutron nodes with DVR gonna be. So with DVR the actual L3 routing if you have a floating IP it actually occurs directly on the hypervisor and it's routed directly from the hypervisor into your core if you're doing just normal source NAT traffic it's gonna go through the node pair. Right now they're just assigned based on a space available basis without any kind of recognition of where the VMs are ensuring that the pairs are in different AZs right now. Mainly because Neutrons is not AZ aware. Okay thank you. What's the timeline for IPv6 translation private to global address or look at a global address? Post Neutron, I mean post K as well. So actually doing IPv6 NAT? Yeah. Yes. Fundamentally most of the folks who have been working in IPv6 team that all their use cases were actually publicly routable IPv6 addresses. I do recognize that some folks like the ability to renumber networks. If you're doing prefix delegation with Slack it makes that pain a lot less but as far as doing IPv6 NAT it leased L possibly K. Mainly we have to have developers who want to do it. Yep. I had a couple of questions. You said when we have DVR the traffic is bridged directly from hypervisor to the core. So if I'm running a firewall in the network node how does it work? So if you have an edge based firewall how does it work? So the firewall as a service is an experimental service available in Neutron. It's an API which we exported. The DVR team worked to ensure that the edge firewall rules were actually pushed down into the hypervisor into the L3 routing namespace. So effectively you get the same logical edge firewall that you're getting. It's just that the rules are applied much closer to the VM. So yeah, there is a presentation later on today that actually dives even deeper into DVR. So right after. And so we have one more. So currently there's only edge based firewall. Is there a plan to have a three tier architecture web tier, app tier, and DB? Is there a plan where I can insert different firewalls at layers? So the question is is there a plan to do service insertion of firewalls essentially? That topic has come up frequently. Mainly initially we started with an edge based firewall to prove out the API and to harden implementation. Until we get the edge based firewall done, I don't anticipate the team's gonna move on to the ability to insert firewalls. In the interim though, you do have the ability to apply security groups onto any port which covers some of that use case, but not completely all of it. I know some folks want to be able to apply firewalls between networks and whatnot. One more question? Thank you all for your time. Thank you guys.