Editorial StaffAs OpenDaylight makes progress towards spurring adoption of SDN and NFV via an open platform, we asked Executive Director Neela Jacques his latest thoughts on the project’s current status, the state of SDN management,
and what’s next.
1. For people who may not be familiar with OpenDaylight, what is your mission?
OpenDaylight is an open source project that is creating a common, open platform for SDN and NFV. We’re a community of developers uniting competitors to work collaboratively to overcome networking’s toughest challenge — technology fragmentation and duplication. By creating an open codebase for SDN and NFV, OpenDaylight is a vehicle for vendors to build their unique products, service and support offerings on top of a common, core set of
technologies.
2. Do you feel like the move toward open SDN has reached a critical mass? When and how do you see that happening?
In less than 15 months since we formed, OpenDaylight has grown to include 39 member companies and more than 220 developers that are working to unify the networking industry around a common, open, standard code base. By internalizing key industry debates, working collaboratively and using code as the primary vehicle for agreement, OpenDaylight is driving broad acceptance for open SDN and NFV solutions.
We’re seeing more and more proof that the industry is evolving from building SDN solutions based on their own proprietary technology to solutions with an open core like OpenDaylight.
3. Traditional management tools cannot provide visibility into dynamic SDN environments, but this issue is largely being ignored right now since it is the infrastructure vendors driving SDN rather than the management vendors. Where does OpenDaylight see management in the hierarchy of SDN needs?
Management tools have always followed capabilities. The reason we haven’t seen mature SDN management is that it is still early for SDN. We don’t have any one technology, approach or platform that has been accepted by all, or even most, as the dominant platform. As a result, we have a hodge podge of management tools, typically tightly linked to one vendor’s proprietary solution. With a significant set of OpenDaylight-based solutions likely to come to market in late 2014 and 2015, and increasing industry adoption of OpenDaylight as the defacto standard for SDN, I believe we will see great innovation in the sphere of (networking) management – both from existing vendors and from the startup community.
4. Packet Design recently completed our first integration with the OpenDaylight controller. This is part of our plan for a “Network Access Broker” that will verify if the network can handle the routing and traffic demands of SDN applications without impacting other applications adversely. What other developments do you see happening in SDN management?
It’s great to see OpenDaylight integrated in Packet Design’s Route Explorer System to simplify SDN management for customers. This is exactly why OpenDaylight was created — to serve as a platform that can be picked up and built upon for abroad stroke of use cases.
I believe one of the first places we will see innovation from a management perspective is in NFV. It is clear that carriers are looking to move from physical appliances to virtualized services, but that’s not the end game. It is the ability to dynamically monitor the needs of the network and reprogram the network on the fly to meet changing needs that is the killer app. I think we will see some very interesting innovations at the intersection of capabilities like service chaining and network management.
Overall, I am a strong believer that as you move from the physical to the virtual you unlock the ability for greater levels of automation. Dave Meyer (OpenDaylight Technical Steering Committee chair) and I share a view that we are likely to see artificial intelligence/neural net based network orchestration appear once the base capabilities mature.
5. You released Hydrogen – your first software release – in February. How has the adoption been? Is anyone using it in production deployments and in what capacity?
OpenDaylight’s Hydrogen release was always intended as a primarily developer release and the next release, Helium, will be too. Since the first problem we are trying to solve is to overcome industry fragmentation, the goal was to
provide a code base that developers could pick and develop against. We certainly did expect forward thinking organizations (enterprises, service providers, etc.) to pick up the release, kick the tires and explore SDN, and we
are certainly seeing that. I wouldn’t expect anyone to be running Hydrogen in production and, frankly, expect the majority who experience Helium to do so via a vendor supported offering.
Cisco, IBM and Ciena were early to see the value of building on top of OpenDaylight. Inocybe has released a commercial distribution of OpenDaylight’s first software release, Hydrogen, while ConteXtream is leveraging OpenDaylight within their service provider-focused solution. Extreme Networks is starting to market what it calls “the first hardened implementation of OpenDaylight’s controller available today.” OpenDaylight’s ability to easily integrate with other solutions — like OpenStack cloud architectures — has been appealing to companies like Oracle
who are using OpenDaylight in their immediate product roadmap. HP has also expressed plans to use OpenDaylight code base in its products.
6. Your next release (Helium) is coming in the fall. What features are you most excited about?
More than specific features, I am really excited to see the industry working together and investing ever greater resources in open source SDN rather than building proprietary solutions. We have seen the number of developers as well as projects roughly double between releases, which is just awesome! One general area I find exciting is that the community is starting to tackle the question of policy-based management in Helium. I think this is a critical capability. The Group Policy and OpFlex projects are certainly an interesting start here and accompany similar projects in OpenStack. Some may know there is a related OpenStack project called Congress currently being considered. While the two projects are not identical, I think there is room for greater collaboration between all the groups interested in policy-based management and orchestration.
7. The data center and service provider versions of Hydrogen are different (No UI in the service provider version, for example). Do you still see two distinct versions in the future and for how much longer?
That’s a great question and in fact there’s a major discussion happening right now around how to make OpenDaylight easier to implement by using something called Karaf. It would simplify the installation process in that a user could pick and choose which components and capabilities of OpenDaylight they want versus releasing different editions. There are a lot of types of networks and lots of use cases for management in an SDN environment. Instead of trying to guess what any given user is going to want to use, we’re letting them pick and choose what they want. We want to help anyone who’s kicking tires of SDN to be able to do that as easily as possible, and Karaf will help make this possible.
8. Why is open source the best approach for creating SDN and NFV standards?
The current rate of SDN and NFV adoption is low because the industry can’t come to an agreement on the ‘best’ path forward. Open source provides a means for the industry to find resolution and overcome interoperability challenges through collaborative code creation and a pace of innovation that simply can’t be achieved in silos. Because software development occurs in the open, anyone can come to the table to offer ideas and help shape the scope for better quality code. OpenDaylight dovetails very well with standards efforts but to solve the challenge of SDN and NFV, we need actual software that has the ability to adapt and evolve as the industry does.
Add comment