 Welcome, folks. Can everybody hear me okay? Seems to be working all right. My apologies for the minor technical difficulties here as we get started. This is a panel presentation on OpenStack and Open Daylight developer panel. My name is Phil Robb. I'm the Director of Networking Solutions for the Linux Foundation and what that means really is that I spend my day job working to help facilitate the technical community around Open Daylight as well as some of the non-profit activities as well. I'm going to go ahead and let the panelists here introduce themselves and then we'll start with some questions. Okay, Mr. Price, you want to go ahead and start? Sure. So my name is Chris Price. I'm on the Open Daylight Technical Steering Committee, a committer on a couple of projects and a member of the OPNFV Technical Steering Committee as well and heavily invested in getting everything working with OpenStack. I'm Kurt Beckman. I'm Brocade's EMEA CTO and I work very closely with OpenFlow but also in projects that bridge between OpenFlow and OpenDaylight and I care a lot about OpenStack even though I'm a little bit distant from it. Dave Lenro from HP also on the technical steering committees of OpenDaylight and OPNFV and working the ONF and trying to figure out how it all fits into OpenStack. My name is Chris Wright. I work for Red Hat. I'm the Chief Technologist there and I've been involved in the OpenStack community for a few years, primarily focused around Neutron and then with OpenDaylight since the beginning as a board member and technical steering committee member. So I'm interested in talking with you about how we can work together as two communities. Very good. And we'll run this panel so very interrupt driven. If you have questions, feel free to come up to the mic at any point. I'm going to go ahead and start off with seating our panelists with some questions and then again at some point I'll turn over and specifically solicit questions from you but if you hear something that you want to kind of draw on, feel free to raise your hand, come up to the mic and we'll continue a discussion on any topic. With that, Chris Price. So there are a lot of third party plugins in Neutron. What makes OpenDaylight so special? And worth consideration by the OpenStack community as an SDN controller platform? Okay. So OpenDaylight is not built for Neutron. It wasn't intended to fulfill the role of this is going to plug into OpenStack as a Neutron plugin. It's built as a general purpose SDN solution. It's a platform for various types and styles of SDN types of technologies. Additionally, it plugs into Neutron. So you can use it as your data center Neutron plugin for networking. At the same time, you can solve other problems in the network using the SDN capabilities of the OpenDaylight platform. What makes us unique now? We have a really thriving community. We have a lot of invested people. I think the architecture of Open Daylight is also very interesting. We don't have essentially vendor plugins so to speak. We have technology plugins. We have a southbound and then we have an abstraction layer and then we have functionality. And if a vendor wants to solve a problem, they can do so. And they're going to do so in the context of the technologies that we solve in the platform rather than as a separate project or as a pluggable project. And we accommodate vendor extensions, of course, but the architecture of OpenDaylight is very neutral in that context. I don't know if anyone else wants to chime in. One thing, in case it wasn't abundantly clear, it's an open source SDN controller. So it's one of the key relationships that we have is two open source communities that would benefit working together. So many of the Neutron plugins are plugins designed around commercial proprietary solutions. Yeah. And our folks in the audience familiar with Open Daylight, it would have helped if we gave a short introduction of that, or are you mostly aware? My apologies for not asking that to begin with. Yes, Noah? Raise your hand if you're a guru. If you understand Open Daylight. Okay. And raise your hand if you've never heard of Open Daylight before. All right. So we do have a couple. So as Chris Wright said, Open Daylight is an open source SDN controller. It was formed in April of last year. So April of 13. We've had two releases. We're going by the periodic table. So Hydrogen came out in February of this year, and we just released Helium about a month ago. And again, our focus is a broad-based platform that can be used across the networking industry. And a very important northbound application for us is OpenStack. And significant work has been done to continue that integration work. So with that, I'll go to my next question targeted at Chris Wright. So your team has been active in that integration effort between Open Daylight and OpenStack with the OVSDB integration project within Open Daylight. Can you talk a bit about what features are present today and what your hopes for future development and integration between Open Daylight and Neutron and the future? Sure. So while it is a multi-purpose SDN controller platform, our focus, Red Hat specifically and the members of the community, the sub-community within Open Daylight that I'm most a part of, are focused around network virtualization. And really our primary use case is OpenStack. So we want to be able to connect Open Daylight to OpenStack through the Neutron ML2 Open Daylight plugin, which is something that's actually shipping as part of OpenStack's release at this point. There is a fundamental difference between what's in the Juno release versus what Open Daylight, the Open Daylight plugin is capable of. So initially with the hydrogen release, we focused on basic functionality. And we had L2 support and that was really it. And the rest of the functionality we got from using the existing OVS plugin related agents that come with Neutron. Our focus is network virtualization, managing edge switching, using OpenV switch instances and the hypervisor, communicating to those OpenV switch instances via OpenFlow and OVSDB. So the name of the project that we are focused on in Open Daylight is called OVSDB. Really it's broader than just the protocol, communicating to the switch. It's about solving network virtualization in the context primarily of OpenStack. The helium release added additional functionality. Not all of those features are exposed in the Juno ML2 ODL type driver. What we added is additional features moving up the stack. So we now have L3 support, we have load balancer support, security groups, getting firewalls as a service. And that's not all exposed because we missed some of the feature freeze points in the OpenStack release cycle. We have those changes sort of pending in a staging in an external tree waiting for a keel it open and for those changes to be pushed forward. Going forward we want to flush out that core support. So we have a distributed L3 router and improve from a performance and stability perspective. Just continue to bang on it the support for load balancing and security groups and then finish up the firewalls as a service and add VPN as a service. That's kind of our roadmap really. So we see Neutron as a tenant facing API that is the functionality that we need to provide and we've moved from the core Neutron API which is actually L2 only to the extensions and we're just moving through those extensions sort of one at a time. Great, thanks Chris. Next question, Kurt is for you. You've spent a lot of time in the OpenFlow standards environment for this audience. Would you mind giving a brief overview of OpenFlow in general so that we're sure that we have the context and then also talk about how the evolution of OpenFlow might impact the networking industry and ultimately infrastructure as a service environment like OpenStack. Sure, thanks. So yeah I chair one of the working groups within the ONF which the ONF, the Open Networking Foundation is now managing the OpenFlow protocol standard. OpenFlow actually began in 2008 as a very low level control language to basically control hardware networking. That was the way networking devices were thought of I think still in 2008 even though there I think V-switch has already existed in 2008. And then the ONF was founded in early 2011. The protocol was based on a simple model of creating flow entries in a table. The controller would manage the entries in a table in the device and basically control forwarding in that way. And it was a good model that you could build into lots of devices very early and you could add value in a number of ways and there were lots of demos at that time. But it was a little bit limited in what you could do in the early version of OpenFlow. That would be 1.0 that actually has gotten a lot of adoption of devices including V-switches. Well, even just as the ONF was founded a week prior to that, 1.1 was produced that introduced a lot more capabilities, multiple tables and other features into OpenFlow. And that allowed for much more capability but it's difficult to implement on hardware platforms. It's quite useful on software devices like OpenV-switch or other flexible devices but ASIC-based devices have been a little bit of a challenge. And so basically there are some growing pains going on in OpenFlow to apply the richness and power but also apply to a diverse number of fixed function devices. So OpenFlow has been slowly trying to adopt the ONF community has been trying to adopt OpenFlow 1.3 which has been identified as a stable protocol version for a couple of years now. There have been these implementation challenges. My working group produced a spec in June that is really aimed at fixing that and there's been a lot of progress towards adopting that model that will help with implementation on fixed platforms, ASIC-based platforms. And there's move to support this. That spec is called table type patterns also known as TTPs and there's a TTP project within Open Daylight because it helps that the controller understands that. Moving on to Phil's question about how OpenFlow will work in infrastructure as a service model. I think the early model and this was true identified really by Nasira that, hey, we can do a lot of work in the virtual switch in the hypervisor and we don't need to get it all working on hardware first. That's great because there's a lot of existing deployed data centers that don't have OpenFlow capable hardware so here we can use SDN by controlling our V-switch in this hypervisor and we don't have to rip and replace all the hardware infrastructure. I think that's a model that works for some time but there will be interesting hardware accelerations and so on so over time I think OpenFlow 1.3 and controller intelligence will take the SDN that's now floating on top of a transport infrastructure in hardware and that SDN awareness will move down into the hardware as the various data centers add software defined networking capable hardware OpenFlow capable hardware in their infrastructures and there will be various kinds of value adds that come from that. In some cases it will be performance, in other cases it may be visibility and debug or analytics etc. Although there's always ways you can do that in your V-switch as well. OpenFlow is also very interesting in other use cases of networking so not all networking is in a data center or it has a hypervisor there although with NFV which you guys have probably heard about as well more network infrastructure is probably going to be sitting on top of a hypervisor than in the past but there will still be other things. OpenFlow is moving down into optical infrastructure as well and so there will be OpenFlow and other southbound protocols talking to devices besides hypervisors over time and that was a long answer. Dave, Lenro. So I know you've spent significant time in your career thinking about network policy and policy abstractions. Can you give your thoughts on the work being done both in open stack and open daylight regarding group based policy and how those could or should evolve over time? Yeah, so to step back from that project in particular there's a sort of a new approach to operating and managing networks that's in a transition from sort of pure research into products and things that you can use and because the word policy is among the most overloaded words in IT and means something different to everyone else I like to describe this class of solutions as intent driven and by that I mean it involves telling the network what you want from it rather than the traditional approach of telling the network how to do it. So for someone that has an application maybe a cloud first application that consists of a large number of workloads that talk to each other instead of specifying protocols and VLAN headers and bits and bytes and things at that level what the application developer knows is these 20 workloads should talk to those 40 workloads and the things from over here shouldn't be able to get to the things over there and what we want to do is allow people to describe what they need from the network at that level hand it off to a smart piece of software that knows how to translate that into all the low level network protocol and media and vendor minutiae that it takes to actually get it to work and we've heard so much about people who want to program the network the number of people that want to program the network in something like OpenFlow which is very technical and low level is infinitely smaller than the number of people that want to program the network by getting their stupid application to work properly and we can enable millions of people to do what they want to do by making it programmable through these really abstract interfaces. So group based policy there's a project in OpenStack and there's a project in Open Daylight both of them are a flavor of this intent driven networking and what's exciting about them is they're going to enable people to very easily describe what they need from the network and people who aren't network engineers or network scientists are going to be able to use networks in the way that they want to. It's going to take a while to productize this as I said it's kind of just starting to move from research into products and decision is that everybody's going to have this easy to operate network we're not there yet and I'm not going to get into the micro details but the work we need to do in the near future is to complete an implementation and make it consumable for people and clearly the platform from which they want to consume this in large measure is going to be OpenStack and we want OpenStack tenants to be able to get their workloads to behave without having to have a PhD in network maybe also Dave elaborate a little bit on the concept of policy with protecting ships in the night type of issues with networks you know Neutron and OpenStack are interesting in that you know as a single north bound to a real physical set of network elements that problem doesn't exist but Open Daylight kind of has to expand beyond that to deal with Neutron and OpenStack as one of the applications that could be requiring things of the network and how that might be arbitrated maybe expand a little bit upon ships in the night problems and how policy is supposed to help yeah so the state of the art in SDN controllers from what I know is that people create applications that use something like OpenFlow to control the flow tables and each one of these things that it exclusively owns the flow tables and it can do whatever it wants and if you run two of these services they step all over each other and nothing works clearly we need to get beyond that and do better than that and it's a hard problem because down at the low level where you're setting flow rules in switches there's no context about what anybody's trying to do so there's this notion that we'd like to detect conflicts and do something about them but there isn't enough information to really figure out what is and isn't a conflict and what would we do about it when you take it up to the intent space it's much easier to reason about these things so for example in a service chaining kind of a situation you might have a initial rule that says Fred is allowed to connect to the internet and if you were to examine that down at the OpenFlow level you'd see a rule that says when you see this bits in the header send it out port three now if you came along and inserted a firewall appliance into the service chain for Fred and said Fred needs to go through a firewall when he goes to the internet down at the flow rule level you see another rule that says when you see those same bits in the header send them out a different port uh oh there's a conflict something's wrong what do we do when you look at it in the intent domain one rule says Fred can connect to the internet the other one says when he does he should go out this port there is no conflict it's clear that the second rule that you're pushing down is intended to overwrite the first rule and it's superseding it and it's really easy in that kind of context to say there isn't a problem here everything's fine go ahead and push the rules and the world isn't going to end so uh there's a lot of inventing and work to be done to take it from that kind of high level concept that more context is better than less but it's clear that solving the problem down at the low level is virtually impossible and there's a lot of hope to be able to automate and solve a lot of these things by making all of the things that want to access resources in the SDN controller domain go through a single interface speak a single language and a language that's rich in context so that we kind of have a foundation to try to solve this problem cool thanks Dave um this next question I'll start off with Chris Price but I think we have multiple panelists up here that are significantly involved in opnfv so I'll certainly make sure we open it up so that they can comment as well Chris I know from being at the booth that a lot of people don't know at all what opnfv is given how new it is so if you wouldn't mind could you kind of give an overview of what it is who's in it what the goals are and then maybe drill down a little bit and talk specifically about your hopes there or that organization's hopes there with regard to both open stack and open daylight sure so for those that don't know what opnfv is the acronym stands for open platform for network function virtualization the intention is essentially to create an open platform create a virtualization platform that we can focus on use cases where we are able to ship what are defined as nfv type of function so deploying gateway functions deploying signaling functions things which require traditionally what we have called 5 nines type of stability and structure that terminology I think is maybe aging it's more about availability than counting the number of nines and availability can be solved in a number of ways but aside from that opnfv essentially intends to set out to construct such a platform so we're looking at taking open stack taking open daylight kvm, libvert, quimew, sef ovs, dpdk, bundling them into a package and essentially creating a pure open source virtualization platform so it's an open source community the members involved everyone on this panel or at least the corporate entities on this panel are all involved I don't have the list in my head of everyone who is at platinum and silver level but I think there are around about 30 sponsor companies it is open source so it's not a vendor driven activity it's vendor sponsored and operator sponsored so service provider sponsored I can list some names that come off the top of my head those that are maybe more active right now we have of course Cisco, HP Huawei, Ericsson, Intel, AT&T Orange, Chinatelacom, NTV Ercamode just to list a few people that are involved and the ladder is really exciting we don't often get the operators and the service providers in these communities working with us to make sure that they get what they need so it's really exciting to see where 50% of our platinums are something our service providers rather than equipment vendors so in OpenFV our method of operation is midstream open source in other words we don't want to build open stack we want to use open stack so when we talk about we need to put things into our infrastructure management suite what we're really talking about is engaging with the open stack community and getting that done and similarly with open daylight if we need something in the networking component we're not going to go off and build it we're actually going to work with the upstream community open daylight to actually get those components into their platform and then we're going to take them in and essentially do integration and validation I mean we're doing a lot of testing there are already a number of projects spinning up around the test space I think my last list was we have 14 physical labs which are going to spin up and essentially run constant integration sponsored by various entities what more to say what did I miss any questions at this point anything that's not clear okay I did sponsored by the Linux Foundation as well good Chris well I think it's important to underscore our focus is working with the relevant communities so we've adopted the upstream first mantra so our goal is not to incubate code inside the OP NFE project and then some day eventually throw it over the wall at open stack and say look at this awesome stuff we have it's really to engage right upstream and be a part of this community to affect change the requirements coming from the operators and I think to Phil's question second part of the question I guess why is open daylight an open stack important these are to some extent two of the key projects which are driving the industry forward so they have a high level engagement there are hundreds of developers working on each of those projects the reason to take open daylight in is because we are building an NFV platform in other words the data center is the component of the network it's not the network itself and we need a platform which is easily able to extend out beyond the data center and solve networking problems end to end so open daylight provides us with such a platform open stack of course provides us with the way to manage the NFV solutions no? yeah thank you for going to the mic I don't think this is going to help hello? okay that should work could you elaborate a bit on how much you plan to work with at CNFV and specifically on their second cycle of standard development and how much you want to incorporate into your platform and for the audience maybe explain what at CNFV is the Etsy is a standardization organization that focused a group on NFV and they essentially resolved an architecture for how this can be solved across the industry and it's considered a standard architecture open platform for NFV has taken heavily from that architecture when we have looked at how to construct a solution to the problem of the infrastructure layer open NFV plans to implement let's say the IAS layer the VNFI and the VIM components we have a lot of cross collaboration so a lot of people involved in the NFV are also involved in the Etsy NFV ISG for phase two what we hope to do is to take what we've learned from the reference platform that we've produced feed that back into the standardization community so that there is more of a concrete reference to the work that they're doing phase two for Etsy NFV will be more in the manner space focused I guess we're not trying to build that today in open source and we don't want to try and solve that problem in open source before the industry's had a chance to discuss it further there are obviously some open concerns and issues around that but we will certainly continue to work very closely with the Etsy NFV ISG group as well as the ONF and ITF and other relevant SDOs even when you concentrate on the VIM part right you still have interfaces going up north to VNFI manager and it's sort of you can't ignore it in your reference platform but they're just now defining what those interfaces might look like so how are you going to work around that and again for the audience if you wouldn't mind to expand those acronyms the VNFI and VANO and Etsy 101 actually not going to try and do that because that's just going to take a lot of time so essentially the question was from the OpenStack land northbound Etsy has identified that there needs to be a way for OpenStack to work with the other software components that are managing the end-to-end network and managing the functions that are running in the network and the question was given that we provide a northbound interface from the OpenStack layer the OpenStack northbound how will we work with the phase 2 activities in Etsy which essentially are going to try and describe those interfaces in some detail my response is a little bit at the moment these are defined as reference points they're not defined specified as interfaces what we plan to do is analyze what we have as far as interfaces are and propose those reference interfaces in the context of the reference points which Etsy is defining and this way what we can do is we can start to show how the transactions would work across those interfaces we certainly don't plan to build anything above those interfaces but as you say the interfaces themselves the northbound how you use the system how you interact with the OpenStack system from a VNF perspective these will be validated they will be documented and a reference interface will be provided to fulfill those reference points thank you very good we've consumed the majority of the time here so I want to at least have an opportunity for the audience to ask questions are there any questions from the audience oh really there have to be at least at least a couple I think we answered everything actually we got somebody back at the mic could you come to the mic please actually a question is coming back to the topic of GBP group based policy and the work going on in the open daylight realm and the open stack realm and just from an operator perspective I'd like some perspective on what sort of tooling is there that can bridge the gap in the management operations troubleshooting going across both because that's been a fairly challenging aspect from an operational perspective and if there's any best practices tooling that helps bridge the gap I don't think I think the answer is pretty much no at this point it's so emergent and so new that you know crawl walk run and we're still trying to crawl I will follow that up I mean it's Dave was talking a little bit about how the abstract will be resolved into something more concrete as much as we don't have tooling today because those resolvers aren't really complete those resolvers will come with a set of capabilities for monitoring and fault management and these types of things which we will then feedback up northbound into the management component so nothing exists today but as we build the resolvers these functions should emerge as well yeah and just trying to paddle us to things like SE Linux in the case of Linux I mean early on it was really painful a troubleshoot and I think over time some of those things built up around that send with things like GBP it's going to be a similar kind of trend I would think yeah so I think initially when it works it'll be beautiful and when it doesn't work you're going to need all the same troubleshooting skills that you always needed and maybe more to figure out what went wrong but the potential is there to provide the troubleshooting in this sort of abstracted context where some of the pieces are pulled together for you so you don't have to go chasing them all around the network and the potential to improve the troubleshooting tools is enormous it just we got to get there yes sir hi you were talking about reference platform is there anything concrete for the end user if we want to put our hands on or I don't know if HP is providing a multi-layer switch for example or is it too early and that's in context of OPNFV open stack or open daylight the full SDN features of open day lights so because open day light supports multiple southbound protocols there is a pretty rich set of equipment that you can potentially talk to and control from the platform certainly HP and every other big networking vendor has a bunch of switches some that can use open flow for the control plane and some that use other things and so you know there's a combination of equipment that's already deployed that we're trying to bring under the umbrella and things that are going to be there in the future that we're getting ready to accommodate and again it's pretty young right now and probably the open flow based approach may have the most shipping switches on the shelves today but it's all coming along pretty quickly well and it's not just open flow I mean I'm chair a working group inside open flow but open daylight also has net conf and rest conf southbound protocols and brocade offers a soft router or router since we're in Europe that can be controlled through open daylight one of the other southbound protocols and SDN is more than open flow these days I think just to add to that I've been speaking with a lot of people who are using open daylight at the summit this week and there are people telling me that they're running net conf, people running open flow, people running over SDB obviously, PCP I mean I think all of the interfaces that we provide are being exercised in one way or another by various people in the industry so there is a rich level of adoption of these in the context of trying to do SDN with various network types and network elements you mentioned reference platform and multi-layer switch so one thing that is important to note is we do a lot of integration testing in a totally virtualized environment so a great way to test open daylight is connected to a synthetic virtual network and you can create that with OVS and there's tools like mini net that allow you to create these artificial topologies and then you can manage the OVS instances that are populating the, that are the forwarding elements in that topology and do that all on your laptop and just sort of poke at it and see how it works. You asked the question in the sort of the full SDN capability which is a bit of a moving target and coming from open flow sort of a hardware centric perspective bottoms up and now seeing that open stack and open daylight are really working sort of middle out in a way and then there's the OSS-BSS stuff at telcos that's coming sort of top down. What are the full capabilities of SDN I'd say are they're not locked in stone. I like that open flow is a standard because people working on hardware need to have things that are more static and stable because the hardware development times take a long time and I like that the stuff that's more software centric is open source because that can move a lot faster and be a lot more flexible and they can kind of inform each other but it is a bit of a moving target. Any last question? Well that concludes the session we are out of time. I want to thank you very very much for your attention and participation. Please help me in thanking the panelists and enjoy the rest of the conference.