In late March, OpenDaylight celebrated its sixth anniversary and debuted its most recent release, dubbed Neon.

OpenDaylight was launched in 2013, and was the Linux Foundation’s inaugural networking project. “Its most interesting characteristic was the fact that it built a platform that acts as an abstraction between applications and services that connect to a variety of different networking protocols,” said Philip Robb, vice president of operations, orchestration, and networking at the Linux Foundation. Robb has been involved with OpenDaylight since the beginning.

“Having a model-driven architecture like that was really something that allowed for the creation of a platform so that anybody that wants to come to your community to get something done, can get it done,” said Robb.

Over the years the project has grown and evolved, Neon being its tenth release. OpenDaylight now boasts more than 1,000 authors and submitters and claims to power networks that serve more than 1 billion subscribers. Some of its prominent adopters include AT&T, Tencent, Orange, CableLabs, Ericsson, Verizon, and China Mobile.

“The product does just continue to grow. It’s to the point where it’s now a cog to larger machines as we continue to build out the networking specs that are necessary to be able to do next-generation networking, as well as 5G,” Robb said.

All of OpenDaylight’s releases are named after elements. Neon added features that support modern networking use cases, including optical transport networking, WAN connectivity and routing, and virtual networking in cloud and edge deployments.

The group built on its features for network virtualization, optical transport infrastructure control, WAN connectivity (by adding a BGP CEP function), stability, and reliability. This included function enhancements and bug fixes that allow OpenDaylight to be used by both vendors and downstream open projects to put together projects and platforms around the controller.

It also added more MPLS security features, Robb explained, because this was a feature that one of its downstream projects was looking for.

That project was the Open Network Automation Platform (ONAP). While OpenDaylight has become a component in many organizations, Robb said that one of the most important applications was its integration with ONAP.

“The ubiquity of what ONAP is turning out to be” has made it the most common application for the controller, Robb said, adding that ONAP makes up 77 percent of OpenDaylight’s worldwide subscribers activity in the project.

“We play an interesting role in ONAP,” he said, noting that while it is also a direct SD-WAN controller, ONAP used OpenDaylight’s architecture and code to define the abstraction for its own application and SDN controllers. “There are a couple of very tight synergies there,” Robb said.

The end-users that are driving OpenDaylight have built applications that are pushing toward an application-driven platform, Robb noted, citing one of the initial promises of OpenDaylight. “We have ended up putting a lot of energy for managing applications that are VNFs [virtual network functions], which is really the next step of automation for carriers,” he said.

ONAP helps with this. The applications sit on top of ONAP and then rely on the OpenDaylight controller to thread the traffic. So while ONAP can spin up virtual machines (VMs) and Kubernetes pods, it feeds the telemetry data through the controller into an analytics engine.

“I see OpenDaylight as that critical Pogue in how do you thread traffic that sites on top of that larger orchestration engine,” Robb said.

There has been some criticism that OpenDaylight, and SDN controllers in general, has lost some of its luster.

Roy Chua, founder and principal analyst at AvidThink, in a recent analyst post on SDxCentral lamented the dying hype of SDN controllers. “OpenDaylight continues to march along and do its job," Chua wrote in an email response to questions from SDxCentral. "It adds value to the overall ecosystem but certainly not at the level of hype that was there a few years ago.”

The hype, Chua says, was tied to the notion that SDN controllers would transform networking and create a new applications-driven platform, “but that wasn't the case back then and unlikely to be the case in the near future.”

According to Chua, some of the luster lost was due to the business model of SDN controllers. “The customers were mostly not ready to transform to an SDN network,” he said, adding that with networking, it's hard to transform only a portion of your network, “The interconnectedness of networking made it hard.”

“Back in 2013/2014 [OpenDaylight] kind of thought that the need to have an application ecosystem that directly interfaces with an SDN control was really something that was going to be important,” Robb said. “What we found was there were certainly applications that worked directly with OpenDaylight, but as we look at NFV in particular it’s clear that it’s going to be an orchestration platform like ONAP that is doing all of the things required to know exactly the status of everything from your infrastructure management layers through the VNFs that are running on top of those virtual machines or through those managed containers.”

OpenDaylight stays relevant, according to Robb, on the backs of its end-users and its downstream projects, including ONAP, Akraino Edge Stack, Kubernetes, OpenStack, and OPNFV. “As we continue to watch new and interesting innovations happen in other areas of software development and in the software ecosystem, it will pivot to support that,” he said.

Chua said that OpenDaylight will definitely remain relevant. “It still has enough momentum and proponents and value that it will continue to march on,” he said. “In terms of further success, I think it will depend on the relevance to 5G and edge deployments, and whether the architecture is a fit for those deployments.”