 Alright, very good. Welcome folks. This talk is about Open Daylight, specifically collaborating with Open Daylight for network-enabled clouds. My name is Phil Robb. I'm the technical director of operations for Open Daylight. I'm going to talk first a little bit about what Open Daylight is. So this is a slide of the architecture for our current release. I'll go more into detail on it later. But what I really want to just show you here is that as an SDN controller, this is really an application that has a northbound interface, a variety of services for managing your network, a core set of infrastructure so that those services can talk to one another as well as talk to some southbound protocols to manage your network, and then along the bottom are the variety of different southbound protocols that we currently support inside of Open Daylight. From an OpenStack perspective, it's really about an ML2 plugin driver, mechanism driver, and then we've also added a layer three, a layer three plugin to do things like Elbas and Firewall as a service and VPN as a service. That talks to a component inside of Open Daylight called the Neutron Northbound. For us, that is a set of common interface, it's a common interface to OpenStack because we have a variety of services that want to perform different activities for OpenStack, but we wanted to present a common interface for OpenStack. So our Neutron Northbound project within Open Daylight actually provides that for OpenStack. Some of those services are group-based policy, NetVert, which provides again things like the Elbas as a service, policy management, VTN for doing virtual tenant networking, as well as List Blow Mapper and Network Intent Composition, or NIC, as another project to implement intent or a nice abstraction far above layer two and layer three for OpenStack to talk to. Yeah, I don't know where I went. Yeah, okay. Okay, for anybody who presents here later, there are two high buttons that go forward and back. Don't press the one underneath that because this is what happens. Okay. There we go. All righty. Sorry about that. Operator error. So what is Open Daylight trying to do? Open Daylight is really trying to bring the industry together around software-defined networking and making your networks more programmable. All right, very similar to OpenStack and what's happening here in the cloud industry. We're really trying to bring everybody in the industry, users, vendors, whoever who's interested in actually being able to do that, really turn your network into something that is very programmatic to bring them together. So, and we're succeeding. We're doing very well. The project's been around since April of 2013, so we're just now hitting our third year. We have broad industry support both from a user as well as a vendor standpoint. This also shows the number of products that are actually out there, so folks actually delivering Open Daylight in commercial environments. So, again, for a project that's been around for three years, we're very happy with the momentum that we've continued to get as we're bringing out more and more features from more and more organizations across the industry. One of the things that's different about Open Daylight versus other controllers is normally when folks talk about SDN and SDN controllers, they're specifically talking about OpenFlow. OpenFlow is a great protocol. It does a lot of wonderful things, but it's not the only protocol out there and certainly for legacy devices that don't talk OpenFlow, if you want to try to manage and see your network end to end, as well as try to put some level of programmatic interface to it, you got to do something more than OpenFlow. So, our design was specifically built to be very, very modular, to allow new services to come in as well as to allow new protocols to come in. So, as we started to develop this, we kind of did this in a layered format, right? So, we had applications, we had a central set of service abstractions, okay, or service abstraction layer, and then we had a set of protocols down at the bottom, right? So, a typical application would work through that common core down into the protocol, and that's how we'd get the services to talk to the protocols. What we ended up realizing, though, was that it didn't really matter if it was a protocol or it was a service. These are all services to one another. You have things that are producers and you have things that are consumers, right? And so, we decided to create a model-driven architecture. So, using the modeling language Yang, we actually have a Yang model that will generate APIs for your services or protocols, and that provides the interface for any other service or protocol to interact with yours. All right? So, again, it doesn't matter if you're a protocol, it doesn't matter if you're an application or a service, you end up talking through the API generated through a set of Yang tools that we have that generate these APIs for you, make sure everything is done properly throughout the entire system. A lot of, you know, no manual activity, so it happens much more consistently. So, in the end, then it doesn't really matter if you're a protocol or if you're an application, right? You're really a producer or a consumer, right? And, again, you talk through a representation of Yang and there's a data store, has two sides to it. There's a configuration data store that is what an application wants the network to look like, and then there's an operational data store, which is what the network actually looks like, right? From pulling from the network devices. As well, there's somewhat of a messaging bus that provides RBC and notification functionality. So, as an example, then, again, you can have a consumer that is an application, in this case, something like OpenStack would talk RESTConf down into the Open Daylight controller. It could then pull information from a producer app and the producer can provide information to other services inside of Open Daylight or to applications that are outside of Open Daylight. Similar, the providers of information can be network devices working through a protocol. They can be through NetConf, again, and they can be consumed by services inside of Open Daylight or they can be consumed by applications that are above Open Daylight, such as OpenStack. So, as a fuller example, OpenVSwitch uses OpenFlow as its language of choice for protocol implementation. In this particular slide, you can consider apps to be OpenStack. You could consider OBS to be the OpenFlow switch. OpenStack then talks through RESTConf, tells the controller what it wants to impact on the network. That goes into the configuration data store. That causes a notification to happen to the forwarding rules manager, which then goes and tells the OpenFlow plug-in that something has to happen out on the network. A flow is pushed out onto the network. Information is brought back from that switch that received that information. Then, from that, from the switch coming back in, the OpenFlow inventory operational data store is updated. That also updates the forwarding rules manager, as well as the topology manager, so that OpenDaylight has the full view of both what was attempted in the network as well as what actually happened in the network. So, why should anybody at OpenStack really care about an SDN controller? Simply put, the ability to spin up a compute and a storage node at will is pointless if they can't be connected intelligently. It's been a really exciting year for OpenDaylight. We continue to get more and more real deployments, real users coming to work with OpenDaylight. From an OpenStack standpoint, this is what we hear from those that are using it in an OpenStack environment. And it's really about, you know, Neutron is really good at identifying and helping tenant-facing type applications work through their networking and virtual networking in particular connections, right? But things like network function virtualization in particular require new functionality and they require something of an understanding of the network that goes deeper than just the overlay, right? And these are some of the use cases that have been identified and these are some of the organizations, the end users that have been picking up OpenDaylight very often in an NFB situation. So, advantages of using an SDN controller in OpenDaylight in an OpenStack environment. Number one, it's that OpenDaylight can see everything end to end, right? And that includes not only the virtual network, but also the physical network underneath. Going through the data center, through the campus, across Metro, across whatever your long haul van is, right? The ability to manage those connections and the virtual overlay that sits on top of that is really essential when you're trying to be a cloud operator. When you're trying to run this, you've got data centers all over the world. You've got expensive connections that are going between them. Everything from the traffic patterns to the costs change on a variable basis, right? Having a device that actually can monitor and sense what's going on inside your network and react to that and react not only to the virtual connections, but the physical connections underneath. That's the reasons why you want an SDN solution. So, and again, if you ever look, and for those that have become familiar with NFV, I remember being at this conference about three summits ago and the term NFV wasn't really known to anybody, right? And so the telcos and the open stackers have been getting together over the last 18 months. And if you've done that, then I expect you've learned an entire new vocabulary of acronyms you never knew existed before. So, you know, you can think of an SDN controller and open daylight as us worrying about the network so you don't have to, right? Is really what it's about. And then there's always going to be higher level integrations necessary with other types of orchestrators, right? That sit above the infrastructure as a service, they sit above the network and they're managing applications, they're managing a whole variety of things and they need to talk to both the network in a very detailed manner as well as to open stack in the virtual environment. These are reasons why decoupling those two activities is a really good thing. So, we did a user survey in February and I just wanted to put this slide up to talk about, again, so about a third of the use cases for our controller are really quite directly tied to open stack, right? And if, again, you talk about doing things like traffic engineering tied to the cloud's needs as well as, you know, monitoring and maintenance for the cloud's needs, they actually all tie in. So, now I want to step back and talk a little bit more deeply about the current version of open daylight that we're on. So, the items that are in the yellow are actually new to this latest release. Again, we constantly are having new services brought on as well as new protocols while at the same time we're actually working very hard to continue to make it more production quality, more robust, more scalable, more performant and so forth. And this current release is no exception. Specifically, again, for open stack, the new features in the beryllium release. We've been going through an evolution with our Neutron API that will continue for several more iterations, both of open daylight and of open stack. There's a very good presentation that will be on that tomorrow and I'll give details on that a little bit later. For this release, we got full HA and full clustering top to bottom from open stack and everything that open stack is doing above Neutron, through Neutron, through all of open daylight, through the southbound protocol and open flow, tested very well. That was where we spent a lot of time making sure we could do end-to-end clustering and so that either went down, they came up, they actually resinked, everything worked as it's supposed to. So that was an important thing for us. Another activity we did was really work on security, in particular doing hardware VTEP as well as security groups implemented in open flow as opposed to just through IP tables. So it's a more efficient way of doing it. And then also supported the whole BGP VPN activity that was going on inside of open stack to make those VPNs through BGP actually implemented through the open daylight controller. So Boron is our next release. If you haven't figured out our names yet, we're walking down the periodic table. So you get a science lesson if you come work with open daylight. So please join us. Again, we will continue to work on scaling, performance, and again evolving this, our ML2 driver, as well as continued work on things like group-based policies, service function chaining, VPNing in particular. And then we've got a variety of new features, too many to actually list here then. So I only pulled the ones out that I thought might be interesting to this to this group. Energy management, so actually being able to manage the state of your networking devices based on the power consumption you want or need your network to manage, is one of the protocol features that's coming in to open daylight in Boron. OCP, the ability to actually manage remote radio head units in wireless networks, is coming on as well. Yang IDE, is that coming out? No, it looks much better on yours than mine. Yang IDE, so if you've heard me say Yang a lot, Yang is a very robust modeling language and for those that are very much beginning with it, it can be somewhat of a pain. One of our community members decided to write a nice IDE that plugs into Eclipse, does a really good job of laying out the structure for you, helping you actually identify errors and so forth. So if you're new to Yang, come look at the Yang IDE project, it will help you in your learning curve. Again, we've also done Kafka, as a Kafka producer, so if you've got Kafka consumers, you can now tie them into open daylight. Cardinal is actually a project to tie into orchestration and network management systems. EPC for doing Evolve Packet Core, so extending OpenFlow with their extensions for managing Evolve Packet Core and a project to basically do JSON RPCs to different applications. So what to see here in Austin? While you're here, again, yeah, take a picture of this one. Because this open stack and open daylight, that will give you the current state of the technology between the two projects and what they're doing. Again, we've got an evolution going on until, well, through Neutron and IndoAktava, as well as through Boron into Carbon for our side. And then for higher level discussions on NFV and SDN, that middle presentation on Among the Cloud. And then finally, talking about NFV and how NFV can actually be applicable, at least some of the technologies can be applicable, into your classic data center. That's also being talked about as that third one. So getting started with open daylight. So again, obviously come to our website, download it. We have an advisory group and if you're a user and you're interested in open daylight and you're playing with it now and you're looking to deploy it or have deployed it and want to be part of this group, the advisory group is quite active and it's been quite helpful to the technical community for us. The technical community asks them questions when we're coming up upon a design decision that we, you know, find, obviously, it will have a user impact, right? Our current group of advisors is very impactful to our community. And so if you are a user and you are interested in working with open daylight or RDR, I encourage you to come see us and we'll work through that with you. We do have a booth here, so it's over at C14. So come please join us there. We have demos that are going on throughout the week as well in the booth and we've got a listing of what's being shown. So you're welcome to see that as well. And then again, just come to our website and pull down the code and start playing. With that, I thank you for your attention.