[BLANK_AUDIO] >> All right hello, we're here with Madhu Venugopal from Red Hat. Madhu's working on a network efforts, as part of the OpenDaylight Project. And has been also developing a lot on OpenStack. So, we're going to talk with Madhu today, about OpenDaylight, OpenStack and, it's for commercial grade, open-source efforts in SDN controllers. And, thanks for, thanks for, thanks for taking the time today. >> Sure Nick, it's a pleasure. >> Yeah. So, I know you've done quite a bit of work on, on OpenDaylight and OpenStack. And, one of the reasons I actually wanted to, to talk to you for, for the class. In particular is your experience in the open source experience and developing SDN tools. And, um,m can you just kind of describe a little bit, you know, your history with OpenDaylight. And just more generally the OpenDaylight project has really picked up steam over the last year. What's kind of driving all of that? >> Yeah. OpenDaylight [INAUDIBLE] from the beginning. So I was statistical from a long time back. I was [INAUDIBLE] for a long time as a kid. And then, we started experimenting on the, on the, on the controller business. After watching the the Open Ended Foundation 2011. That's the first point when I got it's way by all the great big site from Argent Cosada and Scott Shenker and others. There is inspirational point where we started working on the controller. And you know, that involved to be one of the best code for code OpenDaylight so. So, count from day one and as he said the project grown leaps and bounds for the past one year and many years from now. When we usually push the code to the first companies that we did on OpenDaylight project it was around 60,000, 70,000 lines. Now, it is one point some we can't even practice it like millions of hours like close 2 million lines of code, maybe. It's it's crazy right [LAUGH]. Yeah I mean, that that is that is why my time I spent with OpenDaylight it's still not it's still in essence shade one year. Two lines of code, but, as I said it is ramping up or it's catching a part off on our channel. It is quickly becoming the de facto SDN controller out there. >> Yeah, It's, it's, it's, seriously picking up steam. It also seems to have a sort of serious backing from, from industry, Cisco, IBM, and, and so forth. And but there's clearly a big open source element to it, too. So can you kind of describe, like you know, is it fully open source, is there like, is it mostly open source. And then, I meant in like the, the, you know, the, these vendors are going to want to you know, add their proprietary bits in as well. How did it. How does the whole ecosystem play out? How open is OpenDaylight, I guess is another sort of way of asking it. [LAUGH]. >> All right. Like so one thing I've realized, and it's personally there, when I started OpenDaylight view a few months back. It's been more than a year now. You know, I was new to open source at the time. So, even I had this vision of open source where now you have. You have open source the code, but keep something proprietary to you and then now try to have an edge on others, right? I think, I think all the vendors have realized that is not the way to go anymore. Because the transition is definitely not in keeping, keeping things proprietary to you, the position, look, look at SDN. SDN and open SD they go hand in hand really, right. It has become, it's anybody who had things. The open source for networking came up really at the same time when HTML also picked up steam. So from what I'm seeing today at least in the OpenDaylight. There are a lot of vendors participating of course. But, it's, it's open to the term. Because Linux Foundation is the, is backing all this, and Linux Foundation is meant, is known for it's openness. And, and even though engineers are coming from various vendors backing. But they're all engineers working for a common cause or,you know, addressing their attempts for the masses really. So, it, it can it can be as open as it can get. So. >> So along those lines too I, I mean I'll definitely sort of jump in and ask you some more about. You know, what it does and how it differs from other controllers. But, I mean, while we're on the topic of openness you know, heck of a question. It's like what is, what's kind of the best way for people to ramp up and, and, and, and learn about it? I mean one of the the, I, one of the things, I guess, you, you're, you're you're tied in with the STN hub guys as well. And they've done a really nice job packaging an a VM for people to play with OpenDaylight. But I'd say it's still like it's pretty, it's got a famously steep learning curve. I think down the road like you know, certainly wonder if students should be looking at it and, and things like that. But it's, it's got a pretty steep learning curve. are, are there efforts afoot to kind of make it easier to pick up? And, and I guess along those lines how do you suggest people get started, like, are there good tutorials and things like that out there? Or, what's the best way to kind of jump in? >> I'm glad you touched upon this topic of, you know, the steep learning curve. And [UNKNOWN] today suffers from that problem badly. It has a, it has its learning curve. And the community is working hard to make it easily consumable. I'm if you you got look at this or like mailer you'll see that this one of top most thing about how to make it consumable for everybody. Not just for core operator developers, but for everybody out there how to make it. As simple as, like, now just pick it up and start using it, right? And [UNKNOWN] again doing some wonderful job in addressing that and the concern that OpenDaylight. And they can have different contribution for OpenDaylight, which makes it very simple for folks to pick up and start using it. But using it is different from developing on it. So the the code developers on open ended, we're all working together to make it simpler for anybody develop apps on top. Right, that is that is going to be the the the the the difference for between usage and not using it on the aging controllers and OpenDaylight. Today, I mean, as you, as you know [INAUDIBLE] coming along, and lots and lots of features being contributed. And slowly we started realizing that [UNKNOWN] even though we can not coordinate the light other are not finding it easy at all. Right? And the community is speaking out, speaking up now, and it's very good where they are giving a lot of good inputs, good inputs. And we are, we are actually changing the way we operate in Daylight. Not just be the wild, wild west and write code and throw it out there and then. We are actually making really consorted effort to make a simple for others to consume. >> Yeah, that see, that seems seems super important, I think going forward. I guess one of the one of the things that I've seen in, in some of the tutorials you've given and, and, and demonstrations online. And, and certainly wha, it seems like one of the one of the nice features of OpenDaylight is it's ability to support. A lot of different plugins inside of this service abstraction layer or I guess SAL if that's how you call it. >> Right. >> But you know it seems like then OpenDaylight can potentially support a lot of different SAL API's beyond OpenFlow. So I guess. A couple of questions there, what, I mean, what's the current status of, of OpenDaylight support for different versions of OpenFlow? And then what are kind of other popular south end APIs that people are using. I mean, I assume there's more to the story than just OpenFlow. >> Observably, OpenFlow, it's open days supports, as I said, SAL is the layer which is going to provide that abstraction between. This solve one protocols with not applications right. That's the objection there and that provides the unifying effect on edge controller like OpenDaylight. Where you can support various ways to talk to the devices. It could be from a management plane like OVSDB is an example where it is mostly management and protocol. Where we, we can talk to all these switches and manage it, effectively. OpenFlow is suddenly the, the lynchpin of SDN [INAUDIBLE]. Whether, whether somebody likes it or not, when, wha, when, [INAUDIBLE] like to say it's imperative. We don't like to use it. I doesn't matter, the OpenFlow is the lynchpin. And you know, it's it's out there to if it succeeding already with various on various standards as well. And today today open support OpenFlowWork.0.2 or not three we have one or three plug in that that supports this this protocols right there. I'm they they are efforts to start to work on dark four dark five. And has be as well enough make progress on the on the standards. OpenDaylight will catch up and try to run them the fastest way possible actually. And and one thing about but so anyway. >> I was going to say like one of the things that you mentioned was sort of the support for these different OpenFlow versions if you will. And you know, I noticed that, that Flood Light for example has this thing called Locksygen. Where they, they create these bindings for different versions of the proto, I guess the theory is that, you know, as the wire protocol evolves, you can. You know, sort of create new bindings relatively easy. Do, do you see some value in something like that or, you know, is the, is the strategy just like you're going to write plug ins as the protocol evolves. And just hope that you can kind of keep up with what's, with what's going on? >> So OpenDaylight has something very similar to that where OpenDaylight we have a lot of modeling there. So we use the Linux as the model language for, for on the modeling side. So similar to oxygen, oxygen maintains it's it's definition using a separate way. And then, we we we automated from like you can controller similarly in open data we have this model which. Where we define the, the y protocol is kind of defined in the YANG models. And as the new version comes along we'll update the YANG model. And once the yang model is updated the code is originated we have this YANG tools project which runs through this YANG files. An auto generated source code. And source code gets attached to the controller and things starts working, right? And this YANG, they way we are looking at YANG is, it's in a, as a bigger vision, it's look at it there are other protocols also makers of YANG. So even though OpenFlow is the wide protocol that talk in controller and the on the devices. Since the YANG itself tells us a buffer mechanism where you don't have to keep writing these web protocols by hand as define them using YANG. And they do put them [INAUDIBLE] make things work. So it is it is kind of similar to what is being thought about in oxygen, but one practical issue we are facing is. YANG it's pretty awesome when we can do things using models, model is great way to abstract things. But when it comes to augmentations and extensibility and so on so forth. We are treating some challenges today. Hopefully, hopefully we'll make it through them as well. So once it make it again again all of the everything boils down to make it simpler for end users. Even those complicated now then when we make is simpler simplicity means nothing right so. >> Absolutely, yeah. >> Once you make it simple, then it will be operate much wider. >> Absolutely. I guess I got a couple other nitty gritty questions that I wanted to ask you like, some more some more far out vision types of things. I guess, one, one of the things I think and actually a lot of these sort of reflect some things that disconnect between you know, what's going on in research. And what, what industry folks are talking about and I guess some of the nitty gritty here, I was trying to bridge that gap a little bit. One of the things that that I, that I, that I keep hearing about, in industry forums is OBSDB. And that's something I guess, certainly, you don't read about it very much in research papers. Like we don't talk, you know, we certainly aren't using it in assignments and things like that. But how does OBSDB kind of relate to, to the OpenFlow Protocol. You know, what, you know, do switches need to support OpenFlow to also run OBSDB and what's the relationship between the two. And the, the on the wire control protocol and what's kind of the best way to think about, you know, good uses for OBSDB. >> yeah, so OBSDB is, is like close to my heart as well. Because that's one of the reasons why I, in fact, joined, quit the school. And then later joined [UNKNOWN] right, because I wanted to work more different to OBS and OBSDB, as a mechanism to manage OBS. And we know that OBS has open switch. It's becoming kind of the de facto standard on the edge [INAUDIBLE] platforms. They have, even OpenStack is OBS has the, has the edge switch, so and OBSDB helps manage this switch, right. So we can simply see OverFlow as a as a control period mechanic where we can program flows. And make make the hot look at the traditional method networking you program things on the t cam and the mac tables. And traffic will hit that and start following things, right. Of why it's the consumer's, required to get the managing position different with, views to comps to get V-LANs. And, comps for your panels. And, so on and so forth. That get asset and into harder programming, and then, tools. I'm going to keep that, and then, charge getting power on the hardware, You can consider all of this deviant, novel influence. Dually complimented protocols where always db takes care of all the management levels for obs are obs software is running on. While open floor takes care of the the contraband for the forwarding there right Open with switch as a switch being open and open source it has modest protocol exposed and open it being this multi protocol controller. It's the perfect marriage between these two open visage and OVSDB. Where we use OVSDB as a mechanism to actually [UNKNOWN] orchestration. So, when it comes to network acquisition, I'm, I'm sure you're not talking about network yet. But network is the, if you ask me, the application of SDN. and, and of course there are other views that network is not SDN. To me, network is the application of SDN. Well, it, it really tools applying that how our mission can really helps on the latest under on the job. And look at all, all this being the, the edge there. We can actually orchestrate the, the, [INAUDIBLE] channels. Making the underlay as, as, as a pipe essentially. For that OVSDB actually helps set up these bridges, set up these [UNKNOWN] station. All of this is done using OVS DB while OpenFlow is used to actually program these flow programming rules on the OVS edges. Also due to the emergency rate we can say hey, data coming on this, VNI match on the VNI a power to a given, specific international postal code. So all the, all the OverFlow, the the programming while OVSDB takes care of the general orchestration. And these two hand in hand is able to deliver they're able to deliver synchronization just by using this recorder. >> I see so like one way to look at it too is you can't have things like virtual servers for NFD or, or you know, sort of middle boxes. Sitting on virtual machines without something like OVSDB as well. Or maybe you can, but like it makes, it makes the management of those kind of things easier. >> Absolutely yes. Actually you hit it right on the head. So OVS, expose both the protocols. Whether you use OVSDB, Angle, or just OpenFlow. Look at, let's take me as an example, right? We're near this rap and roll or yes and to me when it actually opens up only the open flow channel for the switches. But not necessarily the always dv channel right? While we can also put it always with channel and start managing things from the from the front of. And there are cases which I know already where the always protocol as being not specifically for OVS. Only there are vendor switches which they implement the OVSDB protocol. So you can move the VX land to be constellation the VX land augmented on top of switches. On various [UNKNOWN] today, where the launch support opens slow, but it's support always to be. It's like, they go really complementary to each other. And you can pick and choose which protocol you want to use. And Open, OpenDaylight can control all these protocols in isolation or in tandem together. And network is in a excellent example where we use both the protocols to actually manage the data organization. [BLANK_AUDIO] >> Yeah that's interesting I guess that leaves me to some more higher level questions I think which is one is I guess like it seems like. I mean a defining characteristic of OpenDaylight is the ability to have these plug ins that manage all kinds of things. Not just, not just OpenFlow switches. I mean, you can see, you can, as you point out you can manage tunnels, overlays, servers, other things. I mean, I guess, I mean, there's a low level question there. Which is like what are the useful plug ins in an OpenDaylight people should be familiar with. But I think the, the bigger question is. What do you think this all means for SDN? I mean it seems to me like SDN started off being kind of synonymous with OpenFlow. But now it's clearly, not just beyond, going beyond OpenFlow. But also this is way more than just configuring a network of switches, right? You've got other things as well. So can you talk about wh, What do you think this means for just, I mean, are we talking like. You can't really have SDN without, without compute and storage as well. Or, or, you know, can you say a little bit more about where you think this is going and, and what the Open TLX philosophy is. >> certainly, the OpenDaylight as a, as a product frame. We take a character to wide [UNKNOWN] SDN needs, like so open-ended on the first time it was released. We had this trend distribution called the base solution the [UNKNOWN] solution and now the transition edition. Well, each one tied [INAUDIBLE] to this kind of use case and [INAUDIBLE] requirements. And that's, that's, that's very restructuring the, the actual difference between how open-ended can help an [INAUDIBLE]. Then [INAUDIBLE] OpenFlow, other protocols. Please let me help you find it. So, let's take a [INAUDIBLE], right? If you look at the cloud or data center. Folks that need to experiment, right? It's at East Lake. Green field, many green field operations out there. So and and all is one thing, which is accepted on a, on a, on a, on a data center of its [UNKNOWN] space. And hence, [UNKNOWN] today you'll see that we talk about OpenStack [UNKNOWN]. We talk about. Only remarkable odsb, remarkable open flow, how to manage this channels and everything. While [INAUDIBLE] so lets throw this on bit more traditional then the enterprise cloud the center where it's not. They currently placed operating in first textile rather it's larger progress into the into the new world as the end right. Where what they do is they want to keep the existing structure and talk if if they if the controller or a central management plane can help. Move from an existing infrastructure increase their operation frequency by, by, by, by automating many of the things that we're doing manually today. They're happy with that and if we and tell them hey know what replacing code box and replace with OpenFlow switch. They're not going to do that right so and then and hence they really love the concept of. Operating supporting this net protocol where we support net calls with the YANG model. Where their existing devices supports our YANG right and open ended support SMNP as well. So they can rather than making it smnp as well and so on so forth and so so it's it's. It is the openness of addition of supporting the existing broad free operations. Also transitioning the new cloud into the new world of rotation so all all works in tandem right. And and not the problem inner fee inner fee is a big big big player there right. And with, with so much options available on OpenDaylight, right, NFE can, really, [INAUDIBLE] makes use of it. Where, it's it's all new, I don't want to say new things they hate. NFE is [INAUDIBLE] two different things, of course they're two different things. NFE is functional virtualiztion, as [UNKNOWN] is already for networking of course, right? But they are totally complementary in nature. We already hear folks talk about using OpenStack as a way to manage their NFE devices, right? We already hear that. We already hear things about [UNKNOWN], we already about [UNKNOWN]. [UNKNOWN] is not going to be a thing [UNKNOWN] is a, is a [UNKNOWN] across all the, all the, all the distribution, all these cases. All the [UNKNOWN] right? So, so we want to keep hearing about using OpenFlow or SDB or other protocols in tandem [UNKNOWN] cases. But today it's, we have a crystal clear view of, okay, focus on the center cloud. We have this OpenStack requirement, which ob, obviously be under open, open flow. Such it where, as a different determinant word, but those determinants in this all go flat, flat out. And there'll be, there'll be a space where a lot of, like you said, available for folks to use. And it's really up to the folks to make use of [INAUDIBLE] right. And, and they're already seeing things happening that on the first world network for any fee they want. To use OVSDB, OpenFlow and also net clowns on the site. So, it's like, it's all, it's all, it's all out there. Um-hm. Actually, yeah, that's, it's, it's, there's definitely a lot of stuff out there. And I think, that, that leads me to another question too, which is I mean. It definitely seems like, I mean, one of the things that, that sort of strikes me when I look at Open, the OpenDaylight office. Is there's a plugin for, for all kinds of things. But and, and you can sort of, you can sort of mix and match, but I think another thing that at least like. It, some, some researchers are thinking about, too, is like I mean, you mentioned, for example, like OpenStack and, and NFD on, on one hand. And OpenFlow switches on the other. But seems like now you've kind of got separate protocol separate plug-ins, you know, separate sort of ways that you do this. And then, you do that, but, you know, you know, some people are talking about. You know lets just view the whole network as abstraction and I don't have to worry about oh, is this south bound. You know, is it OBSD or OpenFlow or Netcon or something else. Lets just talk about sort of network wide extraction. Do you think such a thing is, is realistic, like is that something that open daylight folks are thinking about? Or on set what are you thoughts there? >> Right [UNKNOWN] let me, let me, take a step back and then we'll come back to this point. Right? So your looking at composition. It's about that right it's about treating network as a resource. And the moment you say hey I, I have compute, I have computer running here. I want to have an elastic way to expand the compute and so mutable network is on the way right. That's not going to be the case where I don't want to I don't want to think about network as a place that I need to spend time on. But and then it's supposed to be up and running all the time 100%. There's no, no down time for network, which would not be the case, right. And if you want to work until that you should not be worried about connectivity protocols, connectivity technical support. Whether or not I'm using open floor, or OVSDB or netcraft If normally you talk about these protocols that means. You only are getting into the complex nature of networking, right? So, I am totally on board to the topic of, hey, I don't want to talk about word protocols at all, but someone has to do the job, right? Someone has to, kind of dirty laundry, right? [INAUDIBLE] >> Someone has to do the plumbing, right, yeah. [LAUGH]. >> Yeah, and, and the someone is the per, person like me and Brent Salisbury and, you know, Dale Tucker others who are actually working. On the ground, right? Making this thing all the open source, right? So one thing, one thing I really want to convey at this, on this topic is that even though we talk about SDN, we talk about the various protocols. There's talk about OpenDaylight. But whichever way SDN goes in the future, I would be. Pushing so hard on being the openness that we have today, right? So is [UNKNOWN] synonymous to openness? Within open source, and open networking, I'll, it has to be open. Right? If it goes back into the proprietary nature, I would say it's modest DM. Moment it is proprietary. But it's not quite at the end. Let's, let's call it out by there, no. So, that's, that's, that's my, my intention of that. So, well what I'm coming at is once it's open, once it's all open. Once it is available out there like Linux, right? Linux is open. It's available out there. Not everybody who's writing. Writing applications on Linux is worried about less than [UNKNOWN]. They all take for granted Linux is working, right? But there's a huge [UNKNOWN] community which maintains it, right? So, let's think about open-ended as that one where yes we talk about, we will talk about protocols. You'll [UNKNOWN] protocols. We'll find that abstraction, we will do all this one. But as an obligation to [UNKNOWN]. Don't worry about what we talk about the unit protocols. You worry about your logic don't worry about protocol asking the thing to work fine. And if you are networking geek like like us come and contribute to this insanity right and that's how it's going to be right. Absolutely, yeah. So i guess like I mean liked your analogy with, Linux in particular. Obviously most of us don't have to worry about the internals of, of, of, you know, what the, what the latest you know, kernel, kernel patches and developments on things like that, I, I guess, You know, by analogy with OpenDaylight, like you said, maybe most of us wouldn't have to worry about the guts of maybe, well I guess the south bound API. And maybe things below the south, I guess is maybe the later below which maybe we wouldn't have to think. But I guess. Quite, I guess maybe, questions to kind of leave you with might be, Okay, you have the plumbers and then maybe you have the application developers, and then you have the researchers, maybe. So, for the application developers, what do you think are what applications would you like to see developed on OpenDaylight. That would like really take advantage of the unique capabilities of OpenDaylight? And then I guess from the research side, like, what do you think are the hard research questions. Or, you know, things like research questions that your engineering aren't going to solve that you're, that you're hitting your head against now. Either in the plumbing or above. >> Oh. I mean there's always some, some interesting close to my heart questions as well, so. We know when it's it's it's proven already that [INAUDIBLE] is the the king of yesterday as far as dm. And if you could other applications there are actually a handful you don't see wide deployment of other applications but this is really. Conditional is like enormous [INAUDIBLE] is enormous that we can actually see the one that you talk about abstraction right. Not, not necessarily the based authorization but necro abstraction assets can be used as the end completely right. Not just in data centers, not just in these orders. Of, of course we did that from campus the, the network tools, integration of network tools, security I'm working on and whatnot, right. So what are we seeing today as a networking feature, on these closed, proprietary boxes. We can see everything today with, with, with the, with our [INAUDIBLE] and the boxes are available there, we, we should be able to achieve. Anything that, even, given, given box, differentiates, using SDN right. >> Mm-hm. >> So, it could be any obligation. From, you know, from DNS thing to, old from from portal to [INAUDIBLE] right. And, and SDN help, how I would say [INAUDIBLE] they could run them to go and take a peak look at that where votes are. Votes like us who want to write engineering applications not necessarily made to open up later. But like anything they are actually doing this kind of this application like projects. Where they are exploring things there and I would they come contribute there where. They are kind of the application wing where they are trying to write applications on top of these these controllers. And and on and they're trying to solve the real world applications as well so. >> What do you think yeah what do you think of the hard like the hard technical problems. That you're just really banging your head against and you know. Maybe might, might be good for the, for researchers to think about. >> Oh yeah, certainly, there are two things that I really don't know how to know. I just [INAUDIBLE], it, we're, we're working towards the solution on that. But, see if we look at it right, the, the, in the SDN loss originally, when originally it came about. The active means it caught our attention that we said packets still go to the controller. Controller manages the packet and then after that things will get programmed for all these things right. Yes that may work for a small research kind of thing where you can start doing things. But really real world one won't do anything like that they don't want to see the. The landed off it shooting the content of a plane and getting thrown around inside the plane. But, that is something which, is like, called upon, I don't, on, on the vehicle agreement. They could be somewhat pleased despite me doing that, but, you know, by and large, folks try and do things correctly, by the rules. And things start forwarding right. So this reactive nature of things right it is stellar where we can do lot more innovative interesting things the reactive nature. Which you could never do before right. So, this this solving this problem of reactiveness reactive getting the reactive innovation. Right? Into the, into the problematic world of, redoing things in [UNKNOWN] and [UNKNOWN]. It's a, it's a, It's something which, I don't think we are solved the problem yet, right? >> Still struggling with that [INAUDIBLE] >> There is one thing which is very, >> Yeah. >> very interesting where if they can solve that, right? Then I can, I can think about. Like pins and I'm just so application which can be used in production at scale at performance right. Now that is one thing which we are struggling with actually right. I forget the question that you ask. Sorry. >> Oh, the second question I guess you you had said there were two problems that you were kind of of struggling with. Like, one was, one was sort of the reactive nature of, of a lot of control applications. You said maybe there was like another challenge. I don't, I don't know. >> Oh, yeah.
