 Hello, hi everyone, welcome to this session about open stack and open daylight My name is near a chill. I'm a product manager Let's give him maybe one more minute to join look again. Maybe people are still coming so Okay. Hi everyone. Welcome to this session about open stack and open daylight My name is near a chill. I'm a product manager with red at looking after our open-stack platform product specifically on Networking and open daylight and here between is Andrew Fredette With the technical director for SDN in our office of technology The agenda we have for today is basically I wanted to kind of briefly explain what is an integrated infrastructure for Kind of modern SDN NFV Deployments and I'm going to touch the eye level common use cases. We see on the market and then we'll deep dive into open daylight and what is the open daylight project and Specifically how it works when it goes to open stack integration and a project called net weird And then spend some time Expanding what we are doing in red at hope and stack platform and open daylight You have the slides here that are publicly available. So you can take a picture or just use the URL if you want to see the slides So some contacts before we begin I wanted to start with this slide which is kind of saying okay there's the enterprise IT and the telecommunication NFV market and In principle, yes, they're like these are two separate markets with kind of unique applications and concerns but I think we're As much as we are talking to customers and users we kind of getting into the point that very large enterprise deployment are really kind of a service provider like deployments and It's we can see it all over the place with the type of applications with the requirements with the kind of the DevOps state of mind And the technology being used So for example There's this trend of automating everything which is you know important for everyone Next generation architecture. So it's stuff like L3 leaf spine everywhere routing everywhere kind of you know big scale NFV which is really a telco concept But definitely enterprise can benefit from it as well in terms of virtualizing common functions and networking services in the campus or the enterprise and Again this DevOps and cultural change which is much more kind of operational driven and So the network is sort of transforming the kind of Line between classical enterprise and service provider is not that clear anymore and Some common use cases we see so The very first one here. I call it network virtualization Which is kind of the classical Enterprise use case if you wish and then under it. There's data center virtual networks. There is campus branch virtual networks Micro segmentation, which is just a fancy way of doing distributing firewalling everywhere So these kind of use cases are really typical on the enterprise side And on more of the telecommunications side, we see residential services. So stuff like vcpe And then the mobile which is really big, right? There is the ran section on the access side there is all the core and eepc and Then the value head services that the service provider wants to offer and Then the traditional kind of business services L2 VPNs L3 VPNs for connectivity between different shops or enterprises and so on And I wanted to pick just two of them the residential and the mobile one and kind of explain From high level what's the use case looks like? So this is like a typical kind of service provider network offering residential services And you can see over on the left side. This is the Cpe the customer premises equipment usually a very dumb kind of router or A kind of modem device sitting on your own or maybe kind of a small business and Then there's this demarcation point between The home and the service provider network and then there's difference Access technologies could be jeep on or cable or DSL and so on and then once you are at the core of the service provider Network, this is where we want to virtualize everything, right? And you can see here. There's an example of different VMs that acting as VNF Effectively offering different kind of services Like quota management parental control Traffic optimization a virtual firewall and so on and this is where you really need kind of an SDN solution to manage everything here And a common requirement would be I want to do service chaining Because I want to tailor for this particular customer this particular kind of SLA and quality of service and And the kind of the chain of services that he's paying for right The other one is the mobile services example Which is again a big one and this is kind of a typical high-level architecture of a mobile network Again, we have on the left side. You can see the ran or the radio access network kind of domain And it's very common to see just with NFV Basically a passive antenna, which is going to get the signals from the mobile devices and then immediately we are going into fiber Into what used to be the base station, right now The base station is going to be on the service provider kind of infrastructure in this case It's kind of centralized. It can also be distributed more close to the antenna But the virtual bbu. It's essentially the base station Version and we're getting the traffic and once we are at the service provider network, then we're going to the core This is more the EPC the evolve packet core use case again all all all type of Devices that traditionally were at physical boxes and providing different kind of functionalities like MME signaling gateway packet gateway and so on And then on the virtual GA land This is where we want to end the traffic before it leaves to the internet and this is again where we need service function chaining most often must often again to offer different services based on your particular package with the service provider And trying to kind of generalize the requirements for for all of that We see a huge demand on the field for standardized control of network And today we have this kind of notion of underlay or physical network and overlay or virtual network which is kind of weird because in the end it's all kind of one service one network and Maybe from kind of engineering perspective It's very easy to think of a service as an overlay, right? It's just a point-to-point kind of VXLan or whatever, right? But from an operational point of view, it's a nightmare, right? I mean traffic should should traverse some physical devices and you need to have like end-to-end visibility Into you know where the traffic is going. What's the kind of end-to-end user experience cruelty of service monitoring and so on so we really want to get rid of this underlay and overlay kind of terminology and Provide kind of a seamless integration into the network, which is something we are missing today in the SDM market big time So we're talking about fabric configuration and control control like physical fabric You cannot escape from your network and just provision the V switches Overlay, I mean if there's an overlay, so we still need to configure the overlay Be it some V switch or V router you want to control the configuration there and then support for the neutron API Which again is the de facto kind of API for networking and we're seeing tons of SDN solutions out there That are essentially bypassing neutron Which I think is kind of a bad thing for the community and for everyone here because we don't want to bypass neutron with Extensions and third-party stuff We do want to and enhance it and make it kind of a robust API we can utilize for all the use cases we care about So these are kind of very important kind of pillars of standardization that in my opinion are key to the success of SDN and Then support for different data path connectivity type So again, we all started with some basic kind of you know virtual machines view to you on the guest and probably something like OVS But then in reality we end up in this kind of crazy hybrid deployment with Linux bridges OVS OVS with DPDK And there's cool stuff coming like VPP like FDIO and so on And there's also SRIOV, which is not using any kind of virtual Switching on the OS, but we still need to support guest using SRIOV with physical function a virtual function and so on So we do need somehow to basically support all this kind of different data path connectivity option and still provide some Visibility and at least of operational experience to the to the customer Open source standard base is again Also a common requirement there are tons of solutions out there and Open source doesn't mean just that the code is in GitHub, right? I mean we need the community We need the feedback we need to see kind of the development end-to-end and we think it's really a key requirement today. I Touch before about service chaining Which is I mean it's clear to see why it's important for the service provider market market for kind of the VEPC VCP use cases But also as I said before on the enterprise side There is going to be value of you know providing different kind of value head services like load balancing DNS and so on Using appliances or VNFs. So you do need some service chaining capabilities in your platform And then there is the boring stuff, right? So nobody wants to work on kind of real Availability and availability event correlations security, but in the end this is really really important stuff As well as IPv6 support, right? So we are in 2017 IPv6 should be pretty much a strict requirement on most deployments and I'm not talking about just IPv6 for kind of Workloads, but also from a control planning infrastructure perspective your API end points and so on should be reachable with IPv6 So this is usually kind of the stuff that we neglect Because we want to work on the next big thing and the next big technology But we do need to provide some like basic availability and reliability functions in our solutions and then Last but not least I ready for future innovation Which is again big thing because I mean we are all in open stack summits and we are kind of dealing with open source Technologies and tools and you see that the rapid evolution and like there is like plenty of Projects and you can see like each and every week something is announced And you don't want to go with something which is very monolithic you want this kind of of Modularity and ability to basically plug it into the new shiny thing that's going to solve your use case And talking about future innovation. I wanted to talk about the two napkin protocol from 2089 so I don't know who are familiar with this protocol hence Come on Okay, so this is actually BGP the border gateway protocol Which is probably the most important protocol on the planet today And this is how it started almost three decades ago And it was started with two napkin by two fellows from Cisco and IBM Basically scratching some protocol wanting to solve very particular very specific use case Which is how we can exchange route policies for IP between different autonomous systems? That's BGP three decades ago. This is how it started I don't know how familiar you are with BGP, but today BGP. It's basically multi-protocol BGP with tons of difference of implementation and use cases Like IPv4 unicast IPv4 multicast VPN for IPv4. That's for L3 VPNs For IPv6 L2 VPNs vpls evpn so all sorts of good stuff which is built around BGP and This is all thanks to those two guys Three decades ago who kind of understood that if the platform if the if BGP is going to be modular enough And going to provide kind of a framework for networking you will be able to grow it and add more and more and more interesting use cases to it and I want to really Think about open daylight is kind of being the new BGP Not to say that we are going to replace BGP with open daylight But that we want to inherit kind of the same platform robustness and framework Characteristics from BGP and kind of implement them in open daylight And open daylight is just a general purpose Java platform, right? You can write whatever applications you want on top of it It's end up being an SDN controller Which is a very common use case for open daylight and it's really a robust platform Okay, it's not like a one-trick pony kind of a you know solution for one Very particular problem. It's a general purpose controller that can be applied for many applications and use cases and there are Cases of open daylight being deployed to manage IP kind of routing optical transport fabric for data centers overlay and so on and so forth so very Kind of varying use cases and applications that can be fulfilled with open daylight With that I want to end it over to Andre who is going to deep dive into open data and open stack and the technical details All right. Thanks Nier So I'm gonna start off by just reviewing really high level of About where we plug in so it's an open daylight is a as a neutron Back end so neutron has really three main components an API The orchestration layer that's responsible for configuring the the network to satisfy the needs of open stack And then some type of programmable data path that can be controlled by the the orchestration layer with the upstream reference architecture we have neutron server as the as the neutron API and the ML to OVS Plug-in or driver together with a collection of networking agents neutron agents that do the configuration and management and then open v-switch as the as the programmable data path With open daylight It's very much the same just plugging in a few different components still have neutron server But then we have a different plug-in the networking ODL driver and then open daylight on the on the back end doing the Configuration and we get rid of most of the agents and The and the programmable data path is still still support OVS, but then a collection of other options So OVS with DPD K layer-to-gateway VPP and And hardware devices as well so open daylight is a It's an SDN controller platform It doesn't actually necessarily have to be SDN as near mentioned that that was kind of the initial use case But hosted by the Linux Foundation last month it turned four years old So it's been around for a while over this the course of this time There have been a thousand over a thousand different individual contributors from 140 different companies organizations It's has a mature open governance mature code base dozens of solutions based on open daylight and many deployments So just just back to the slightly different picture of those that that high level when we look at this with the open stack solution we look at open stack as the orchestration open daylight as a controller and controlling multiple different types of devices Networking ODL is a project that Implements this that this neutron the neutron driver So it consists of a lot like with similarly to a lot of other plugins a ml2 Plug-in for layer 2 a layer 3 plug-in and a collection of service plugins for the for the advanced services And then these communicate with open daylight over a rest API so wanted to spend a little bit of time talking about the the modularity and the open what what really is open daylight and yeah We use it as an SDN controller, but it's really a yang-based microservices platform So you can think of the kernel is this MD sal layer model-driven service abstraction layer That's really the think of it the this distributed data store for all of the applications It provides the data data RPCs notifications and clustering support for high availability and then on top of this we build services and They can be anything you want they need to be defined by a yang Model and the the yang model provides a well-defined API so the services can cooperate and Furthermore within open daylight there are tools that will compile these yang models and generate Java code Java APIs that can be used by the the services that are being developed You know now typically in the in an SDN type solution will have some of these Services will be northbound Facing northbound APIs talking to orchestration systems Some will be protocols that are used to talk to devices while others will be Applications and services that are that form the business logic of what your of your solution So this is this I don't expect you to read this nested slide necessarily There's a link at the bottom if you want to but the the general point here is that there are a lot of different Services that have been developed on open daylight. I think sometimes open daylight gets a kind of a bad rap for being really complicated but the the fact of the matter and I think a lot of that is because of all of these options and Trying to figure out. Okay. What exactly do I need to do what do I need to use here? But in the solution that we're talking about which is never really only use a small subset of those highlighted in red here that implement this this service and and potentially others in the future as we look to integrate with VPP which We'll be talking about later on in another talk, but But these are there are tools there that you can use you don't have to use all of them And it's not very complicated to install it. It's a fire up your craft instance and install ODL the net vert open stack and it pulls in everything that it needs and that's it or better yet it's this is all integrated with triple o based installer and Can be included in the installation of the overall cloud So let's talk a little bit about this the open daylight net vert application And what's happening inside of open daylight to make it work? Open daylight has one common northbound API neutron northbound to communicate with open daylight and this is our open stack this is done so that It can to a foster innovation within open daylight and allow multiple different applications to be developed to support Open stack and several have been several have been developed and some have been you know consolidated and I think we've we're kind of Arriving on net vert being one of the most popular and most active one of those solutions net vert so neutrons northbound's job is to receive the the configuration information from From from neutron from networking ODL stored in this in the MD cell and it's not really shown here But of course, this is all this stuff is built upon the MD cell and most of the API is between these Components are are based on MD cell, but The within net vert it listens to this this data store through notifications and and when a Something a configuration is is passed down from from neutron network goes goes to work and Configuring the devices to support what's needed within within net vert. It's built. We have our own Network abstract network model and we don't use exactly the neutron Because model because this is designed as a network is designed to support multiple different northbound plugins and there's work also going on to integrate with Kubernetes and Potentially in other northbound APIs as well. There's a math based API That drives network vert as well So it's a generic network virtualization solution and each of the within net vert the the different components are modular to support layer 2 layer 3 VPN services and then southbound There's a renderer model where we can use this this This data model and render it on to different devices So currently it's mainly open-flow and OVSDB based devices the OVS switches and hardware VTEP the Renderer so for hardware top-of-rack switches that support OVSDB But work is going on But we also communicate with BGP routers for our BGP VPN support for multi-site And then work is going on to support VPP and then also physical underlay devices So I have a list of features here. I'm not gonna really go through all of them in in in depth but the suffice to say that there's a pretty comprehensive support for neutron APIs and we're you know This new new features are being implemented in each release fully distributed layer 3 layer 2 layer 3 routing Vxl and overlay various types of overlays not support security groups So it's very functional and some and I also want to point out some of the key work that's going going on moving forward And that's that I've touched on some of these earlier, but the container integration. There's a project for that Physical network control EVPN. So we have EP VPN for inter cloud but for controlling devices within the cloud and then this the VPP and GVP integration and I just one last slide here that this really done is a cross-community collaboration with a number of different open-source communities one of the ones we work with really have a well course open stack that We're talking about today But in addition to open stack opnfv is a place where a lot of these things are pulled together Integrated tested and verified so all right at this point. I'll hand it back to the near Thank you So last section I wanted to talk a little bit about open daylight and red hat So what we are doing with open daylight in terms of kind of productization So our current open daylight focus and I think under touch a little bit of it before So this is these are the project. We are involved with So on the left side these are the open daylight project. We are actively contributing to and working on So obviously kind of the core open daylight beats the MD cell and yang tools and other kind of the basic infrastructure pieces of open daylight and then everything which is Rated to the neutron use case right the open stack integration So neutron northbound as a project and then net weird as our service provider And it's really we are really happy to see kind of this option convergence around net weird So we're working with you know folks from NEC and Ericsson and others And we're really happy to see everyone kind of agreeing on net weird being the main kind of provider for open stack networking SFC is another project which we are integrating into net weird to solve the service function chaining use case We are working again very closely with the other communities with the kernel team with OBS Because we need an estate support for that And this is something we are eagerly waiting for And bunch of integration and testing so all the kind of packaging and testing to make sure that what we are doing is Properly tested and on the southbound side as Andrew mentioned We are currently mostly focused on two protocols and project OBS DB and open flow to interact with OBS OBS DP DK or top of rec switches Which are really based on the OBS DB hardware VTAP scheme Which we think is kind of the very fundamental Pieces we need to provide and a good over a decent overlay solution But definitely the native evolution of that is to go net conf BGP and others to provide a more comprehensive insight into the physical underlay the physical fabric And then on the open stack side. It's on the right side here. We're obviously contributing to neutron because again, we don't want to Replace neutron here right neutron is still where the networking API is being defined We just want to implement this API using open daylight So we want to make sure that neutron is healthy as a community But also that the right features and obstruction obstruction sorry are getting into the upstream bits obviously networking ODL, which is the project with the collection of plugins and drivers for open daylight to Neutron and then triple O which is our deployment based system for Sorry project for open stack And Android touch before about the kind of the complexity of open daylight and you know just huge You know number of projects there and we are really proud just like we work with did with triple O to kind of make it Very easy to consume. So we we do have Basically images and eat templates as everything you need to orchestrate an installation of open stack together with open daylight Which is really a simple So this is something we are working on as well in terms of Commercial product So starting we try that opens like platform eight, which is our Liberty based open stack platform We are bundling a an open daylight RPM and open daylight package together with our open stack platform product And it's currently offered as a technology preview. So it's not fully supported But the beats are accessible to all of our customers And again, we are not Packaging everything in open daylight. We are really really focusing on the open stack Networking use case. So we are essentially packaging the net bridge project and all the required dependencies to run it So the base controller staff the protocols southbound protocols we need and so on And the idea is really to provide it as a back end to Neutron. So instead of using the MO to OVS Kind of driver or maybe the nooks bridge and so on basically using open daylight as a back end I really encourage you to find out more here. We have two links the first one. It's actually a blog post Fending what we are doing and there's link to documentation and Inside and the second one is just an email alias So if you want to give us any feedback about the platform your use cases and experience So we're glad to hear and talk to you And this is just to show the reddit package. So again very Kind of focused on our use case basically The API as we need net view is as a base application and open flow and OVS DB But again, we do have plans to go into other applications and plugins based on on the use cases we see and Definitely the main demand is from the NFV market, which is driving a lot of our open daylight work But again, we do see also customers on the enterprise side kind of benefiting from from this work And my last slide is for again some links for further reading and the slides will be available after this talk So you can just click the links. So some more information about the upstream project. We talked about in particular the net grid project Genius and the container orchestration engine project, which we are all kind of active in the upstream currently And then on the product side, we have our product documentation We have a product guide and then installation and configuration guide Which is basically explaining how to use triple low to deploy reddit open stack together with open daylight So this is really cool. I encourage you to check it And then some more kind of NFV rated documentation That's it we have around five minutes for questions so There are two mics one on the left and one on the right, so Do you mind using the mic because this is being recorded? Sorry Well, I don't think they so in your last slide you show the the ODL API and then in your slides you showed a whole stack of you know Diagrams and you know components that were used for open stack in this particular case How much in that slide in particular that was really very busy And you just selected the ones that were necessary or required. How much more development work is needed to? support in those particular projects to support for example the open stack As the controller use case it's all there working now Well, but what if like additional? Components that were not selected there was needed to be done Because you know you're talking about the complexity that people thought was surrounding this and I would imagine That was because maybe some people at some points were using this realized maybe there was something additional to be integrated into this so I think so right now we have a net vert is really a comprehensive Neutron back-end it provides net the net vert using net vert with open daylight provides you with a comprehensive neutron back-end You know for open stack and if you want to control OBS or Toporex switches now if you want to say we mentioned using the controlling VPP switches the Fido VPP So that's additional work So that's new keep new capabilities We're also planning to do work on new controlling controlling the the underlay physical devices So that would be new work, but if you if you basically want to use OBS and in the L2 gateway It works today With DVR enabled you lose really the ability to do a dpdk acceleration in the compute nodes Does bringing an open daylight and net vert give you the ability to solve that problem So you can do a DVR architecture with dpdk it does. Yeah, you don't actually use DVR open daylight is is de facto DVR, yeah, I mean we don't use supports it it supports dpdk Yeah, I mean open that doesn't rely on kernel construct like namespaces to provide routing so It's basically just open flow with OBS. So from open that perspective We are talking OBS db and open flow to OBS and then it's could be that dpdk data path or kernel data path both are going to work the same way a bgp question So if you have a say an an open contrail deployment Should we expect that open an open daylight deployment to be able to bgp peer with open contrail and be able to exchange routes and Integrate with that or in fact it can't I actually learned that today that some some folks from ericsson did a demo during like a recent I can't remember when it was but where they they showed Open daylight peering with open contrail and also with new wash so the three different So that's one of the advantages using this using routing for peering All right, thanks Those slides that you mentioned that there's multi site support Using bgp peering. Can you elaborate on that? Yeah, that don't take it. That's the a vpn. Yeah, so We the net ver supports bgp bgp vpn Support services, so there's a bgp vpn plugin or a neutron service that so it can be controlled via open stack and then The open daylight will Use bgp to exchange routes between the different sites and allow connectivity between the two and what's supported Currently and so we use externally from open daylight We use an instance of quagga to do the peering So that's where the bgp is implemented, but then that peers with a physical gateway and Then it can be used to again exchange routes between the two different sites and then use an mpls over gre Uh encapsulation with bgp vpn to For communications between the sites through these gateways and then Also added this during this latest release was support for evpn encapsulation for layer two So the first one was layer three second one is supports layer two as well Hi, yeah, I had looked at open daylight a while ago now and one of the things it was lacking was the controller clustering What's the current state of that? So, uh controller clustering is supported. It's uh, and it works reasonably well It's something it is one area that we're going to keep banging on to to make sure that it it works Flawlessly, but it is something that we're planning to have and it's supported by a number of Vendors, okay, it's it's no longer just what uh kassandra. That's what it was at some point Yeah, it's it's built into the md sal that is implemented a a raft protocol to Ensure consistency between the the databases. So it's all built into md sal Yeah, and just to say that currently with the triple o work we are doing so like if you take the Kind of a catabits. We're still deploying just one instance of open daylight But starting with the next version We're going to basically deploy n numbers of of controllers. So it's going to be back into triple o as well Okay, great. We're working on it with triple o Deploy a set of controllers and if you have a multi site, you know post that deployment with triple o deploy controllers in every site And then you federate them or so do you have a centralized the architecture? So currently we have support just for one open stack cloud That's our first phase But once we get there we definitely want to look at into the multi site kind of use case and and solve it So currently we do not support kind of multi site with open daylight And what is the kind of the roadmap the timeline for that? I cannot say I mean it's it's something which is bigger than open daylight because there are also limitations on triple o itself to support multi site Um, so we are working on it, but I don't have a concrete kind of version right now Okay One last question There was a nice graphical user interface to open daylight, which I utilized. I don't know a year before this day and You could very easily show the flows between modes things like that What was really beautiful because normally you don't see that and you have just rough understanding So, um, will we include as I thought it's not really included at the moment, right? So actually it is. Um, it is it's called deluxe daylight user experience and it's part of our package um Well, we did some change recently and we changed some stuff on net veert That broke some of that, but we are we we are working to fix it And yeah, I mean there is a great benefit on evident on having something like deluxe because it's kind of From an operational point of view It's giving you a better kind of visibility into the flows Because troubleshooting open flow rules on ovs. It's uh, it's a hard it's a hard job So it's kind of visualizing the tables and flows and like vx on id is pertinent and so on So it's definitely included And it's tech preview so we can definitely play with it and give us feedback I mean we know there are some bugs, but we are definitely working on it And are you asking about the basic deluxe interface or the uh, there was also some more kind of a poc to To expose additional information about net vert and the switches the physical switches and the flows so great Yeah, so there that existed as well I don't I think it uh, it's it was more of a poc in and hasn't been maintained as well as it It should have been but it's something we definitely have on our kind of road, you know, at least List of things to do let's call it that. Yeah, so do you think open daylight will be The default in our deployments in two years? I don't know from now um, yeah, I mean personally, I think that We should at least recommend it for at least for nfv and for our nfvi stack Because again currently we are defaulting to just ovs tpdk or sry ov with the ovs agent Which is usually a no go for for for for nfv, right? And then people do want kind of a robust stm platform And we think that open that is the natural evolution of that So open that would be the recommended for nfv and then again if you are a big enough enterprise And you have the right use case you can use it as well, but at least for nfv We think it should be the default Thank you Okay, thank you very much. Yeah, thank you