 Yeah, hi everybody. My name's Carlos. I work for CloudOps out of Montreal, Canada. I do OpenStack deployment support. Who's CloudOps? We deploy clouds, OpenStack, other cloud technologies. You can check us out or come to the Ascendian booth at the marketplace if you want to know more. So let's start talking a little bit about Neutron. Or better yet, let's start by defining what an SDN solution is. So for the sake of this conversation, let's just summarize it and say that an SDN solution is a software that will offer you a Northbound API. It will offer you a way to remotely control or manage your networking devices, be it software or hardware. And we will provide you a way to separate the control plane from your data plane in your network. So that's what Neutron is, a Northbound API plus a database. But Neutron will also give you a reference implementation to provide you a way to translate whatever the intent of your tenant when it comes to networking into an actual configuration that will let packets flow from one endpoint to another. So how does Neutron do this? It does this by using, how does Neutron do the reference implementation by leveraging open source components? Open V-switch, Linux Bridge, DNSMass for DNS or DACP, IP tables for security, Linux namespaces for routing and netting, or proxy ARP, or any function will be implemented using, sorry, open source components that are orchestrated together by Neutron to achieve the flows that you want between your workloads. How does Neutron does this? Basically it has several agents, think the ACP agent, Layer 3 agent, metadata agent, which all receive their commands using RPC solvent protocols. So why would you need to plug something else than Neutron? Well, there are several reasons. Maybe you want better performance than whatever is offered to you by these open source components. Maybe you want further security from whatever is provided you by IP tables, or you want better performance in your Layer 2 switch. Another reason may be maybe you want better analytics than whatever is offered to you in Neutron in combination with Selometer. But I think that one of the most important reasons is because you want to have a common networking software orchestrator, not only for OpenStack, but also for other orchestrators. Maybe you're using Kubernetes. Maybe you have Bermedal. Maybe you have Messos. Maybe you have VMware and you want a common networking for all of those orchestrators. This is what SDN will help you solve. So what other options are out there besides Neutron? So let's start by looking at what OpenStack project has to offer us. Dragonflow, which is a distributed SDN controller. It will implement the OpenStack API, sorry, the Neutron API, but it will do this a little bit different when it comes to whatever is implemented in the underlay to support the flows. What it will do is we will instead a local lightweight SDN controller in each compute node. So no need for a network controller or for components that running a controller. Everything is distributed. So think distributed Layer 3, distributed routing, distributed switching, distributed ACP. Everything is distributed in Dragonflow. As I said, OpenStack project mostly contributed by the Chinese companies Huawei and Wcloud. Next, we have Open Daylight. Open Daylight, very strong community behind the project. Vendor and non-vendor interesting contributors. So the power of Open Daylight, or one of the powers of Open Daylight is that it supports multiple salvoing protocols. So whatever hypervisor you're using, whatever software switch you're using in your hypervisor, or whatever networking hardware you're using in your data center, or even in your one, Open Daylight will provide you with a protocol to orchestrate or remotely manage these devices, software or hardware. So Open Daylight will provide you, ODL will provide you with the ML2 or gluon plugins to plug into your OpenStack. You can learn more about gluon and other talks in the summit. OpenContrail, opens a portion of UniperContrail. So the magic here is in the virtual router. Basically, OpenContrail will let you make service provider type connections up to your hypervisor. So think EVPN for layer two connectivity between your hypervisor or a remote site and a remote site, or maybe layer three connectivity implemented to layer three VPN. OPNFB, not an SDN solution by itself, but will let you do integration testing of different SDN solutions. So basically, OPNFB will provide you, if you're doing NFB and you want to do integration testing of your applications, it will provide you with scenarios that you can test. Think OpenStack with OpenDaylight, or OpenStack with OpenContrail, or OpenStack with no SDN, or maybe Kubernetes. And you have a series of bunch of installers you can use to actually install and run these scenarios. Project Calico, a very interesting approach, supports multiple orchestrators, and it do this by implementing the common language that everybody can talk. Layer three, IP. So how does it do this in OpenStack? You have your ML2 plugin that will push configurations to each CD. This will be picked up by Felix, which is the agent running in the hypervisor or in your bare metal server. And this guy will push security using IP tables or routing, BGP routing using the bird open source software. You can even do BGP route refractors if you want to scale up your data center and whatever you're connecting to Calico. You can even go public cloud this. Big Switch Networks. If you're doing white box, either with Dell or HP, and you want a solution that will orchestrate your physical fabric and make it look like one big switch, this is what Big Switch does. So you have two options. You can either install the agent in the hypervisor, the Switch Lite VX. We will let you offload layer three into the fabric, or you can choose not to install the agent, which is actually just an agent that pushes flows into the kernel, OBS-based kernel. Sorry, into the kernel component of OBS. Or you can choose not to go with the agent. In this case, you will be using the Neutron reference architecture components for layer three. New watch networks, very cool solution. This is what I call the Ferrari as the end solutions because you can support everything. Think VMware, OpenStack, CloudStack, containers, OpenShift, Kubernetes, all the hypervisors. Support for multi-protocol BGP, access control lists, service chaining for layer two, layer four. So very cool solution. Check it out. Analytics based on Hadoop, which is also very interesting. Whatever we have in the provider, we have VMware, you have two options, ESX-V. If you're only doing ESXi hypervisors, and of course, if you're doing VMware integrated OpenStack, this is what makes sense. Of course, you can also use it with other OpenStack, supports other OpenStack releases like Red Hat Director or Mirantis, or you can choose to do NSXT version 1.1 if you're also doing KVM. And not only ESX, Neutron and Mitaka is supported here, and you can also automate using different automation tools. One interesting feature that's in BetaState is that CNI, if you want to plug in another container orchestrator like Kubernetes into NSX. The licensing is interchangeable, so if you start with NSX-V, you can switch to NSXT if you want to or back. And last, we have a couple of solutions from Cisco. One of them is the virtual topology system, VTS. The other one is the ACI. Two very different solutions. The main difference, one is whatever you use for your hypervisor. In VTS, you will be using a virtual topology forwarder or VTF, Cisco-specific software that is accelerated using DPDK and VPP. For ACI, you will use OVS. ACI will basically orchestrate all the flows that go from VMs into your fabric and will let you either have hardware-terminated VTAPs in your Cisco Nexus 9K for ACI. The other difference is that ACI supports Nexus 9K in ACI mode, and VTS will support other lines of Nexus that are not necessarily in ACI mode, maybe in fabric mode. So that's it. Those are the 10 SDN solutions for OpenStack. There are more, but this is what I can give to you in 10 minutes. Thank you.