We’ve had a couple of potentially significant developments in the networking space, developments that seem on the surface to be contradictory. On the one hand, big firms like IBM, Cisco, Microsoft, and Ericsson have created an open-source project for SDN development, called “Open Daylight”. This suggests wide industry support for an open SDN framework, and that’s something carriers tell me they want. On the other hand, Ericsson (one of the Open Daylight founders) has just bought Microsoft’s MediaRoom assets, which seems to be a move to establish a position in IPTV based on proprietary technology. Is there a contradiction here, and what does this say about proprietary versus open-source service software?
Ericsson has to see the Alcatel-Lucent cloud moves as a threat because it doesn’t have strong assets from which to build a cloud story, and because Alcatel-Lucent already has a content position. Remember, operators see three primary monetization targets—content, mobile/behavioral, and cloud. A strong cloud story would give Alcatel-Lucent complete coverage, and if the company can shed its long-standing silo mentality and position its stuff well, it could take market share on that combination. So Ericsson grabs up Microsoft’s content assets, which covers at least two of the three monetization bases.
So what about the Open Daylight stuff? If a competitive market demands vendors own some assets that can drive strategic engagement, why cooperate with SDN? Is SDN not strategic? Is Open Daylight not addressing a strategic piece of SDN? Is it all a sham? Maybe a bit of all of these things.
It’s not fully clear where Open Daylight will be showing the light, to start with. It’s hard to see how it would move the ball much if we presumed it’s going to be nothing more than an OpenFlow controller—we already have those. The early rumors suggest that the project will be more like a kind of official underlayment to Quantum, with functionality designed to support all of the “models” that make up Quantum in its latest (Grizzly) manifestation. All of this is helpful in an integration sense, but it’s not going to add a bunch of new features or functions. Which is why it’s worthwhile to ask what vendors gain by backing it.
The obvious benefit is that the project lets all the members put their hands on their heart and pledge allegiance to SDN, open-source software, the cloud, and probably a few other things without actually having to do very much on their own. It’s keeping a hand in the SDN process without making any specific commitments when 1) it’s probably too early to make much money on SDN at this point and 2) it’s possible that even now SDN could overhang current products and positioning.
I think there’s another factor here, though, and it’s suggested by the fact that the platinum members of Open Daylight include Citrix, IBM, Microsoft, and Red Hat—all software and IT players. I’ve said for months that the value of SDN isn’t realized at the OpenFlow level at all, it’s realized above that, in the way that network services and applications and infrastructure merge to create a new union of resources. The northbound APIs of Open Daylight will be open, open to exploit with the truly useful higher-layer stuff. The IT vendors may be seeing this as a way of putting networking back in the cage, of creating a specific boundary point where the commoditizing iron of the present meets the exploding IT value of the future. A boundary point that, of course, favors the IT types.
Don’t take this as an indication that I’m opposed to Open Daylight; I’m in favor of all carrier open-source projects for a bunch of reasons, not the least that they tend to take the otherwise-interminable standards processes out of the abstract and into the (at least more) concrete. I hope that NFV does the same thing, in fact. It’s just that all this maneuvering and defense is obscuring the fact that we still don’t have a solid notion of exactly what goes into SDN from top to bottom, what makes software-definition of network behavior uniquely valuable. We also don’t have a picture of how Open Daylight will balance OpenFlow-centralized SDN with more distributed-IP SDN. If those two converge anywhere, it’s not inside the Open Daylight corral but above it, north of those northbound APIs.
The good news here is that while it’s possible to use both standards processes and open-source projects to stall a market by obstructing progress on collective visions, it’s much harder to do it with open-source because real code is contributed and anyone can in theory pull together pieces to make something useful. But the critical piece, as I hope this blog has shown, is those northbound APIs. Framing the drivers of the SDN movement without specifying interfaces between those drivers and baseline SDN technology is futile, so it’s here at the northern border that we need to be watching for progress. Open Daylight is in the dark till it has a model for those APIs.