Clik here to view.
Mike Fratto
Summary Bullets:
- The OpenDaylight project has a good start on becoming a compelling force in SDN with solid vendor support and lots of energy.
- There are some hurdles the project needs to get over and some pitfalls that could derail market acceptance.
Is the OpenDaylight project going to take the networking world by storm? It’s hard to say since the project is barely ten months old and only just shipped its first revision of controller software and applications, called Hydrogen. However, if the buzz and energy at the sold-out inaugural OpenDaylight Summit are any indication, the chances for its success are very good.
Amid the feel-good keynotes from Neela Jaques, executive director of the OpenDaylight project, and Jim Zemlin, executive director of the Linux Foundation, pointing out the collaborative nature of the community and the openness to divergent ideas were proof points showing how quickly new ideas can be tested with OpenDaylight, which may lead to new product offerings. For example, an engineer from CableLabs spent a few weeks evaluating a pre-release version of Hydrogen and noted that OpenFlow and the protocols used to manage cable modems were quite similar. He created a proof-of-concept SDN for the cable network which did not require any updates or replacements to existing cable modems using OpenDaylight, generating interest with cable operators.
That kind of rapid development from idea to proof of concept is the power of using a single code base which is modular and adaptable to your environment. For equipment vendors, this means rapid development on features which add differentiated value (applications and services) and rely on a common infrastructure. There is still room to differentiate hardware with new capabilities (I don’t think hardware is commoditized), but the demand from enterprises is changing from speeds and feeds to functionality that spans vendors and products; this is where the openness of OpenDaylight shines. By standardizing on a single code base, network vendors can focus on the applications that will drive new networking capabilities that will work across their own products as well as others.
The assumption, of course, is that other vendors will implement OpenDaylight in good faith and not try to rig their implementation to exclude others. While derivative works based on OpenDaylight have been made available according to the Eclipse Public License (EPL), other vendors do not have to implement them. There seems to be some notion that the transparency required by the EPL will expose vendors which try to make a silo and ‘the market’ will reject them, but given the plethora of Linux distributions, the market could simply shrug and adopt a preferred OpenDaylight implementation just like they standardize on a Linux distribution.
Of course, for vendors such as Alcatel-Lucent, Avaya, or HP which already have network fabric spanning the data center and campus LAN, the question is: what value does OpenDaylight provide? Using a controller to orchestrate network changes is one way, but the same functionality could be driven from an external orchestration system.
The work and momentum from the OpenDaylight project are exciting, and everyone from enterprises to vendors needs to be paying attention. Still, it has a long road to follow.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
