Define your network in software with OpenDaylight

No readers like this yet.
A network of people

For years, the traditional model in networking was for much of the work to be done in hardware. But with the rise of cloud computing and virtualization, and the need for networks to become more agile and flexible than ever, a trend is beginning to take hold to take networking in the same direction that computing has gone. We are seeing more and more that the networking functions traditionally done in the datacenter by dedicated, almost exclusively proprietary hardware and software combinations, are now being defined through software.

Leading that charge within the open source community has been the OpenDaylight Project, a collaborative project through the Linux Foundation working to define the needs which software defined networking may fill and coordinating the efforts of individuals and companies worldwide to create an open source solution to software defined networking (SDN).

Software defined networking is an essential component of OpenStack, and the OpenDaylight Project and OpenStack are working on many complimentary goals to make sure that OpenDaylight can provide an SDN backbone to OpenStack. A hot topic at the OpenStack Summit in Atlanta earlier this month, OpenDaylight community members are working to ensure that OpenDaylight can effectively integrate with Neutron, the primary networking component of OpenStack.

During OpenStack Summit, I sat down with Neela Jacques, Executive Director of the OpenDaylight Project, to learn a little bit more about the project and where it is headed.

How did OpenDaylight come about? What was happening in the industry before OpenDaylight came along?

There's a trend happening in general in the industry toward a more automated datacenter, and more automated IT in general. You see compute get ever more abstracted, ever more virtualized, and also more automated. You're starting to see the same thing with storage. Everybody's talking now about software defined storage. Networking, though, has been the part of the industry, the part of the infrastructure, that's in a sense the most behind in that trend. It's still for the most part manual in the way that it was fifteen or twenty years ago. That's true in general, and that's here true at the OpenStack Summit. And so what you start finding is that the industry is all agreeing with each other that we needed SDN. I'm going to define SDN in a very loose way as the following, which is, we have a need to consolidate intelligence away from the hardware to some extent.

The problem that we have is that everybody is building their own version of that. The result that we've had is actually somewhat unfortunate. The result is that we've got 30-40 SDN controllers. They all roughly do the same thing, undifferentiated, in slightly different ways, which means that we don't have interoperability. What you've got is a fifteen horse race where customers don't really want to pick a horse. Network admins don't wake up and say "I want to take a chance on my infrastructure."

People look at this and they say "we need a platform" and ask what are the options for a platforms out there... So OpenDaylight is a creation of many of the top developers across the industry, who go together and said "we need a common platform that nobody owns." IBM is really the father of OpenDaylight... So IBM went out and asked, "hey guys in the industry, are you interested in building with us a common platform, and we've got to do it in open source because a standard isn't enough." And so they did, and they started building a coalition of the willing. They asked how they could convince people that this isn't just an IBM project or a Cisco project or a Big Switch project or a Juniper project, and show the world that it's legitimate. There were really two options, do it under Apache or do it under the Linux Foundation, and they chose the Linux Foundation.

So that's what OpenDaylight is: it's a common platform and a common code base for software defined networking, and it builds a foundation for network functions virtualization (NFV), which is a huge thing on the carrier side. It is meant to be a code base that people in the industry pick up and build into their own OEM commercial products, or something that people can install and use on their own, a la Linux for example. We've got both goals, but the key goal that's behind it all is to allow for network interoperability in a way that works with everything.

Where is OpenDaylight right now, in terms of development and release?

We just got to our first year anniversary. The real first question that a lot of people asked was if we could get code out the door, or even before code, could we get these people working with each other? We passed that in February when we had our first release of Hydrogen. So the progress is actually pretty impressive. What we're trying to do is very, very difficult. A lot of people doubted. If you go back and pull out the press from a year ago, there were a million people who gave a hundred reasons why this might not happen. Every issue that they brought up is a real issue, and they're all hard issues, but we were able to conquer a bunch of them.

One of the focuses of this OpenStack Summit has been the focus on getting operator feedback to improve the OpenStack development process. Do you think there is a lesson to be learned for OpenDaylight about focusing on users early in the process?

There's two answers I could give on this one. There is a fundamental difference between OpenStack and OpenDaylight; OpenStack is trying to create something that is brand new to the world. They got a whole bunch of folks together, the requirements weren't there, and I think you're right, and it took a little bit longer than it could have to get others involved. If you look at OpenDaylight, there are a whole bunch of SDNs. The problem isn't that there aren't SDN solutions, but in terms of a controller, you don't really need to go to an end user and ask what does a controller need to do. You actually need to go to a developer, someone who's building a network function, because in fact most customers don't care about a controller. What they care about is the network function.

The second thing I would say, from the carrier side, is that they actually did a lot of the work for us. They wrote down in their whitepapers what they wanted from NFV and they wrote down the use cases. I should add one more, there's an organization called the ONF (Open Networking Foundation). The ONF has gone out and worked on it, so in the early days, I think the view from the developer community is that we have enough to build something that end users can react to. However, you're absolutely right, we need to get end users and we've already had end user plugged in. And so we are launching the first OpenDaylight user group specifically aimed at network architects.

What's been your experience so far at OpenStack Summit?

This is my first OpenStack Summit so I have nothing to compare it to, to be honest. But the comment I've heard from a lot of people is that this show is very different, and people always seem to talk about the Portland summit. It sounds like Portland was all about the enthusiasts, and that there was something wonderful about being a small group, the rest of the world doesn't know who we are, and there was a fraternity, a brotherhood that existed. And there's a feeling that there's less of that here. I actually think that that's positive. The sense that I get here is that we've got a wider range of folks. I do think that there's still an element of "when are the users going to show up?" The truth is that on the non-consumer side, on the enterprise space, things don't get adopted that fast. Yes, Blackberries get dropped and iPhones come, but even then that's a four year period. I think it's actually unfair to have an expectation that you would have three thousand users here. I've actually seen people from many major corporations coming and looking, some of them are early and some of them are late.

User profile image.
Jason was an staff member and Red Hatter from 2013 to 2022. This profile contains his work-related articles from that time. Other contributions can be found on his personal account.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.