[OpenDaylight] How we brought gNMI to OpenDaylight and opened new possibilities

Networking acronyms are designed to keep us employed, but gNMI is one of the few actually worth the headache. For decades, managing a network was full of unknowns – you wouldn’t know of a critical issue, until the next morning. Imagine gNMI, a protocol for configuring and monitoring network devices, missing from such a crucial project like OpenDaylight. 

That is why PANTHEON.tech brought gNMI to OpenDaylight. More visibility, better management and most importantly – increased speed management, in today’s demanding era of AI throughput, among others.

The Death of the Polling Bottleneck

In the “Disaggregated Network Era,” we’ve finally decoupled hardware from software. We are moving away from monolithic, vendor-locked chassis systems, towards open-source stacks that act as the central nervous system of modern infrastructure.

The problem is that the old way of monitoring, SNMP, is a bottleneck. Polling-based architecture can’t keep up with terabit speeds or the massive amounts of data generated by AI and machine learning workloads. We need a “push” model, where the network tells us it’s on fire the second a spark appears.

Why SONiC Benefits As Well

The explosion of Generative AI has placed enormous stress on data center networks. AI training clusters require lossless networks, massive throughput, and ultra-low latency. Packet drops or buffer overflows that were tolerable in standard cloud computing, are catastrophic in AI training runs.

SONiC is being actively optimized and promoted as a solution for these AI-scale workloads.

This pivot toward AI necessitates a management interface capable of handling granular, high-frequency data. SNMP is incapable of this, while NETCONF is too heavy. This creates the specific demand for a gNMI-capable controller.

Learn How To Pivot

If you’re still using SNMP for real-time AI clusters, you’re causing the bottleneck yourself. It’s time to look at the headers.

Why gNMI Wins the Protocol War

The industry has been ecstatic about gNMI (gRPC Network Management Interface) because it’s built on HTTP/2 and Protocol Buffers (Protobuf):

• Binary Efficiency: Unlike the verbose XML of NETCONF, Protobuf uses binary serialization. This means lower bandwidth consumption and fewer CPU cycles spent unpacking data.
• Streaming Telemetry: gNMI supports a “Push” model via the Subscribe RPC.
• Mode Versatility: You get STREAM for continuous data, ON_CHANGE for instant event-driven notifications (like a link going down), and SAMPLE for periodic updates.
• Atomic Operations: The Set RPC ensures configuration changes are transactional – either the whole config applies, or none of it does.

How PANTHEON.tech brought gNMI to OpenDaylight

OpenDaylight is the most pervasive SDN control plane, but it originally lacked a native, robust gNMI southbound plugin. As the largest contributor to ODL’s source code, we decided to build it ourselves and contribute it upstream.

Solving dependency hell w/ lighty.io

Standard OpenDaylight runs on Apache Karaf, which is powerful but heavy.

1. Problem: Karaf takes minutes to start, has a massive memory footprint, and suffers from “dependency hell”.
2. Solution: We created lighty.io, an SDK that runs ODL components in a plain Java SE environment.
3. Result: Startup times drop from minutes to seconds. It’s cloud-native, making it perfect for Kubernetes clusters and microservices.

The gNMI Plugin Mechanics

Our plugin translates the binary gRPC world into ODL’s Model-Driven Service Abstraction Layer (MD-SAL). While the internals are complex, we made the “Northbound” interface simple: RESTCONF. This allows your DevOps team to manage next-gen gNMI devices using the same standard HTTP/JSON requests they’ve used for years.

Why does it matter?

Open-source innovation is great until a bug takes down a telecom network serving 1 billion subscribers. Relying on the upstream master branch for mission-critical infrastructure is what we humbly call a high-risk strategy.

PANTHEON.tech provides a hardened distributions of OpenDaylight and lighty.io. We handle the security validation, performance tuning, and Long-Term Support (LTS) so you don’t have to deal with the aggressive 6-month community upgrade cycle.

We don’t just give you the software; we give you access to the engineers who wrote the code and the SLAs required for enterprise-grade reliability.

Ready to modernize your fabric? You can start by testing our pre-packaged lighty-gnmi-community-restconf-app to spin up a gNMI controller with a single command.