(Featured image: Under the shadow of Woody Allen, Kyle MacDonald waits in the lobby of New York’s W Hotel.)
Kyle MacDonald likes the OpenDaylight Project, but he’s not sure he can trust it.
It’s not a knee-jerk dislike of Cisco, IBM, and the other big companies involved. They’re some of his best industry friends, considering MacDonald is vice president of cloud for Canonical Ltd., the company that supports the Ubuntu operating system. Ubuntu sits at the heart of many a cloud project, and it’s the most popular Linux flavor on Microsoft Azure, MacDonald claims.
But MacDonald has been watching OpenDaylight, and as he explained to SDNCentral at Interop last week in New York, he’s concerned whether the consortium will give enough voice to the user community and whether OpenDaylight’s vendor members have the motivation to move at the speed the vendors (carriers, in particular) want to see.
So, MacDonald wants to create his own best-of-breed software-defined networking (SDN) framework, an alternative blessed by Ubuntu, in a sense.
“I have a list of players who make a contribution to the world comparable with what OpenDaylight is doing,” MacDonald says. “In the next 90 to 120 days, I think you could reasonably see us start making noise.”
This doesn’t mean MacDonald is dismissing OpenDaylight altogether. “If OpenDaylight gets their [act] together — if launching [Hydrogen, the code release expected in December] is what gets them on track and gets something done — I don’t have a problem picking that up,” he says.
Before the Dawn of OpenDaylight
MacDonald came up with this idea more than a year ago. Why not take the best offerings of multiple elements — maybe a white-box switch, a flow-control technology, a northbound interface — and stitch them together into an SDN framework? The recommendation would be aimed at helping the users that are drowning in vendor proposals for SDN. He ran the idea past Nicira and Big Switch, getting nods along the way, he says.
Once OpenDaylight emerged in April, offering to do the same thing, MacDonald put his idea on the back burner. “I was like, ‘Problem solved,'” he says.
But in watching the progress since then, and in reading OpenDaylight’s open-to-the-public message boards, MacDonald worried that OpenDaylight might tilt away from the right answer. On the plane flight to last week’s Interop show in New York, he decided to reignite his idea.
Part of his concern had been that OpenDaylight might not match the “cadence” of releases that Canonical has. A new Ubuntu release arrives every six months, and the deadline forces progress to be made.
OpenDaylight fully intends to work on deadlines, writes Jim Zemlin — executive director of The Linux Foundation, which is overseeing OpenDaylight — in an email to SDNCentral. “The release cycle for OpenDaylight is every six months. This is definitive,” he writes.
“There is no conspiracy with the OpenDaylight Project,” Zemlin adds. “The bylaws, license and governance for this project fundamentally protect any far-fetched conspiracy theory from transpiring,” he writes.
The Sound of 20 Consultants
But “conspiracy” isn’t quite what MacDonald is talking about; he’s looking more at a track record of how large companies behave in large groups.
“It’s like 20 McKinsey consultants all trying to out-advocacy each other,” he says. “The forcing function is really a set of users who come to the table and say, ‘I want to do this.'”
That’s why he thinks it might be better for someone like Canonical to shepherd this effort — someone that has open-source credibility and has no particular stake in the SDN race. The Linux Foundation does have the open-source street cred, which is why it was chosen to coordinate OpenDaylight, but despite all the openness built into the project’s bylaws, OpenDaylight is still a consortium started by vendors, with discussions apparently dominated by vendors.
“This begs for a solution that’s open-source. This begs for people to be very full-disclosure about what they’re working on. This begs for full interoperability and integration in a way that only Ubuntu can accomplish,” MacDonald says.
“The more the merrier,” Zemlin writes in response to the prospect of another open-source project sprouting. “The SDN landscape has gone from proprietary technologies developed by independent vendors to a landscape with open-source software projects all working towards a common goal. This might not make for sexy headlines but it certainly makes for good code.”
A Referee for SDN
MacDonald isn’t alone in worrying about vendors’ progress on SDN. Shazia Hasnie, senior director of network engineering at carrier MegaPath, is similarly concerned that vendors’ voices will out-shout users’ as SDN formulates.
“I know it’s not going to happen very soon — true SDN, not proprietary SDN,” she told SDNCentral at the Ethernet and SDN Expo show that shared space with Interop. “That’s why service providers need to be there to be the referee to make sure that the industry and the whole ecosystem keep marching towards the true SDN vision.”
Hasnie likes the ideas vendors have preached — that service delivery has to be not only more automated but also dynamic, for example, or that end users should be able to use self-service portals to tweak service-level agreements (SLA) and some elements of configuration. But she says she has doubts that vendors, particularly some frontline players, are willing to make good on that potential in an open, truly proprietary way.
“Unless there’s a holistic, integrated view of the network, some of those functionalities are not possible. Unless I can see the whole picture, I cannot suggest changes in the network,” Hasnie says.