Inside OpenDaylight: Unveiling Common Misconceptions

As a TSC member and long-time committer, I’ve fielded many misconceptions from throughout the ecosystem about OpenDaylight. In this blog, I’ll address a few of them to help the ecosystem understand what OpenDaylight is and what it is not.

OpenDaylight IS a Software Platform for SDN Applications

OpenDaylight platform exists because there is no single SDN application fulfilling every company’s needs. OpenDaylight ships standard components like YANG Tools (dynamic API generation from YANG models), HA (high-availability) clusters, AAA security, plugins for NETCONF, OpenFlow, BGP/PCEP, and more protocols. These components are used as a foundation to support SDN applications and functions. While the primary purpose is to provide this foundation, OpenDaylight also ships a few applications for common use cases (NetVirt for cloud networking, transportPCE for optical transport, etc).

OpenDaylight IS A Truly Open Source Project

By this I mean, it is not just the code, in OpenDaylight all the decisions (technical, community, governance, etc) are done in the open, all OpenDaylight meetings are handled publicly with no join requirements (Resource: https://wiki.opendaylight.org/view/Meetings), and nobody or organization has special treatment or reserved seat. Contribution is the only valid currency in OpenDaylight. 

OpenDaylight IS Governed By Developers

The Technical Steering Committee (TSC) is composed of Committers elected by the developer community. The ODL projects elect their own Committers based on contribution and meritocratic criteria. Also, the projects have full autonomy and decision on feature development, quality assurance, release plan and more. Of course, this level of freedom requires some coordination between projects as well as with other projects in the Linux Foundation Networking (LFN), e.g. to produce an ODL release.

OpenDaylight IS A Creative Endeavor

OpenDaylight runs a flexible model where developer creativity and innovation coexist with business requirements. Literally anyone can come to OpenDaylight to develop its own SDN application idea using the same processes and tools as other components more driven by user and product requirements. In the end, it is the contributor's decision to productize the application code or not.

What OpenDaylight IS NOT

OpenDaylight IS NOT Maintained by Altruist Or Independent Developers

The developer community is primarily funded by companies with a business interest in OpenDaylight from a distribution or consumption perspective. This means most of the developers in OpenDaylight are paid to do some work. But that said, we are very proud to have few independent developers contributing in their own time in our community.

OpenDaylight IS NOT a Turn-Key SDN Controller

There is some misconception, perhaps because other Open Source projects and most proprietary solutions are turn-key and tightly-integrated, that this project is also of this kind. Nothing is further from reality, the OpenDaylight controller is a software platform requiring development and integration to accommodate your specific use case. This effort generally goes in 2 places:

  • Controller Northbound: define and implement the API that best suits the SDN use case (Create optical circuits, MPLS tunnels, Ethernet Services, IP Services, etc.).
  • Controller Southbound: integrate with the network device via standard or proprietary protocol (NETCONF, BGP, PCEP, OpenFlow, etc.).

Get The Best From OpenDaylight: To garner maximum benefit from this kind of community including motivating new features, there are a few engagement options:
1. Contribute- Join the community and engage dedicated development resources to let your voice be heard and your code be used. Most projects run weekly meetings and all of them have a mail list anyone can use to reach the project contributors, asks questions, etc. (Resource: OpenDaylight Projects).
2. Partner- Work with companies that specialize in hardening and deploying Open Source projects and align to unforked code methodologies. A valuable partner should be aligned philosophically and hold leadership roles in the community to represent you and motivate projects.
3. Contract- Hire a company to write and contribute code upstream. These companies can help you acclimate to Open Source—watch and learn.
After years of watching deployments, we’ve noticed that most successes stem from a combination of the above three options. Be careful with option #3 though—Open Source is as much an operational culture as a software solution. To succeed in Open Source, it needs to be a part of your internal operations.
You’ll notice one of the options isn’t “Download and Deploy.” Open source can only thrive if you participate beyond simple consumption. Open source isn’t like placing an order from a vendor. To continue to extract value, you have to invest in it.

Ok, now that we understand what OpenDaylight is, and what it is not, let’s address some questions and misconceptions around OpenDaylight technical capabilities: 

1. ODL Cluster is not 100% HA: There are several ways to architect and deploy a cluster but one thing is clear—you cannot have consistency, availability and partition tolerance at the same time in the same distributed system (see https://en.wikipedia.org/wiki/CAP_theorem). With that said, you have to give up something. Since the controller is ultimately responsible for the network state, I would argue that data consistency and partition tolerance are more critical than 100% availability. In my experience, most networks can afford a few seconds of controller downtime (especially in the management plane), as long as the controller fully resumes operation after the downtime. However, if the data is not consistent or the controller breaks after a brain split, these problems are much harder to recover from.

2. ODL Cluster does not scale: This is again a trade-off question, if High Availability (HA) is your main concern, be ready to sacrifice performance and scalability. Data replication and strong consistency puts a big bill on the system performance and scalability due to the extra generated traffic and message routing. While you can reduce some of this overhead by tuning the cluster/shards replication, you have to be careful to not create something too complex and ultimately unmanageable. Specifically for scale, I believe there are more efficient ways to deploy the controller using multiple instances of the same application (microservice architecture). These ideas were presented and discussed during OpenDaylight Sodium DDF the Open Networking Summit (ONS) North America 2019 (https://docs.google.com/presentation/d/1gDLHyyuh8VVRpzHpTq9GDkv4XKAe3EaSbm2uGJFTiO8/edit?ts=5ca1c0b2).

3. ODL does not support network transactions involving multiple devices (NETCONF): OpenDaylight does not provide a framework for sending configuration to multiple devices, check the overall transaction integrity, do a configuration rollback in case of failure, etc. However, it is not extremely difficult to integrate with other Open Source frameworks (e.g. Camunda, Netflix conductor, etc.) allowing users to define the workflows that best suit the use case. Some ODL downstream companies (including Lumina) are already doing this and it’s probable that this integration effort can be delivered upstream.

4. ODL does not save or reconcile the device's configuration (NETCONF): While saving the device's configuration in the ODL datastore is a valid option, this may not always be the optimal solution. Some may prefer to use external Open Source and scalable database stores like MariaDB or ElasticSearch. As far as reconciling the stored configuration with the network configuration, this is SDN application responsibility and use case-specific, as it depends on which kind of network, device, vendor and more.

5. ODL does not provide generic PCE application: OpenDaylight does not provide a generic PCE application to compute paths based on a graph/topology. Some ODL SDN applications like TransportPCE implement their own PCE function and OpenDaylight downstream companies like Lumina provide this functionality on their own or through third-party SW. I believe a generic PCE component providing just path computation services (skip specific path implementation) for the existing ODL-supported topologies (e.g. BGP-LS, OpenFlow, etc.) would make a lot of sense. This could be a new project in OpenDaylight if someone was interested in doing the work.

6. ODL Logs are not useful to troubleshoot network problems: For the most part, OpenDaylight provides internal and system-level logs which are not highly useful for troubleshooting network problems. That said and as we mentioned earlier, ODL is a software platform and it is normally the SDN application’s responsibility to provide useful logs to the user. I know from a Lumina perspective this is absolutely true as we put a lot of effort into our SDN applications to support relevant logs. When all is said and done, OpenDaylight is still the best open source SDN controller platform in the market. The community is larger than any other project with over 1,000+ contributors and 5,000 members over the project's life. And with over 1 billion subscribers, the project is clearly on the right path. That said, as the #1 commercially deployed vendor, Lumina has learned a lot about how to deploy this platform while addressing some of the questions above.

Read more about how we're addressing these areas in our blog Open Source SDN Control: To DIY or NOT to DIY.

To see a demo of how the Lumina distribution of OpenDaylight can accelerate your digital transformation, contact us and reference our Solutions page for specific capabilities of the Lumina portfolio.