Open Networking foundation (ONF) Executive Director on the group's achievements, goals
- 16 September, 2014 03:44
OpenDaylight is a Linux Foundation Collaborative project that is building an Open Source SDN controller. To find out how the effort is going Network World Editor in Chief John Dix caught up with Neela Jacques, who joined the OpenDaylight project last November as Executive Director.
Where does OpenDaylight stand today?When I was considering taking this job people gave me all these reasons why OpenDaylight couldn't succeed. And I think to a large extent that's been proven wrong. It's not that the challenges aren't there. It's that with enough smart people working really hard to overcome them, they can be overcome.
Let me start by describing the elephant in the room. There have been a lot of questions about the project's governance, and specifically around Cisco's involvement. You could consider them one of the two co-founders of the project, the other being IBM, which actually drove the creation of the group. But Cisco is the leading vendor in the industry and, because they haven't been very involved in open source in the past, there are naturally questions around their involvement. "Who would collaborate with Cisco? They'll dominate every build, and everything is going to go Cisco's way."
+ ALSO ON NETWORK WORLD SDN and Network Virtualization: A Reality Check | Understanding SDN Vendor Ecosystems | Incremental SDN: Automating Network Device Configuration +
What I think surprised a lot of people is we've had very mature governance. What you've seen is a community that is growing, that is diversifying, that is really moving in the right direction. Cisco's role is still relatively large, but pretty much every month more people are joining, more projects are coming into the larger project.
So I think we represent hope in the industry, that the industry can change, both technically as well as in terms of how the members work with each other. A lot of people would like to see OpenDaylight succeed, but there is recognition of how challenging that is, so there is healthy skepticism.
OpenDaylight just recently issued the so called Hydrogen release of code. Bring us up to date.
The vast majority of people downloading the code are developers. In fact, if you look at how OpenDaylight is going to be consumed, we are first and foremost building a code-base that will act as a platform on which other people will build their solution. While you will see some people download and use OpenDaylight in Test/Dev and eventually in production, a large percentage of the consumption of OpenDaylight will be code OEM'd within a broader solution.
Cisco and IBM are examples of that, but so are ConteXtream and Ciena, companies that have a choice: do I reinvent the wheel and build the 31st controller in the world, or do I pick up a piece of code that's ready for me to use and build on top of that?
So if I compare it to Linux. Linux is in my computer, in my car, it's in a million things outside of the server room. In the same way I think a large percentage of OpenDaylight will be used and leveraged that way. You will have a few people who grab the code, compile it themselves and deploy it in their environment, but mostly for a proof of concept (POC). If an end user hears about SDN and thinks it's great, they might find themselves needing to POC 15 different solutions. Do I need an overlay? Well, you've got to look at three or four overlays out there because they all do things differently. And if you want to figure out how to use OpenFlow, well there are different flavors of OpenFlow, so you're going to pull a couple of different ones.
So with something like OpenDaylight you can very quickly kick the tires on SDN itself.
"I want to experience a couple different flavors of overlays. I want to experience what it's like programming flows as opposed to doing things with BGP the way that I have been doing it." So that's the immediate end-user use case. But frankly Hydrogen is early in its maturity cycle, and therefore I wouldn't recommend it.
Cisco is a core supporter of OpenDaylight, but then says it thinks some intelligence should remain in the switch. Doesn't that fly in the face of the bigger-picture SDN.
There's a huge debate going on in the industry. In general, everybody, including Cisco, agrees some level of intelligence needs to be centralized. The debate is how much intelligence?
One side says all the intelligence is in the center, while the other says some intelligence is in the center, but still a lot of execution intelligence is at the edge in the switches and routers. And that raises the next question, which is, if you have some level of centralized intelligence, is it imperative or not? Are you keeping all flow information centralized and then simply giving instructions, or are you instead capturing the needs of application, communicating that to the fabric, and letting the fabric make optimization decisions?
I think this is the defining debate of our industry for this decade. Will it go all one way or the other? Or will it be a combination of both? I don't think anybody knows. And unfortunately, most of the brilliant people in the industry are all employed by companies that have a lot to gain from one model versus the other, so the views they're espousing are incredibly self-serving.
But everybody agrees the network has to change. We ran a survey and found something like 95% of people think they're going to deploy SDN by the end of next year, which is ludicrous if you think of SDN the way that I do. So there's tremendous desire, yet to some extent the market is stalled because of the risk of picking the wrong solution, and this is even for the big guys. It's even riskier for the little guys.
Standards aren't going to be the way we resolve these differences. So it's either going to be all-out war among proprietary solutions, or we create a community where people can leverage code to demonstrate out the pros and cons through multiple revs of the different technologies. And this is why in OpenDaylight we have the service abstraction layer, which, I think, has been very misunderstood.
People ask the question, "If OpenFlow is the answer in the future, why would you create an abstraction layer that allows a whole bunch of old protocols and old technology to interoperate with these wonderful new methods?" And the answer is because we don't yet know whether the OpenFlow model is going to work or whether it will be something else.
Are overlays going to win or are they a transitional niche technology? We don't know. And so what we're trying to do with OpenDaylight is provide a core controller that can work with multiple models, allow them to develop over many years, leverage them. Because I don't think that the world in 15 years has eight different southbound protocols, 30 controllers, five overlays, and so on and so forth. I think there will be a shake-out. Today, however, we need that brainstorming, and that's why so much investment is going into that abstraction layer.
So OpenFlow isn't critical to the success of SDN?
Scott Shenker (a professor in the Electrical Engineering and Computer Sciences Department at UC Berkeley) talks about SDN 1.0 and SDN 2.0. And I think OpenFlow, in its first iteration, was a really, really interesting departure from the past. It was a theoretical exercise, in a sense, to turn the world of networking on its head. And I think it did its job brilliantly.
I think the ONF did their job brilliantly.
On the other hand, it's really, really hard to invent something from scratch and get it right the first time. OpenFlow 1.0, in a sense, works better in theory than it works in practice. It can solve a few narrow problems decently well, but when you start to think about deploying it in production networks, you have to optimize not for one thing, but for 15 attributes, all of which are critically important -- performance and QoS and cost and OpEx, etc. -- and what you found is OpenFlow 1.0 wasn't going to work. Like any 1.0 product or 1.0 solution.
So they revved it again and got to 1.3, and 1.3 solved some problems. But guess what happens? You know those typical regressions, you solve some problems and you create new ones. So I think OpenFlow has great promise, and it serves some really good purposes, but here's what we don't know yet. Will this evolve?
There are folks who believe it's just early and that it will evolve and we'll go to 1.5 and 1.6 and 1.7 and 1.8 and 1.9, and over time it will continue to get refined and it will be the protocol that changes the industry. You'll eventually be able to do everything with OpenFlow. And that's possible. It may do just that.
But other folks say, "Actually, no. OpenFlow was a great start. But there will be another protocol that overcomes it." And then still others that say, "Networks don't change overnight. No point in throwing the baby out with the bathwater. OpenFlow does flow programming really, really well. In parts of your network OpenFlow works great. But BGP does a great job for certain things. And we need other protocols out there. "
And the truth is we don't have one programming language in the world, we have many. It's fine that there is Java and C and Python and Ruby. Our world can deal with multiple solutions to many different problems. Networking is likely to evolve that way. What we need are systems that are able to work with and integrate with other systems.I do believe we will see a shake-out. This industry has been sleepy and has not changed for so many years, and now we're in a period of great change, which means that a lot of innovation, a lot of seeds are being planted, but not every seedling will grow into a tree. I think we will end up with a few trees. I think OpenFlow has some critical mass. I don't see OpenFlow disappearing. But I just don't know that it's going to be the silver bullet that works for everything everywhere.
You've mentioned overlay networks a few times, is network virtualization the low-hanging fruit?
I do think it is the low-hanging fruit, which is what's nice about it. It's very accessible. It appears non-disruptive. It gets you out of having a million silos in networking. And it offers the promise, I think, of a programmable network. But I don't think it solves every problem, and it creates some new problems. So I think network virtualization makes some sense, and I understand why the data center is looking at it and why it's gaining a lot of traction. But I think there is a lot more to SDN than just network virtualization.
And I think longer term we need more profound change to networking than what network virtualization brings.
Given VMware is the major proponent of that approach, why do they want to be a part of OpenDaylight?
OpenDaylight has the potential of changing the networking industry, of slowly becoming a community with the greatest minds, the biggest questions in the industry. And that can be disruptive to anybody who either makes a lot of money or has designs to make a lot of money.
And so VMware, like everybody else, has to figure out, "How do I want to participate? How many resources do I want to put in? Is this a force that I can make money from, or is it something that is going to disrupt my ways of making money?"
On the other hand, OpenDaylight and VMware have some different views of the world. OpenDaylight has some different technologies, some different players, some of which are competitors with VMware, and therefore they have to be careful in determining how much to get involved, how much to contribute. And I think that's something that's going to evolve over time.
OK, the last question. Helium is up next. Is that more than a developer release?
Hydrogen was all about getting something out, getting real code out people could leverage, showing that these technologies could work with each other, showing that these people could work with each other. The Helium release will continue to refine and evolve the existing components while adding a set of new functions and capabilities. Areas of focus for the community include stability and performance, North-Bound Policy interfaces, improved clustering and federation, further support for OpenFlow, application developer engagement, documentation, support and integration with OpenStack, and support for additional South Bound Protocols. It is scheduled to come out this fall.