Today's announcement from OpenDaylight on the second generation of its open source controller for software-defined networking (SDN), known as Helium, is a significant step forward for this organization and for open source as a method of getting the next generation of networking -- The New IP -- to market faster. (See OpenDaylight Releases Major 'Helium' Upgrade.)
Compared to previous telecom industry standards processes, OpenDaylight is moving at warp speed -- if that really existed -- to produce a commercially deployable version of a critical piece of SDN gear. Just as important as the new features included in the more mature package of code that is Helium, is the way the process itself is maturing. Now the challenge will be to see if it can stay on course. (See OpenDaylight Unveils Open-Source SDN Controller.)
Hydrogen, the first OpenDaylight release, came out 10 months after the group was founded. It was a stake in the ground, admits Executive Director Neela Jacques -- proof that the organization could bring the right people to the table and get them to commit code to getting an open source SDN controller to work. With that success came increased expectations, but also increased participation as more industry players began to see OpenDaylight as a significant force in the virtualization realm. (See What OpenDaylight Really Wants to Do.)
Six months after Hydogen comes Helium, which builds on the Hydrogen code base but is more mature. "It has fewer bugs, it is architected in a better way and we've changed the way it's packaged," he comments. "We also have increased the resources. There are twice as many projects. We now have a couple hundred developers who have worked on Open Daylight to increase the functionality, some of which is immediately usable and some is for the longer term."
The fact that Brocade Communications Systems Inc. (Nasdaq: BRCD) announced its new controller, built on Hydrogen, is a significant proof point, Jacques says.
"A year and a half ago, all solutions were proprietary -- we began saying there is another way, and Brocade is proof of that," he says.
As Brocade CEO Lloyd Carney made clear at his company's investor day in New York City last week, the vendor is going all-in on open source SDN because it can. Unlike rivals such as Cisco Systems Inc. (Nasdaq: CSCO) and Juniper Networks Inc. (NYSE: JNPR), Brocade has no skin in the proprietary game, and isn't putting any existing revenue at risk by building its new products as open source. (See Brocade CEO: Hybrid Public-Private Cloud Makes Sense for Businesses.)
A fork in the road?
Just by being out there with its new controller, Brocade has upped the ante for the competition, which could produce benefits for the service provider community.
The ideal situation for SDN deployments, Jacques admits, is open source-based deployments with vendor support. Network operators investing billions into a new infrastructure aren't going to come running back to an open source community with questions or problems. They are going to turn to their vendors, as they do today, for support and solutions.
So here is where it gets interesting, and where we'll get a key indicator of OpenDaylight's future. Will other vendors step up, as Brocade has, and build their SDN future on open source, or will they try to mitigate, in some way, the impact of OpenDaylight's work?
There are multiple ways to do that. One is to have multiple controllers, one based on open source and another with proprietary features. Ericsson AB (Nasdaq: ERIC) is one company that comes to mind with this strategy. The challenge is to determine where the company's resources are used going forward, and whether the open source controller earns the favored child status or is left with the crumbs.
A second way is to start with open source and then "fork" it -- add proprietary features or wrappers to an open source core that aren't contributed back into the open source community for use by others. This approach is common to the telecom industry, it's what vendors have done with other standards for years -- take the standard and add "enhancements" which make interoperability difficult if not impossible and lock network operators into buying add-ons such as management systems specific to one vendor
If network operators are willing to accept a forked approach because they see it as safer or a faster move to the market, then OpenDaylight loses. And the industry does as well.
Getting policy right
There are other challenges for OpenDaylight as well as its work continues with the goal of getting Lithium, the next version, out in six months. There are significant issues to be resolved and these resolutions only get tougher.
Jacques and Colin Dixon, committer-at-large on the OpenDaylight Technical Steering Committee and principal engineer at Brocade, both spoke about one such issue: how to handle policy.
Policy is critical because it will enable services to be handled appropriately -- please don't sharpen your net neutrality knives here, people -- so that different types of traffic get the priority they need for latency, security or other reasons. Without the ability to implement policy, SDN loses a lot of its interesting capabilities for managing network resources in a dynamic fashion.
But the industry already has multiple ways to handle policy. There is group-based policy, much of the code for which was contributed by Cisco, and there is the policy version being developed by Congress, an OpenStack project. Group-based policy management requires a piece of smart hardware on which to run, and right now that looks an awful lot like the Cisco Nexus 9000 switch.
So one of the challenges for OpenDaylight will be to determine how to best implement one or the other or both approaches.
"Right now, the group-based policy project has two different southbounds -- it can work using use (Cisco's) OpFlex or OpenFlow," Dixon says. "We in the community are able to talk about and reason about problems like do you want to assume you have very smart hardware, or do you want to have smart software and a controller which let you use dumb hardware or at least program OpenFlow with very simple rules? I don't have the answer as to which one will prove out. Code in OpenDaylight will be the best place to go find that answer."
Both Dixon and Jacques would like to see anyone with interest in seeing how policy plays out in Lithium to get involved with the policy project group within OpenDaylight -- and by get involved, they mean bring code. In specific, Jacques is hoping those participating in Congress will join the effort.
"If we have a policy model in OpenDaylight that looks exactly like (Cisco's) ACI, then we will have failed our purpose," he says. "Not that I have a problem with that but there is different hardware and different views and we are so much richer when different people join. I expect we will see more debate in OpenDaylight and the way we debate is with code."
Dixon's spin is a bit more succinct: "More community is more better."
— Carol Wilson, Editor-at-Large, Light Reading