 We are up. All right. Hey, thanks folks. My name is Phil Robb I'm the senior director of technical operations for open daylight and I'm going to be talking to you about open daylight and collaborating with OpenStack For those who don't know or haven't heard of open daylight We are an SDN controller an open-source project. That's part of the Linux Foundation As an SDN controller, we really want it to be a common platform with a common set of code Building a strong community so that we could have an industry-wide Collaboration in the networking industry doing software-defined networking To that extent from a membership standpoint you can see from this slide that we've got pretty much most of the networking as well as Computer manufacturers as part of our collaborative We've also started to get end users such as AT&T and Comcast. We've been around for three years We launched in April of 2013 We're now to the point where again, we've got end users who are actually putting these things into production To the extent that we've got these different organizations that actually have products and services built on open daylight That are in production today In a nutshell open daylight has about 32,000 commits Two and a half million lines of code more than 700 developers at this point It's been around for again a while. So we're we're getting to the point of being mature and in production As well as if you do a Kokomo study on the code base, it's looking like about 764 man years of effort There's been a lot of activity in the networking Open-source area over the last five years or so Open daylight is by most different measures the largest. So we have a very healthy community Very active again not too dissimilar from OpenStack Around a hundred and fifty known commercial deployments from 20 different companies And that spans software equipment vendors service providers networking entertainment energy management in actual deployments We do a survey every year and we just had our summit about a month ago At the end of September in Seattle and part of that survey we we ask, you know, where are things being deployed by our users? And we're pretty well split between North America Europe and Asia With regard to where open daylight is being deployed. We also ask our users what they're using it for And around 20% it's it's in new service creation 27% in managing and monitoring their networks 26% and actually doing traffic engineering and about a third or 28% in NFV and cloud In recent years last couple of years the real intersection between open daylight and open stack has come strongly in the network function virtualization space If you were in the keynotes this morning you saw Ildeca talk about What they've been doing with with Network function virtualization and the open platform for network function virtualization or opnfv That's also where open daylight sees its largest intersection with open stack currently So why do you care as an open stack or why does it really matter? If you've got open daylight and the biggest thing is just with the size of the deployments that we're seeing You know, we heard from China mobile with their 10,000 instances As they they got the super user award this morning, but the networks are just getting hugely complex So being able to automate being able to tell an external device Make my network do X for me and not have to worry about it further is really what we're trying to get to and that's really the job of the Controller alright, so as we continue to build out these more complex environments more automation Everybody knows is needed more analytics is needed so that you can actually feed the the orchestration layer So that everything can just be happening in an autonomous way That's what open daylight is providing to open stack And if we look at it from a layered perspective, you know, you've got your your platform as a service Software as a service up at a layer. You've got the infrastructure and from a networking standpoint We're talking about network management network orchestration the actual controller being able to do analytics on that network And then at the bottom you've got the actual physical devices Right so being able to have the applications Just tell from an intent standpoint or a policy standpoint I need this instantiated in my network and have that actually done through an orchestration layer to the network Collect analytics off the network so that you can intelligently tell those applications again Then how to manage and orchestrate and evolve that networks Composite form, you know over time that's really what we're trying to get to here So the stack manages itself Again lots of activity in the open source networking space over the last few years This is a slide that actually comes from the folks at the open platform for network function virtualization project or OP NFV and It does a good job of just laying out now the options right that are available from an application layer things like cloud foundry other platform as a service platforms Again analytics a project recently started called Panda specifically to do large-scale analytics on your network Orchestration has seen a lot of activity in the last month or in the last year rather with Open-source Mano open. Oh AT&T has announced that they're open sourcing e-comp That's supposed to come out in open source somewhere in early 2017 from an orchestration standpoint again from the virtual information management Platform space open stack is by far the the significant player there Network control again open daylight. There's also onos that focuses on open flow specifically open contrail focusing more on MPLS Linux dominates the operating system OBS DPDK FD IO as as Items that are actually down in the data plane Hardware specifically with open compute and then opnfv is really to try to put all of this together Create an installation environment and a test environment So We look at it like you've got a variety of different views different ways that you need to look at your network Right and at the at the top. There's really just the application view, right? I got one application that needs to talk to another I want to talk to my platform as a service router and not have to worry about anything else Right policy is an important piece of network management as well making sure that you've got users that are separated You've got equipment that's separated you got different quality of service for different types of flows that you've got being able to manage that in a policy Format and being able to view it from that perspective is important the service view right so you've got Different endpoints that are sitting on different lands that are connected through different wands through different data centers You want to be able to see actually end-to-end what that looks like and that sits on top of a virtual topology Usually in in our virtual environments such as OpenStack right so there's a virtual network that sits on top of the physical network and What makes up that physical network, but the actual elements right so you need to be able to understand those resources as well Compute memory storage are pretty common Bandwidth is also just as important. It's very influential on how your application is going to perform right so better network management And visual be able to see that is really important So being able to spin up those compute and those storage nodes without knowing how to connect them intelligently is a big problem So again kind of going back to the NFV Use case and what we're seeing you know OpenStack is really good with Neutron to be able to show the tenant facing side of What your networking looks like right being able to see the physical environment tie it to policy tie it to service And tie it to the actual physical network is what Open Daylight's there to help with So for virtualization for multi-tenancy again network function virtualization telco services like service function chaining in particular These are all important again as well as as well as policy and intent We've got different use cases from AT&T China mobile orange as well as the Massachusetts open cloud as examples of this So again the most important benefit from Open Daylight to OpenStack is that you can see things end to end Within the data center across data centers across the WAN the virtual environment and the physical Infrastructure sitting underneath that We're built in a very modular way to support many different types of protocols We support many of the existing legacy protocols as well as the popular SDN protocols such as open flow And we're constructed to be able to support the new ones that are coming out as they come out Being able to actually do the network monitoring collecting the statistics Logging those off so that they can be looked at from some analytics engine or reacted to in real time Is another key feature of the of the controller and we're built to integrate with those higher-level orchestrators And you're seeing again in the NFV world Open O is specifically targeting being able to orchestrate virtual Machines that it's spinning up as well as the connections and the service function chains that are created between them So this is just an example stack one of many that Open Daylight can perform But this is focused on open flow and OBS DB Inside of OpenStack Neutron. We have an ml2 driver as well as networking ODL as a layer 3 plug-in for doing Load balance is a service firewall as a service VPN as a service and so forth in Open Daylight We have a module called Neutron northbound because we have a variety of services that are potential that are that are available To be used for OpenStack's purposes And so we wanted to create a common interface to OpenStack within Open Daylight And then you plug into Open Daylight whatever of those services you're looking for such as OBS DB netvert group-based policy virtual tenant networking List flowmapper or the network intent composition project From a southbound protocol in this example. We're using open flow OBS DB and net cough Another example is fast data stacks. This is actually a project within OPNFD Again Neutron and OpenStack at the top talking through Neutron northbound to the policy engine One of the policy engines inside of Open Daylight called group-based policy that then talks to the virtual packet processing renderer That talks through an interface that's net cough and yang to honeycomb agent sitting inside of FDIO And this is how you're actually managing Things that are built out of FDIO be it a middle box type of renderer or be it a switch itself and then OPNFV has projects to both install with Apex as well as to test with Funk test and yardstick that particular stack configuration For more information on fast data stacks again that link down to the left and I'll provide these slides later So if you want to go look at the architecture from the OPNFV site What makes Open Daylight different? When we started working on controllers and when SDN was brand new it was it was often thought of in layers, right? You had applications and you had a core controller and then you had network elements And that's really how we kind of started constructing our application We had an application We had a service abstraction layer that could then talk to Protocol plug-ins so that you could have an application talk to different protocols depending on what your equipment was Right, but that ended up being really complex It was hard to add new applications. It was hard to add new protocols So we changed and went with a model-driven approach So now what we do is we actually have you model what service or protocol you're going to implement in a model That we use Yang for our modeling So you build a Yang model and then run it through a set of tools we call Yang tools and outcome is a set of API's That are auto-generated that then you write code behind to implement your service And so if you're an application You write this model Generate this tool if you're a protocol you write a model run it through Yang tools and generate the API for that Then an application talks through that API To either an application or to the protocol so it doesn't really matter If it's a protocol or if it's an application or a service the interface is really the same right and the common glue between them Is this Yang representation right and we have that in both a common data store That all of the applications can access and as well as through message bus through RPC through notifications and so forth And then we cluster that so that you've got one logical instance That's actually spread across multiple physical instances for high availability and for scalability So you've got then producers of data and consumers of data And those can be either internal applications or services within the controller or external So they can be applications talking to the controller through a rest interface or obviously they can be Network elements talking to the controller through a protocol plug-in Right, and it doesn't really matter Where it is in internal to the controller or external the information is shared the same we We list our um our projects or we we release our project Down the periodic table. So we started with hydrogen then went to helium our most recent release in February was called beryllium and It in particular had support for open-stack full ha and clustering as well as Improved security for hardware v-tep using open flow as opposed to just IP tables Also in that release we had open-stack BGP VPN support for the first time and then our most recent release is boron all right and boron came out about six weeks ago And in it we continue as always to work on better scaling and better performance better ha and clustering We continue to evolve the ml2 driver Within open-stack And we worked on a project to really do application agnostic composition Pipelining so we run into an environment in an SDN controller particularly when using open flow Where it's easy for an application one application to step on what another application is doing send two different flows to a switch and Totally confuse the network right so having some way for applications to uniformly Work with each other to know that they're not stepping on each other was something we recognized We needed to do with an open daylight and we'll end up doing this in a couple of different layers We will most likely do this also in the in an intent layer as well So again just priding provide an application providing intent to the controller and the controller Then figuring out how to properly manage that pipeline When not using intent we still needed another another way of doing that And so we used a project called genius was created for boron and it provides that interface And we have examples where particularly with service function chaining where we want different services To be able to know and work with each other so they're passing things off And and again interfacing with the switch, but they want to do it in a synergistic way as opposed to a mutually exclusive way And genius provides that for them as well We started a project called net vert that's actually a spin out from the ovsdb project Really focused again on providing network virtualization services to open stack And then a new project was started called yang ide And this was actually brought by folks from atnt If you've studied atnt in their domain to activity They're really focused on yang as a modeling language that they want to use for a lot of different things in their network Environment and so they wanted to be able to have a tool that would actually build yang models and put it into a Clips and so that's actually what yang ide is It's a tool to build yang models syntactically check them visually Be able to represent what that yang model so that it's easy to see Put it into a clips and since open daylight is probably one of the largest applications using yang today That's where they decided to house it was within open daylight With boron also we had another southbound protocol plugin called ocp that was added And it's done for controlling and managing radio remote radio head equipment And then cardinal is another interesting project that was done And it It actually allows open daylight to be monitored and managed from traditional network management systems So it has a set of snmp mibs as well as and will also generate traps To talk to a network management system Providing all the information that open daylight can see to all of the different network elements that it's actually managing So we have a project within open daylight called time series data repository or tsdr As well as sentinel that's specifically looking at that type of data for streaming workloads And information from both of those projects actually feed through Cardinal to a network management system as well. So to integrate with your existing network management system To get started come to opendaylight.org Another big thing that we did that was sorely needed in our project Not too uncommon to to open stackers as well was our documentation was pretty horrid We made a very large step in this latest release all of our documentation is now part of read the docs It's it's uniform. It's it's cleaned up much nicely And because we just had our summit We record everything in our summits as well so we've got Just hours and hours of recordings on our youtube channel open daylight Project on youtube Again, these are all now only four weeks old. So now's the time to go take a look at them There's many different sessions that are on open stack and open daylight integration I strongly encourage you to go there to take a look As well as full day tutorials on how to do integration of open stack and open daylight at a very low level So lots of hands on and lots of good recorded material there for you Again, open the open daylight.org slash start to get started and with that I I greatly appreciate your attention. Thanks everybody