All right folks, we're gonna get this session started. I'm just gonna start with a quick round of introductions. I'll start by introducing myself. Before I do that though, this is the flight from Atlanta to New York City. If you're planning to go to Washington, D.C., you're on the wrong flight. I mean, sorry, this is the panel for Open Daylight. Here we have some of the smartest minds in Open Daylight and I am very much honored to be leading this panel. My name is Neela Jacques. I am the Executive Director of the Open Daylight Project and I'm gonna hand it over right away to Mr. David Ward. No, wait, the other one. You know, that has happened before. Actually, no, my name's Dave Meyer. I'm CTO and Chief Scientist at Brocade and also the Chair of the Technical Serving Committee of the Open Daylight Project. My name is Kyle Mestri. I'm a Principal Engineer at Cisco and the OpenStack Neutron P.T.L. Hey, my name is Brent Salisbury. I'm a Software Engineer at Red Hat. My name is Ben Gopal. I'm a Principal Engineer at Red Hat Respel. Cool, Madhu, keep the mic. Let's start, I'm gonna start something a little bit easy.  Would you mind just giving us a quick overview of what problem we're trying to solve in Open Daylight? Well, that's not fair, that's hard. Come on, Madhu. Frankly, we are trying to solve a lot of problems in Open Daylight. I can take the entire day to explain what all we are trying to solve. But at least, my hope is that now we are being sensitive to the end customer's needs and right from hydrogen release, we have the editions releases where we have the base visualization and service provider and we are kind of boxing ourselves to these three use cases at least. But there are a lot of projects coming in fast and furious. So yeah, it's like networking is our space and we address anything that is out there. So that's what I see yesterday. So you think we could solve every problem in networking in Open Daylight? Absolutely, yeah. All right, well let me, I'm gonna hand my mic over to Dave unless you can pass it all the way over. Dave, you're the head of the TSC. Are we gonna spoil the ocean in networking and solve every problem? Well, as Madhu just said, we're getting a lot of projects that want to come into the overall project and basically the projects have a life cycle and that life cycle begins with a project proposal and then they go to a state called incubation and everything that we have is kind of an incubation state either in the previous release hydrogen or the future release helium. That doesn't mean that all of that stuff will become mature or stay in the project but we don't know we don't know what's important, what's good, what customers will like, what will solve use cases so we have a pretty low bar for allowing projects in but as they want to mature, there's successfully higher bars so I don't see that we're gonna boil the ocean. Right now it kind of looks like it but that's kind of inherent in having this low bar for entry because we wanna incubate whatever we can at least those projects that are germane to the networking mission that Madhu was describing. Cool.  One of the first questions is as this comes up, we've got different projects lost to different views. I can't help but notice that you all don't work for the same company. In fact, your companies probably compete against each other. We've got some other companies in the project not sitting here right now who are also major competitors with all of you. I'm gonna start with a question for you, Kyle. You stand here, the sole representative of Cisco. Why would Cisco participate in something like Open Daylight? Why would you share your secret sauce with everybody else? Well, we have really good secret sauce, first of all. No. Well, I think that the reality is that going forward, everyone sees that open source is really the way forward for a lot of things, including networking. I mean, if you would have guessed three, four years ago the excitement going on in networking right now with SDN and everything like that, look at where all the excitement is. It's all from open source. There's all these open source projects. We're all up here representing Open Daylight and that's a great project with like Dave was saying, lots of incubated things. It's really pretty crazy what's going on right now with all of this excitement as well. And I think that what you're seeing is all of these companies want to be involved with this. So I think because their customers are kind of pushing them in that direction. The customers want them to be involved in these open source projects. The customers are pushing them in that direction. So I think that's kind of why we're all up here. Can I take that off? Yeah, I wanna talk about this, man. I have to, right? Because I was with Cisco when Cisco contributed Open Daylight source code to the Open Day community. So I was there in the history of Open Daylight just to call it right. Frankly, we had no idea Open Daylight will be this big when we started, right? When we started the base Open Daylight source code back at Cisco when it was there. Our objective was to commoditize the SDN control market, right? That's the real objective, right? To be frank. But once we saw the community building around that, right? I mean, a lot of guys interested in this. Now we see it much beyond the SDN controller, commoditizing the SDN controller. We can do much, much beyond what we originally thought. And now the excitement is like, now Cisco is like a huge contributor there and a lot of companies coming along. So it's much beyond commoditizing a controller market. I'll chime in on that. Because I think OpenStack paved the way for what we're doing. There's been quite a few open source controllers out there. There's been, but none of them really picked up steam because there's a lot of risk going into this for a company. I think it's a collective risk with everybody. But it's also from the consumer side. So I started out as on the other side where I'm watching this build up and I need to pick something. Well, I'm gonna pick something that everybody's engaged in because the only thing that's gonna work in my opinion is multi-vendor open source in the long run because anything else just really isn't collaborative or capturing needs for everybody that everybody will kind of get around. And we saw the StackWars and I think we maybe even learned from the StackWars and the SDN side. So just to follow up, I have a kind of a wider, no, I don't know, wider, a longer view, which is that I see it as sort of like internet philosophy kind of coming back. So when we started doing the internet, it was about openness and transparency. People knew how to do IP, it was published, open standards, all that stuff. There were competitors, IPX, Apple Talk, all this kind of stuff, but those things all died. But the implementations that we had became proprietary and vertically integrated. So you got a router, right? What's inside it? Who knows, right? And having that become more of a white box than a whatever, black box is sort of back to the future on the internet, I think. So I think what we're really witnessing, along with what everybody else said, was sort of the moving forward of the philosophy that we had when we built the internet, which was openness and collaboration. All right, and that all sounds great. But if I go out and I look at the websites, if I look at the news, I gotta say nobody in this industry seems to agree with each other. I'm seeing so many people pointing fingers at each other saying, your vision is silly, your vision makes no sense. The only way to go is an overlay. No, overlays are the completely stupidest way to go. How do you manage in an open source project when you've got individuals whose companies fundamentally disagree with each other? Do you agree to just agree with each other while we're working together, or do you disagree within the project? How does that work? Can I say? So what was your quote today? Trust plus conflict is truth, right? Trust plus conflict is truth. Trust without, is the procedure truth. Conflict is, yeah, conflict without trust is politics. That's the answer. I think even more than that too. I mean, so Greg Farrell wrote a great post that talks about how, about how when you look at open source projects like Open Daylight and OpenStack, you're actually seeing the sausage being made.  If you're buying sausage from a vendor, you don't get to see all of that. But I'm sure, we all work at vendors, we've seen that actually happens. You're still making sausage internally, you just don't get to see it being put into the casing so to continue it. So essentially, I think that's really what's happening. I mean, I think it's all healthy debate, it's everything. It's just that you're seeing stuff that normally you don't see in a proprietary vendor product. All right, I'm sorry. I'm gonna ask you a different question so that we can get through everything. You've been involved a lot, Dave, in the IETF, right?  Well, we have a lot of methods for standardization and you've been involved in a lot of them. We're here at OpenStack, there's Neutron. Why the heck do we need Open Daylight? Why can't we just get it done with the IETF and you're the Neutron PTL for God's sakes? Why do we need Open Daylight? I'll take the IETF part, okay. I'd like to take that part too. So one of the things, and we heard this this morning, one of the things that's so fantastic about the open source community, and I've written about this quite a bit nowadays, is the amazing acceleration and velocity at which stuff is happening. One of the really problems I think with the IETF these days is it's just really slow, right? And so you kind of look at it and you go, well, there's reasons to standardize things, maybe. But what was it? You could have good, fast, and cheap, and now it's just fast, fast, and fast. And the IETF is unfortunately slow, slow, and slow. And that's hurtful to what we're trying to do here. Right, and to continue that, I think that it boils down to the fact that do you want people to generate a bunch of specifications and argue over that, or do you want them to generate working code that can actually do stuff? I think at the end of the day, that's what it actually comes down to. Working code is gonna trump a document. On the pipelines significantly changed to, like Nick McKeon, Stainford Guy, and one of the founders, as a great quote, it's 1982 and the microprocessor just came out. I mean, that's what it is in networking. So we kind of fell behind the curve with, as Compute really storage did too, went along. So why not do it just in neutron? Why do we need open data? Why does a set of projects? I've got a lot of spinning on that actually, but oh no. I mean, if you look at OpenStack though, it immediately out the gate solves one of the hardest problems in networking and that is like, how do you discover what's out there? So networking for 25 years, as long as Ethernet's been around, we flood networks to figure out where everybody is. So out the gate, you have something that tells you exactly what the state of your compute infrastructure is and out of that compute infrastructure is metadata that we consume. Mac address, IP addresses. We know where all this is now, just out of the gate. So I personally really like Neutron. I like the APIs. We don't really have a data store quite yet anyway, so. At least I'll take the neutron part of it, right? Yes, please. Today in Kyle's talk, Mark actually spoke about that actually. He explained why OpenDalight and why not in Neutron. The answer he gave is actually the right answer where OpenDalight folks are primary network engineers, right? Who are writing software code in that, right? While in other open source software, where software engineers who try to do networking they're two different bees, right? At the end of the day, both open source projects, of course. All the code is out there. And in fact, OpenDalight can become the default Neutron plugin as well if need be in future. But just that is the composition of engineers are different and the kind of problem networking tend to solve is a big problem, of course, right? And we need real experts there and then that makes a difference to me. Sure. We're gonna do questions. I'm gonna do, go through a set of questions with them and then I'll open it up for the audience if you guys don't mind. I'm still gonna interrupt.   Anyone here? Sure, let me take a crack at it. OpenDalight is an open source project in the SDN and NFV space. Specifically, it is a project that is built around a common code base for an SDN controller so that the industry can either deploy that control if you're an end user directly and consume it just as pure open source or they can be picked up by other members of the industry, build their products around it so that we have true interoperability and we don't have necessarily the vendor lock-in that you get with 35 different controllers in the world. That's about the best I can try. Do you guys wanna add to that? Yeah, just maybe from even a little lower level to the average network operator engineer architect. When you operate a network today, you are operating thousands of devices, they're loosely coupled one another. So there's just inherent inefficiencies to that. So I think more than anything, what we will solve regardless of religion, vendor or anything else, we're gonna solve management problems. When you start consolidating, there's some good debate around controller control lists. I think consolidating of APIs is nice. So if you're managing thousands of switches and you've got your NMS going out and pulling those. Well, when you add another one, you now have to go back and add that to your whole tool chain. If you start consolidating that, that streams on. Great. All right, one of the things, if some of you follow me on Twitter or read my blog, you'll find out is that I'm a strong believer in the need to internalize the industry's debates. And we've been talking about how not everybody agrees with the same thing. I was going to have Mike Dvorkan on this panel, but unfortunately, Kyle, or fortunately, Kyle is replacing him. So this was aimed for him, but I hope you can answer this one to start with. Mike Dvorkan has written about a big debate that he sees happening in the industry, which is the debate between, is SDN gonna happen in a declarative way or in an imperative way? Do you centralize all of the intelligence and simply tell the hardware what to do and how to deal with flows? Or do you instead capture needs and pass that down to the hardware? And so I'm gonna start with you, Kyle, but I'm gonna go to others, which way is right? What's gonna win? Sure, way to put me on the spot, right? No, I mean, I think it ultimately, I mean, people wanna frame it that way, right? And I know where this is coming from as far as where that is. But I think if you look at it, if you wanna actually look at it that way, you could look at what open flow is and you could say open flow is an imperative model, right? That's right. And no one really uses, we've already discussed, Dave brought this up earlier today, in a reactive, no one can use open flow in a reactive manner in any sort of scalable way. It just doesn't, you can't do it, right? So perhaps the answer to your question lies with that. It's an imperative way of doing things that's not really scalable, right? So you're saying the imperative way won't work because it just won't scale? At least with open flow. At least with open flow, okay. Well, I mean, yeah, but what is reactive? What is proactive? I mean, but there's a lot to it. I would argue we don't necessarily know exactly what's gonna, but I mean, the traditional, like open flow needs to be modified to stop looking so reactive like it is. There's extensions like Nasir extensions that start making a lot of sense. We're definitely looking at stability and everything has to be proactive.  That's just what people in the field mean. Yeah. The question, right? The question and answer doesn't gel together properly, at least, right? So the imperative and reactive do the, doesn't answer the question at least to me, right? The imperative model and the reactive model are two different things to me, right? Because open flow can be used as a reactive or proactive. Doesn't matter, right? So the question really is whether it's declarative or imperative is mostly model based or I know, purely, that's the question, right? So both make sense in different use cases really, right? There are use cases where model, different declarative way of approaching networking makes really a lot of sense. Like if you look at today's SNMP, it's all model based, right? Where you declare a model like a MIB and then you interpret it the way different way, different way of doing things. So to me, both has its place in the networking industry as well. As for use case, on the use case, I would say open stock use case today, right? I would say use open flow and OBSGB, we are good enough, man. It works great and it's fully proactive, no reactive there, so it works. So to me, reactive or proactive doesn't fit into this question, I think. Yeah, so by the way, if you don't know what this proactive and reactive stuff is all about, just come find us later, it's not that. It's just a property of open flow and we could describe it here, but I don't think we have enough time. I just wanted to mention that this idea of imperative versus declarative is not a new thing. In fact, we went through this in programming languages back in the 80s, prolog, functional programming, list, scheme, all that stuff and the reasons were the same.  And the same thing is true here. You wanna describe what your intent is, but not how it's done in the declarative case. And what that gives you is the ability to decouple the intent from the implementation and that's quite powerful. Cool. To not pick on you, although my next question on my list is for you, but I'll pick on the Red Hat guys a little bit. So Red Hat's investing. Community, that's, oh, sorry. It's more interesting this way. On the Red Hat side, you guys are investing a lot in OpenStack. And you're investing quite a bit in Open Daylight. How do you see these things going together? Are they completely separate projects? I mean, we talked about it, it doesn't sound like they're competing projects. How does Red Hat think of OpenStack versus Open Daylight? Are they part of one strategy or are they just two separate bets for the company? Yeah, so our goal obviously is to get to the point where we simplify networking and OpenStack. So right now, OpenStack networking is very distributed. You've got a lot of agents out there. We would like to simplify that with some abstraction. And there's a lot of properties that are just out, that are really important to a network that are completely out of the scope of OpenStack. Does OpenStack want to know latency and cost of a bandwidth link between two data centers? Probably not. So you start getting into some of the details that are really just, the nasty details of networking. Yeah, I'm new to Red Hat, right? It's been seven, eight months. But I've been following Red Hat for quite some time and the strategy. And one of the biggest question I had when I joined Red Hat is, hey, how do they make money out of Open Source, right? How do they really make money now? As of last year, we made a billion dollars in revenue for Open Source. It's quite a stunning achievement. So the answer fits right there, where Red Hat as a company, we will work on various Open Source projects, right? Another day we will bet on the winning ones, really. That makes a company successful, right? So OpenStack and OpenData both are important for Red Hat because both are winning projects from a customer standpoint. So both Red Hat is getting into the cloud business, we all know that, right? Red Hat is the number one and number two contributor to OpenStack today, right? As we know. We are investing heavily on cloud and with our Open Daylight, I don't see a good networking story for the cloud, so. Do you see them as part of one strategy, really? Yeah, yes, SDN, NFV, all Open Daylight makes a lot of sense in all this. It is a strategy, yeah. All right, so big question for Kyle. Okay, I'm ready. I will tell you as Executive Director of Open Daylight, few conversations happen without being asked a question around Cisco and its motivation for participating in Open Daylight. The biggest doubters will bring up things like, well, isn't this Cisco's attempt to open wash? Or another one I heard, I even heard this today, this whole group policy and opflex thing, is this just a case of Cisco trying to paint something as a standard that it invested in many years ago? How, what can you offer to the doubters? How can you prove and show that you really are open to being collaborative and that this isn't really just a marketing ploy? Well, okay, so actually, that's really, that's a pretty good question actually. No, the, okay, so the group policy work for those who aren't aware is some work that we've been doing with Brocade and Plexi and Middlecura and OneConvergence and IBM and a bunch of other companies as well. We've been doing this work across OpenStack as well as in Open Daylight now. The OpenStack work started at the last summit actually at Hong Kong, we had a presentation on this. So the goal, the goal with the group policy work is to kind of simplify this and it kind of goes along with what Dave was talking about where you could separate intent from implementation. So in other words, you can allow application developers to signal their intent and not have to worry about the details of the underlying implementation as well. So honestly, this work, like I said, we've been doing this with a lot of other companies across all of these projects. It's all been done in the Open. You know, we're really not, we're not hiding anything. The intent is to drive this so that everybody can realize value from this. And with the list of partners that we have working on this in all of these Open Source projects, I think everyone sees the value there. And Dave, you run the technical steering committee.  Can you define make sure? No, I'm just kidding. No, you know, my approach to it has always been, well, first off, and we heard this again today, which was kind of interesting is that, you know, engineering as a process is kind of adversarial in a good way, right? I mean, I have an idea, you have an idea, we duke it out with mutual respect and I try to convince you that I'm right and you try to convince me. And if we're lucky, one, you know, I convince you or you convince me. If we're not lucky, we have, or if we have multiple ideas, which we do, by the way, and we could talk about what those are for different things. You know, we have to, you know, then what we do is we kind of let the bottom up process work and those projects that get developed and become real are the ones that kind of win. And that's one of the things about Open Source that's really so great is that real things win. You can talk about it all day long, but unless you have code that actually is actually integrated in projects and that people can use, you're not gonna win. So that's kind of the approach we take. Cool. Another question I get a lot is, how will I consume Open Daylight? Will I pick up a tar ball? Will I get a distro from somebody? Or will I buy a product in which, that is built around Open Daylight technology? What do you guys all think? Well, that's easy for a distro. Well, actually, that's a really great question. And in fact, when the hydrogen release first came out, I remember on some of the TSC calls, we had this exact discussion because, I mean, I've heard some people say Open Daylight is maybe a bag of parts that you could put together. And one of the great things we did, and Madhu alluded to this earlier, was he came up with the base, the virtualization and the service provider additions. So even from the upstream project, when Open Daylight does a release, these are packaged and we've kind of targeted them towards specific use cases. So even if you don't have a distribution release, the upstream release has at least been targeted towards a set of use cases. I think he's covered it. I mean, the one thing I would add to it is, how do you operate it? So are networking people gonna operate this? Are the edge virtualization team gonna operate it? Or the cloud operator? That's still up in there. I don't think any of us have an answer there. I mean, a lot of that's evolution and the operators and the actual people doing work as opposed to talking about it, figuring it out. I can add one more thing, right? If you ask my boss, Chris Wright, he's not here, I guess, right? He would say that having a distribution from Open Daylight like what we have doesn't make any sense, right? Because it doesn't fit everybody's need. He's right because we had a customer request on one of the bundles to be added in one of the editions. We had to fight it over and things like that. End of the day, if we had to come up with a way which we are working on, of course, no point in the community where customers can come, choose their features, and they have their edition, right? That's the goal that you should end up in, end of the day, right? We should be able to provide whichever edition they want that fits their needs, rather than be preparing things for them. A very use case specific, I mean, because that is SDN, right? We're trying to gain efficiencies through not doing everything the exact same way everywhere because the cost on that starts to fall down. Right. Dave, I've asked you a bunch of questions as TSC hat, wearing your brocade hat. You're one of the CTOs at Brocade. If people follow Twitter, you seem to have just gone out on a huge hiring spree, hiring some of the top talent in the space. What's the thinking there? Okay, let me see if I can get this right. So the idea I had when I came to Brocade was, I had been working in the SDN area, and then we started around the same time, or maybe, how long has open daylight been around? Just over a year. Just over a year. Okay, so I've been at Brocade maybe 16 months, right? So I was fighting a lot of other battles, as you might imagine, when I was there, and then this open daylight stuff started happening, and I got in the position I was in, and I was thinking, wow, it would be really good if we could get some people who could first help the project mature, and at the same time start thinking about how we could do value-added different kinds of services or applications or whatever on top of it. So the idea that we're having right now is more or less this. Help the, primarily help the open daylight community harden all the aspects of open daylight, make it enterprise grade, things like that, and contribute committers to, or committers, well, maybe committers, developers to that process. And in the process of doing that, that hardens the platform that we would use for our enterprise grade thing. So we're kind of looking at the whole open daylight project and the open source aspect of it as just our development technology, not our development methodology and technology isn't something different. So that's the way we're doing it. Cool, and I'm gonna do one last question, then I'm gonna open it up to the audience. So the last question is we've got a, there's a release of open daylight, the next release after hydrogen, the helium release coming in the fall, seems to be a flurry of projects. If people aren't watching the Wiki every day, they might have missed some. Can each of you talk about some of the projects that you're most excited about that have just recently been proposed and are coming in helium? So I'm most excited about group-based policy. I'm shocked. I'm shocked, I know, everyone's shocked. But seriously, I think that, the paradigms and the APIs that that's proposing, I think are gonna be really exciting to application developers. And the fact that, again, like the existing OpenStack integration, it kind of lines up with what we're doing in OpenStack. I think that also makes it really attractive to people that want to run that with OpenStack as well. I would probably be, well, definitely OpenStack services were at OpenStack. That's what we're definitely laser focused on is consolidating services, not like consulting services, but like real services, network services that eventually turn into network function virtualization, kind of that long tail. But the SDNI project that got submitted the other day is pretty cool, because it's starting to think about we're creating these islands, whether it's with overlays or with underlays, but how do we start stitching those together and scale them? Because we can scale anything in networking.  Like, you chop things up and create a hierarchy. Can you describe that a little more? What is the SDNI project all about for those people who don't follow us every day? I haven't read the white paper in a while, but basically the BGP, you know, Father, Son, Holy Ghost, yeah, yeah, yeah. You have a table. What? What? Oh, I'm sorry, I'm sorry, that's not horrible. No, it's cool, it's cool. I can handle it, I can, yeah, my dad. So this SDNI was one of the ones I was gonna mention that's really kind of interesting. One of the things we haven't done in the whole SDN world is that, and so let me start like this, you know, in the early days of SDN, there was a controller. It was a centralized thing. It was a monolithic thing. We all know from our experience in doing networking all these years that in order to scale and to have resilience, you need a distributed system. So the next thing that happened, and we're still working on that by the way, but you know, the next thing people started doing was, well, how can I have clusters of controllers sort of in an intra-domain way? So the SDNI thing is trying to do federation between domains using BGP, as Brent said, but that's kind of an interesting idea. In other words, what's happening is sort of an East-West protocol is kind of emerging out of this, and that I've always been pushing for that. I mean, it's not exactly popular, especially again amongst the commercial controller vendors because that would make their controllers interoperate with other people's controllers, and of course they don't want that, you know, unless and until their customers push them there, right? So that's I think the really interesting feature of that. You know, I always liken that to saying, well, if I had ISIS or OSPF or something like that, but it couldn't interoperate with another vendor's OSPF, that's what the state of the controller world is. Personally, right, I'm happy for all the projects who are being proposed, right? I'm happy that there's a lot of traction for the Open Daylight where multiple guys wants to propose projects, but I'm one of the guys who opposed having Julian release with any features at all, right? Because Hydrogen had 1.5 million lines of code, right? In just what, in less than a year? That's crazy, right? You would never see any project out there which will have near time with 1.5 million lines of code and not much code coverage, right? So today we don't have any code coverage, frankly, right? We don't have scalable testing done, right? So personally, if you add more features and more projects to an existing code base, without proper testing and code coverage and scalability and performance, we are setting ourselves like for a bigger problem in the future, right? So you're saying there's a healthy tension within the community between people who want to build new functionality and others who want to refine the code base that already exists? So we need to find a balance there, right? That's why I'm TSEs here, the director here, right? I really want you two guys to find a way out here. I know folks are interested in adding projects. I know that, right? We cannot... I'm supposed to be grilling you on the other side. Hey, Madhu, no problem. I know. That's the answer I get there, but I want to put you in spot right here, right? Because I really want to drive this project where I know we need to bring in stability. We need to bring in some sanity inside this thing. It's exciting, of course. Two million lines of code. Oh, my God, I'm happy, right? But hey, who's testing all this, right? Where is it to be? So just to be what I'm doing for the past few months, like, we guys know that I'm not writing any new feature. All I'm doing is writing proper IT code, proper UT code, to make OBSDB is one of the OGT project, one of the best tested project where we are having, we have doctors now and everything, doing scale testing, everything, right? So I'm spending a lot of time in making sure the existing code is well tested, right? And consumable, right? If you have, once we have a baseline set, then it's easy for other projects to come in and we have baseline to hit, right? Today, there are no baselines. Anybody can come and shove in any code they want to. We are taking applications for a benevolent dictator. So I think exactly what you said actually makes a lot of sense as well, because if you look at what happened in Neutron, we went through a similar thing and in the ice house cycle, we didn't really add a ton of features at all. The entire focus on ice house was on stability, fixing a lot of issues with the gate, making sure that we had tempest test coverage for all these different scenarios and API test coverage and everything like that. And we spent pretty much the cycle, that's what we did. So there was a lot of feature stuff that was pushed out that people weren't particularly happy about per se, but it resulted in a much more stable and robust Neutron at the end of ice house. And we're gonna continue that in the Juno cycle as well. So I mean, it makes sense. The trick is trying to balance that with also letting in some features and letting things grow. I mean, it's a tricky thing. And this is where Dave comes in. I of course agree with my colleagues over here. I mean, this is by the way, this is not specific to open source. There's a tension, if you put features in your code, you're gonna get bugs, period. And these features that we're calling projects are major. So you're gonna get major bugs. What we have to do is find a way to one, strike the balance that Madhu was talking about. And two, mature our unit testing, our system and integration, and all aspects of that. And we did struggle with that during hydrogen. So I hope, I mean, I think we've learned a lot, but we are letting a lot of things in. I mean, we haven't seen the actual people who have, a couple of people have linked their project proposals to what we call the simultaneous release page, which means they wanna be in the helium release, their project, right? And I suspect that most of them will. And we'll be in a situation where we have to deal with this pretty soon. Cool. I promise I'd let people ask questions. So. First, okay. First one is actually picking up on your own questions since we're at the OpenStack Summit. It's about OpenStack versus Open Daylight. And I would like to take that now less than two levels deep. So the first level is, how do you see the division of responsibility between Open Daylight and Neutron? This is a clean-cut understanding where one starts and when one ends, okay? And the next level is, how do you decouple in terms of supporting different compute models at the end in terms of SDN? So not only VMs, right? But other compute models like containers or any other sort of compute models. Thank you. Who wants to start on that one? Two parts of the question. Well, I'll take a piece of it and then I'll turn it over to my colleagues. So I agree that there is, the division of labor is not clean right now. And it's not clean at a lot of different levels, including say like data models and things like that. So that's something that I think is rapidly evolving and an area where people are really putting a lot of at least effort thinking about what we might do. The way I kind of look at it is in an ideal world, the Open Daylight piece of it is sort of a control piece of it, right? And the OpenStack might be kind of, OpenStack and Heat and things above that will be in the orchestration domain. And so if that works out that way, that's a clean, that could be a clean separation. Right now OpenStack wants to configure parts of the network and things like that. And that's where it's kind of messy. Docker? Sorry. Docker, that's all it takes. See, okay, so there are a lot of answers to the question, right? I mean, we are looking at Docker as one of the primary, we only have a simple, we have a Docker instance container for Open Daylight as a release. That's what I'm asking for, I know. So OpenStack and Docker integration is a separate story, right? Which we cannot deal with it. I think Kyle can take that over. But Open Daylight and Docker is like, it's given, right? We don't do anything on Docker as a separate instance because for us Docker is like another instance of a southbound plugin, right? We don't really care whether it's Docker or anything else, right? So I mean, from Open Daylight standpoint, we use Docker, I mean, I use Docker a lot for testing my scale, for OBS scale testing. From a data standpoint, it's mostly OpenStack question, right? So Kyle, I'm just throwing like super quick. I mean, I've already kind of mentioned it, but I really think we need to get feature parity with Neutron today before we start boiling the ocean. So I think it makes a lot of, like let's get basics working, get them working well, start showing value and alleviating the operational pains before we, you know, let's walk before we run because we're not very good at that because we're nerds. Kyle, you're part of both communities, right? And so, I mean, certainly we're here at OpenStack and I think it was a really good question around, all right, right now it's a little messy. We heard about that. How is that gonna get resolved? How do you see the communities interacting with each other? I think, and I mentioned this actually in an earlier session today, but one of the good signs that I see is there's people on the Open Daylight side who are actually becoming OpenStack committers and are getting involved on that side as well. And I think it would be great if we see the reverse a little bit as well. We see some OpenStack people that are actually looking at Open Daylight as well so we can kind of cross-pollinate the two because that's the way that things will get better there as well, is if people are involved in both projects a little bit. I mean, I gotta say credit to you for doing that, right? I mean, you've been one of the first and probably wouldn't be in Ice House if it wasn't for what you've done on that, so it's... Teamwork. Yeah, and that's the beauty, right? It is really, I mean, you just take your vendor hat off if you're not engaging socially upstream and working as a team, not nearly as effective and certainly not as healthy for the project. If I could take a second to give you a personal answer to that, I think it has to be a dovetail model but one where I think neither project is willing to say I'm fully glued to the other dovetail which is they have to work really well together but they also have to work in use cases where the other isn't there. So there's some degree of overlap that's gonna be required to be able to work in an environment where open stack isn't there. On our side, open daylight may not always be there in every open stack deployment but for the most part, we see them as highly complimentary. First comment then to questions. The quick comment is thank you for taking a topic that's exciting and presenting it in an exciting way. So often it's not done that way. It's also cool to see a bunch of people all working together to discuss a topic in a way that actually works together nicely. So that was cool. These people are actually all friends. You may not realize this. If you can tell from the dynamic, we all like to go drinking with each other. But you antagonize them just right. You didn't give us the questions before. Kyle wouldn't be here. Yeah, I think so. It might be that the release that we're using is too old but is more grizzly based, which is old but we were running into a lot of problems with network partitioning and if anything was odd with network stuff then everything would just collapse and it made us run screaming from neutron. Any quick thoughts? You said grizzly is what you were using. Some of that work was based on more when we were doing old school grizzly stuff and some of the newer stuff we need to test more. Was this, were you using the open V-switch plugin or? I have no idea. I'm a project manager. I've spent most of my life as a programmer but the truth is I don't know some of the low levels of what I'm talking about right now. Well, I mean, the best like... You and me both. The best I could say is that, like I said earlier, there was a lot of work put into stabilizing some of the built-in neutron implementation in Icehouse. So I think that would be your best bet if you were using the open V-switch plugin, for instance. There was a lot of issues, and grizzly around scalability of the L2 agent and things like that. So I would definitely upgrade to Icehouse and look there. Test that if we still have problems, run upstream and say, hey guys. Right, right. Cool. Upstream, just to know for everybody, IRC is a fantastic place to get engaged with our community. The main IRC channel has a whole set of people, most of which aren't necessarily sitting there talking to the entire world, but it's a great way of seeing who's on and asking questions and finding people to engage with. Yep. The other quick question. So there's the Helium release coming up, and then HP just announced Helion, and are you really worried about the confusion? You know, of the things that I think are confusing, that's kind of not in the, you know, there's a little bit of a low pass filter there. That's what I'm kind of saying. So OpenStack and OpenDalight are both kind of foundational technologies, and you guys have mentioned it several times already about enabling the application developer, right? And you hear a lot about application aware networks or network aware applications, right? What is your vision, I guess, as far as bringing this to the application developer community? Is this build it and they will come or do you think it will just evolve dynamically out of the people who are already contributing? Where do you think this is gonna go? That's a great question. I mean, I think that is a really great question. So I think if you look at where the state of things are right now, and I've alluded to this before in things I've said, like look at how some of the existing controllers work in some of the constructs. We're still talking about things like ports and subnets and routers and application developers are, that's what they have to deal with. Those are the building blocks that they wanna set up, whether they're deploying a multi-tiered application on OpenStack or writing an application on top of Open Daylight or something. I think this is where things like the group-based policy abstractions help out because instead they can express their intent with the groups, they can express the contracts between the groups and things like that and they can push all of the implementation down to a layer where they don't have to worry about it necessarily. So I think it's an interesting question though around build it and will they come. We've been trying to get input from operators and things like that around this. We've heard back from a few people like Yahoo that are actually really interested in these APIs, they actually, and they're not the only ones, there's been other companies as well that have said, we'd like to see these APIs now so we can actually make use of them. So hopefully it's the case that it's not just build it and they'll come, but we get people involved early. Name dropper. But the only thing I'd add to that is it can be a tough barrier. The bar is kind of high because you've got to know like a lot of insane things about networking that we've been doing for 20 years and then also commit to code, but we're really working hard on those abstractions to kind of make it easier to come in. So we worked night and day on IRC to help with that so anybody interested? I did try to. So I'm the red act, right? So if you look at it at, we are investing on few projects, right? OpenStack, Open Daylight, also a project called OpenShift, if you've heard of it down all, right? So as you said, Open Daylight and OpenStack, they address the infrastructure service, right, IAS, but there's another layer called OpenShift which is a platform service, right? So that address the developers need really much closer, right? At the end of the day all the OpenShift also uses the OpenStack and Open Daylight as the infrastructure pieces, right? So the real question is, even though you see a developer, what does the developers need? Because if you look at OpenStack, it addresses the DevOps requirements, right? But Open Daylight addresses NetOps requirement, we can call it that way, but at the end of the day Open Daylight and OpenStack, Open Daylight's a lot of projects addresses neutron requirement, that means we are eventually addressing the DevOps requirements. Now, application program requirement can be different from DevOps requirements really, right? So that's where we have other projects which is on top of these two infrastructure services, like OpenShift as an example, which actually addresses application requirement directly, where head on, right? You don't have to worry about operating system, you don't worry about your network, you write your war file and push it in, things taking care of you. End of the day, OpenStack, Open Daylight, everything's working underneath to take care of the OpenShift requirements, yeah. You know, if I can just add something to this, I think there's always a question around when do you build infrastructure? And if we take sort of traditional infrastructure that we think about, right? You wanna make sure that you're building the roads, that you're building the railroads to support the growth of your country. But what you don't wanna end up doing, you see some places in the world, if you build way ahead and you just go out and you build airports and you hope the planes are gonna land, if the country's growth doesn't support it, you got a wide elephant. I believe there is one outside of Montreal that way where they built this beautiful airport and nobody's using it, is that right, Mathieu? Yeah. Since we have a real Quebecois here in the room. I think if you look at it, the first step that you need to do is to look at, and this is the easy step in a sense, is there something in the infrastructure that's preventing people from building what they wanna build? And if you look at networking right now, it is clear, it is clear. I used to work for a company called VMware, some of you may have heard of it. And I kept talking to customers who were saying networking is the singular thing that stands in the way of doing what we wanna do. That it comes out, I can automate the store size to some extent, I can do it a lot on the compute side, but the networking remains incredibly manual. And so I think the first answer to your question is, are we focusing on the infrastructure right now over say app developers? Absolutely, because right now that's where things are breaking down. Now once you do that, that becomes a question, which is do I continue to invest in the infrastructure solely? Or do I start thinking about how do I support other apps around it? And I think that is an important one, something that there's a lot of debates within our community. But right now, I think as Mathieu was saying earlier, let's fix the impediments to network agility. Can I comment? Yeah, so I just wanna make a kind of a meta comment on your question, which was something to the effect that one of the really cool things about the open source development paradigm and community really is that it's all bottom up, right? Or I don't know if it's everywhere, but at least in the open source communities I've been involved in. So we try to keep open daylight very bottom up. So that means users and devs build stuff that they think is useful. So we don't build stuff that nobody thinks is useful first. And if we do, it'll fall away because you won't develop a vibrant community of users and devs around it, right? So it's sort of the methodology itself that not enforces, but causes that kind of adoption. It's built in in a way, right? And so that's an incredibly powerful thing. And so we sometimes, it's not an if we build it, we only build it if somebody wants it. Great, okay, next. So again, back to this neutron and the system controller integration. So I also heard in the earlier session from you guys that RYU, for example, is another system controller that has already been integrated with OpenStack. And I hear mostly from you guys that, not directly, but kind of implying that open daylight is going to be de facto standard. At least is de facto standard today, but ultimately the goal is to become standard for OpenStack integration. So what is exactly the goal here? Do we want to have a single STN controller integrated with neutron and be promoted as the STN controller? Or so exactly, I just wanna see your thoughts on that and how you see this. That's one thing. Another thing is, is the ultimate goal having everything, basically having the STN controller business kind of below the line from users and developers perspective? Is this the ultimate goal? What do you mean by below the line? Can you expand on that a little bit? Like abstracted, kind of abstraction. So not be exposed to. Do you wanna start with the second one? I don't know what the second one was. The abstraction. Oh, okay. The controllers be below the line. Well, so the thing is, is that you know, and I was just thinking about the whole question is, and really if it doesn't become possible for other open source controllers to exist, and in fact, for the applications that you run on top of those controllers to be easily or transparently, you know, I don't know what the right term is here, ported, moved, whatever, across all of these things, that will be a failure on our part because we haven't defined the APIs that are important well enough, right? And if we don't define an east-west protocol so they can talk to each other in such a way that they can do that, I also think that will be a failure. So the idea would be like saying, there's only one ISIS implementation or something like that, right? And so my sort sense of it is that, you know, anybody who builds a competitive product in the space, once all of these, you know, product loosely defined, once, you know, all of these different things get defined by the industry, and they're implemented, I, you know, I don't see any reason why that couldn't be the case. I don't know if I got it, but. And I think I can, I mean, I can take the first part of your question as well. So, I mean, as the Neutron PTL, I'm not gonna endorse a specific open source controller, but what I will say is, if you wanna be successful as an open source implementation of the Neutron APIs, you know, your community should be engaging with the OpenStack community as well. You should have vibrant community yourself as far as contributors, people that are utilizing your software, all of these sorts of things, and certainly I think open daylight falls into that category, so I think that's good. So, even though we spoke a lot about open daylight, because Neutron is an open daylight, excuse me, I'm a director, right? We as a developer, I love RYU, right? RYU plugin, we have used RYU a lot myself, right, and the brand to, you know, to understand how it works and everything, right? We love the project, end of the day, right? What our client said makes sense, where, you know, it solves the community, right? I mean, if the community is successful and the, if it's simple to use, and if it addresses the problem, it doesn't really matter whether it's RYU, or open daylight controller, or any controller, whichever makes sense, customer's going to go towards that, right? So, I personally love it, right? I use it also as well, so yeah. The question is about community, whether you form the community around it, and how will it work with other communities is the most important thing. And yeah, I think we learned from history too. So, we're not gonna go through the Linux distribution wars probably. Again, we used to have, you know, hundreds and now we have handfuls that really make sense as far as adoption, so. Just a heads up, it is 6.30, this is supposed to be ending. I'm not sure that this is another one after us. So, if people wanna stay, I think we're happy to spend a few more minutes answering just the last few questions, but we probably should be wrapping it up in the next, you know, five or so minutes. I have actually two questions. One is about the current focus of the project, because there are multiple things we need to worry about. One is the network topology, the layout, and then how we create, and then the overlays part of it, then the policies, so there are many things. So, what is the area that is in main focus? The second part is we never touched upon one more thing. There are many vendors, actually I also work for Cisco, and we have virtualized networking switches and appliances. I'm sure Juniper and other vendors have it too. So, is there any plan on having a controller which will actually accommodate these different appliances? They bring in a lot of IPs from themselves. They have appliances that work extremely well and very compatible with an existing physical network. So, these are the two parts. All right. Well, for the second half of it, there's nothing that stops anybody from building a southbound plug-in. I hope I'm answering your question. That would talk a proprietary protocol or whatever protocol you have to whatever infrastructure you have. And that's one of the really nice things about the design of Open Daylight. It's very modular in that way. So, with respect to whether or not it could talk to whatever proprietary or non-proprietary infrastructure that's in the field, that's a question of whether or not somebody wants to build a plug-in and whatever else is needed to do it. But I think a part of the question is what about virtualized layer, 4th through layer, 7th services? Can those work? Should people use those with Open Daylight? Can I have a beer? Come on, the answer is yes. Does someone want to expand on that? Yeah, okay, yeah. Yes, yes. Jet lag? Beer lag. Yeah, I mean, honestly, 4th through L7 is a big discussion that we have. There are a lot of people doing it. It fits in very well. I think a big part of what we're doing, both in OpenStack and in Open Daylight, is going to a more abstracted model.  As executive director, I don't get to tell them what to do. I get to ask them questions and requests that they may think about. And one of the areas I do ask them, I ask them and them being the entire community, I do ask to look at how are we gonna make sure they're more L4 through L7 devices? Virtualized firewalls, virtualized, whether it's ADC or load balancer, those are all certainly part of a solution. I'd love to see people do it, but those won't get built unless people stand up and say, I'm passionate, I'm gonna build it myself. Yeah, I mean, that's kind of what I was alluding to, but you know, I said it so much more nicely, is that you could always build a plugin that talked to that or, you know, in fact, if it was OpenFlow, you can implement some of that stuff directly, right? But somebody has to have the passion, the cycles, the skill sets and all of that to actually build it. Because I do struggle with this kind of general blob that one ecosystem is gonna rule them all and everything's gonna plug in and scale. I mean, I know Madoo and I are laser focused on OpenStack integration, overlays and services. Like, that's our focus and we'll make that work. With OBS. Right, and using OBS. And that's the important part because there is primitives there for us to program that, right? So we've got. Question was, do we assume L2, L3 is present? Yeah, but you have to have a data path that you can program L2 and L3, right? So L2 is easy today. We're working on L3 right now and obviously on up, so TCP flags. I mean, you get into the bottom, you have to have a programmable data path and it's gotta be non-insane APIs to do it with. I'm gonna open APIs. It has to be open, right? So if you want to be part of OpenDelight, any sort of in-subroom plugin you was talking about, if it is proper in-subroom plugin, you can keep it yourself inside the company and then you can't open-source that, right? If you don't open-source it, part of OpenDelight, it has to be an open API that everybody can access to. And with that, I'm gonna bring this to a close. Thank you for all of you sitting through this. I know it's late and there's beer downstairs, so really appreciate it. I hope you had as much fun as I did. I hope they don't beat me up tonight before dinner.