The software-defined networking industry is sharply divided over the open source OpenDaylight Project. Some say OpenDaylight is a ruse by incumbent vendors to protect the value of their high-margin, proprietary technologies. Others see it as an honest effort to build the open source software foundation for a new industry.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The technical steering committee (TSC) of the OpenDaylight Project has the final say on what software is adopted as core technology, and its decisions will determine which camp is right. The industry is watching the TSC closely to make sure its technology decisions are truly meritocratic. Some vendors and industry analysts have expressed concern that the TSC will bend to the will of powerful vendors like Cisco, IBM and their allies.
David Meyer, chief technology officer and chief scientist at Brocade, was recently elected chairman of the TSC. He agreed to speak by phone with us about how the TSC will strive to deliver technology that the whole industry can get behind.
What steps are you taking to ensure transparency for OpenDaylight and the TSC?
David Meyer: There was a two-day workshop [in the early days of OpenDaylight] where the [involvement of] instigators of [the project] -- Cisco, IBM, Citrix and to a lesser extent NEC -- [prompted some] contentious moments that led to this perception of, "Oh, is this open?" This had to do with contention over what was going to be the basic controller code. So at the first technical steering committee meeting phone call there was a heated exchange about this.
What I decided at that moment was that everything the TSC does -- unless it involves either contractual or other legal IP [intellectual property] issues that should not be discussed in open -- is open. The TSC mailing list is open for everyone subscribe to. The TSC weekly calls are open to everyone. We just had a call and there were 30 people who joined who weren't TSC members. My hope is that sunlight, no pun intended, will be the best disinfection. It's met with varying degrees of skepticism from various people, but there is no other way to shine light on this.
Cisco and Big Switch are both pushing for their SDN controllers to be considered as core technology. How are you going to resolve this conflict?
Meyer: We've talked about various kinds of mechanisms and techniques that have been used in other open source communities because [there have] been other open source communities that have more than one code base competing for the same functionality. But at the end of the day, we need just one. It would be a disaster if we had two Apaches or two BINDs. We have to move quickly on that.
We're in a little bit of a unique situation because generally in an open source project it's really a bottom-up thing. You have developers that are motivated because you have something you [are passionate] about. So you write code and you build the project right from the bottom-up. That's the beautiful part of it.
Here we have combination of some top-down and some bottom-up. And we have a published deliverable for Q3 [that] makes this a little bit different. Generally, [open source projects] don't put timeframes on releases because [they are] driven by developer interest. In the open source world you can't make the guy or woman who is a kernel wizard do something in some timeframe that they're not prepared to deal with.
What's the short-term agenda for the TSC?
Meyer: We'd like to have a code drop that would be a working system and that has some functionality that people could actually use. A controller is notably a core piece of all this, but a controller alone is not a usable system.
We're working out scope of the Q3 deliverable right now. This is not intended to be [an official] description -- but so you can understand what we have in mind -- we need the controller as a piece of the core infrastructure. Then southbound from the controller will have protocol plug-ins to talk to physical and virtual resources that are compute, storage and network. There is one that is there today, OpenFlow 1.0., but others might be OpenFlow 1.3, I2RS [interface to the routing system], BGP-LS, NetConf, SNMP, vendor SDKs; all those things.
On the northbound side, there is an OSGI [Open Services Gateway Initiative] that is for building model-driven APIs [application programming interfaces], so you don't have to lock up what an API looks like, but can lock up what the modeling language looks like. And then you can hand that model to some set of tool chains that can generate that for you. Then you want some nice apps that can demonstrate the power of the system. So that's what we're shooting for: to have basic a controller, a few southbounds and a few nice apps, so people can understand how to build product around this; how to use it in their network; what the real power of it is.
How will the TSC evolve over time?
Meyer: The Platinum members got seats on the board and got to appoint a person to the TSC, so the current TSC is comprised of Platinum member appointees. That's simply a bootstrap process. In a mature open source community, what you really want is the TSC to be comprised of the technical leads of the projects that are core to the overall project.
I don't think in the long term I'm going to be the chair. The chair of the TSC should be someone who is a representative of one of the core projects and is actually a developer. That's what you see in OpenStack or any major, successful open source project. Right now my job is not only technical, but also involves shepherding the creation of this [mature TSC].
What's your assessment of how OpenDaylight fits together with the rest of the software-defined networking (SDN) ecosystem, particularly the Open Networking Foundation (ONF), the Internet Research Task Force (IRTF) and other research and standardization efforts?
Meyer: To the extent that the ONF is building and standardizing OpenFlow, that's a perfect fit. We need that protocol as a southbound plug-in.
In the IRTF, where I'm chair of the SDN research group, that's really about what is the research agenda around SDN, which is a little bit of a different thing. It's looking a little further out, because it's building things like I2RS, BGP-LS, ALTO -- things that would also be reasonable northbound/southbound combinations.
Remember, [OpenDaylight] is not an SDO [standards developing organization]. If you do it right, you kind of build a de facto standard like OpenStack Quantum. The idea is if people start using it, then it will be refined by the open source community. If you ever need to standardize it in the future, you can always do that, but it's not required.
Some participating vendors are putting out conflicting messages about OpenDayligtht. They claim the intent is for incumbents to squeeze out the startups. Do you think that creates a perception problem?
Meyer: My approach is to be completely open. We as a consortium cannot control what people say in the press. That's not something that we can deal with. The ultimate success will be to have great code that people can use and then it ultimately doesn't really matter. Everyone has their commercial interests, or whatever other interests they have, but at end of day, good code wins.
The OpenDaylight thing has got this bumpy start where one or more of the members have done what you've said, but it's also got a lot of inertia already. If we can harness that inertia and the passion and talent of people here, we can build something spectacularly useful for the community. We're trying to build a fundamental piece of infrastructure for the Internet on top of which people can build new businesses, new services, and try their ideas, just like OpenStack, BIND or Apache. If there were two Apaches or two competing HTTP/HTTPS servers, that would have been damaging for the industry and the Internet. We don’t want see that happen.
Let us know what you think about the story; email: Shamus McGillicuddy, news director.