You know, the more you consider the strategic importance of the OpenDaylight project to the vendors involved, the more it becomes apparent: Daylight is defensively strategic to those who seek to marginalize the impact of SDNs in general, and of OpenFlow in particular.
OpenDaylight was formed by Cisco and IBM and stocked with other data center server and hardware vendors ostensibly to develop an open source OpenFlow controller. The intent, according to OpenDaylight founders, is to encourage an ecosystem of SDN application developers.
But when you consider the implications of SDNs and OpenFlow, and that this group is spilling over with network hardware vendors likely to be affected by them, the application ecosystem story morphs into something more urgent from a business perspective. Rather than taking the offense in encouraging an application ecosystem, OpenDaylight is a defensive maneuver to dampen the potential of OpenFlow and SDNs to usher in a "white-box" upheaval of network infrastructure as a virtualized commodity founded on merchant silicon-based switches all speaking one standard language - OpenFlow - to take software-executed directives from a controller decoupled from the switch forwarding plane.
[SOFTWARE-DEFINED WHAT?: Move over SDN; startup looking to go where only Cisco, VMware tread]
It's obvious that OpenDaylight seeks to wrest the "standards-based" OpenFlow controller designation from any other entity or company. Any OpenFlow controller that does not adhere to the OpenDaylight architecture could be deemed "non-standard" by the consortium of (mostly) network hardware vendors. Hardware vendors dictating software standards. Think about that...
But here are some points to consider that were offered by a reader after considering the OpenDaylight proposal. They seem to make a lot of sense and some are spot on, IMO.
Offering OpenFlow controller code through open source, though not new - there are several open source-based SDN controllers available for download - could be a way for OpenDaylight vendors to drop price out of the market and make money through post-sales service and support hand holding. There should be tons of service and support opportunity with enterprises and services providers dipping their toes into SDN; perhaps only those companies with an arsenal of post-sales service and support personnel - Cisco? IBM? HP? - would be attractive to first-time SDN customers, especially if they were also offering "standard" open source OpenFlow through OpenDaylight.
So instead of expanding the market, OpenDaylight appears to be narrowing the market.
But to look at it from the hardware vendors' perspective, they have the underlying infrastructure. The SDN companies, like Big Switch and VMware/Nicira -- both of which are OpenDaylight participants -- have the controllers. And there are new SDN companies being born weekly. If hardware companies have no plans to acquire a smaller SDN company - like VMware did with Nicira - they're left expending software development resources, interoperability testing resources, and joint sales and marketing resources on potentially numerous SDN controllers.
Now, they can just focus those resources on their own unique SDN architectures while soothing tentative customers with the open source "standard" OpenDaylight controller they all collaborated on for the good of the industry :) And with depths of service and support to aid them should they falter.
And if Cisco's ONE controller turns out to be the guts of OpenDaylight, as expected, Cisco can claim its own Cisco ONE controller for its onePK programmable networking play is the foundation of the open source "standard," much like Big Switch touts the open source Floodlight roots of its own controller.
So the SDN customer now has a choice to make: cheaper networking through OpenFlow and white box hardware; or the service and support assistance with SDN from the large hardware vendors if you buy their more expensive boxes... and software... and controllers. OpenDaylight is an enticement for the latter. It's an attempt to stave off OpenFlow's commoditization of network hardware by neutralizing OpenFlow itself.
More from Cisco Subnet:Cisco Subnet bloggers on Twitter.Jim Duffy on Twitter