Don’t forget to sign up for the upcoming webinar with OpenDaylight’s Colin Dixon and Neela Jacques to get an exclusive look at ODL’s newest software release, Helium, and how it aims to advance SDN.
The OpenDaylight Project’s new Technical Steering Committee chair, Colin Dixon, is a principal engineer at Brocade focused on software-defined networking (SDN) and open source, and a computer science researcher focusing on distributed systems, operating systems, and security. SDNCentral’s Roy Chua recently spoke with Dixon about how SDN and NFV are evolving, OpenDaylight’s recent Helium release, and plans already being laid for Lithium.
SDNCentral: Congratulations on your appointment as the new TSC chair!
Dixon: Thank you very much! Minor nit: I actually was elected as the TSC chair, not appointed. It sounds like a small distinction, but it’s important to note because good governance and the community guiding the project are very important for the project’s continued success. It’s an honor to have been elected.
Thanks for the clarification. Let’s start with how the SDN and NFV conversation has changed in the short span of a year. When OpenDaylight was first created, there was a lot of debate around SDN and OpenFlow and what SDN really is. How has that debate evolved since summer of last year?
I think we’ve moved from talking about SDN as a piece of new technology to talking about SDN and NFV as ways to build real solutions. If you ask me, that has a lot to do with OpenDaylight and other open source projects moving the dialogue forward in this way. We’ve advanced what’s possible to the point where we don’t have to focus as much on just getting the underlying technology to work. Instead, we can look at how you use it to solve real problems.
How do you see the linkage between SDN and NFV? Which drives which?
This is probably the only possible answer, but they both drive each other. NFV needs SDN to route traffic to and from a set of VNFs [virtual network functions]. Without the agility of SDN to change how traffic is routed, it would be difficult to take advantage of the key properties of NFV. That is, if you’re going to dynamically spin VNFs up and down as well as possibly migrate them, you’re going to also need to the agility of SDN to appropriately route traffic.
What is the role of open source in SDN and NFV? In particular, what is OpenDaylight’s role today? How has it changed in the last 18 months?
I think 18 months ago, we were really just wrapping our heads around NFV and what the implications were going to be. Today, we’re starting to have a pretty good idea of what the first steps in open source should be. Inside OpenDaylight, we’re seeing projects spinning up that cater to NFV, like service flow chaining and group-based policy.
In the last 18 months we’ve also seen the creation of OPNFV [Open Platform for NFV], which has the explicit goal of creating code inside a combination of other open-source projects including OpenDaylight and OpenStack to drive a reference implementation of an NFV platform. Right now, there’s a lot of overlap between OPNFV and OpenDaylight both in terms of companies and, more importantly, in terms of people involved.
Open source is going to play a key role in taking NFV from white papers and standards to actual deployable solutions.
What’s OpenDaylight’s relationship to NFV?
I think it’s threefold. First, OpenDaylight will provide critical agility in the network to route traffic between VNFs. Second, OpenDaylight will have policy interfaces that help drive and configure how VNFs are configured and interposed on traffic. Third, OpenDaylight might actually implement some VNFs as we’ve seen with us adding support for the LBaaS [load balancing as a service] API in Neutron.
We also want to offer congratulations to you and the team on Helium’s release this fall. From your standpoint, what was the most important milestone achieved in that release?
I think the single most important milestone we hit was showing that we could ship a second release that is more stable, of higher quality, and that involved even more community members — both in terms of companies and people. In essence, Helium shows we’re here to stay. That’s the meta-milestone we reached.
From a technical perspective, I think we’ve shown we’re willing to take on and internalize the major debates in networking as code inside OpenDaylight. The best example is around policy where you saw the group-based policy, static flow chaining, OpFlex, and OVSDB projects all start to both develop policy-oriented thinking about how to manage the network and also interact with each other to move the discussion forward.
I think this is a huge sign that OpenDaylight is really progressing on the core criteria we’ve had for demonstrating success. Seeing broad organizations from startups like Inocybe, whom you didn’t mention, to the largest IT providers in the world pick it up and use it shows that we’re providing real value as an open platform for SDN and NFV.
The next set of metrics will be seeing how they pick it up and commercialize it. I think most of us, myself included, would like to see it used in a way that ensures interoperability with the core pieces truly being OpenDaylight, and not a modified version of OpenDaylight that makes building best-of-breed solutions borrowing from different vendors harder.
I can say that Brocade is delivering our commercial offering based on unmodified OpenDaylight code with some added applications and tooling on top.
How would you compare and contrast OpenDaylight versus proprietary platforms? What are some nuances between commercial and proprietary controllers?
The commercial versions come in a variety of flavors – from those that use a few of the modules in OpenDaylight to add support for certain aspects of a solution, to those that build a custom version of OpenDaylight purpose-built for a certain use case, to essentially selling a distribution of OpenDaylight with support and some extra bells and whistles.
The result is that people will end up consuming OpenDaylight in a lot of different ways. The commercial uptake of OpenDaylight is what allows for these nuances and makes it possible for different users to consume it in the way that’s best for them.
Some people in the community have complained that OpenDaylight is getting too bloated. What’s your response to that?
We’re certainly in an “embarrassment of riches” phase right now, where we’re seeing huge increases in interest in the project in the form of code, developers, companies, and adoption. Managing that growth is a challenge that I think about every day, but I think we’re getting better at it faster than the rising of challenges growth brings.
Helium was a much bigger animal than Hydrogen was, but it was still easier to download, use, and consume than Hydrogen by a large amount. It also explicitly tackled building more streamlined custom distributions that only include the features somebody cares about by moving to [Apache] Karaf.
We’re pushing on this even more as we move into Lithium by increasing automation and trying to get more uniform coding, building, and documenting guidelines across projects. I expect we’ll see significant growth happen, and I believe any growing pains will be more than mitigated as we learn and improve our processes.
As the team gets off Helium and starts marching towards the next release, Lithium, what are the key areas of focus? What cool and new things can we expect?
We’re still in the planning space, but I expect we’ll see the policy-related efforts including group-based policy and service flow chaining deliver some cool new things. I expect we’ll also see new features in clustering for both high availability and scale-out with more support provided to applications to manage these issues to meet their needs. There’s also a big push coming from some newly proposed and existing projects to handle the diversity of switching hardware that now supports OpenFlow in a more seamless fashion so that applications don’t need to worry about it.
Want to learn more? Sign up for the exclusive webinar with OpenDaylight’s Colin Dixon and Neela Jacques to learn more about Helium and its new features.