YANG, OpenConfig, and the Quiet Revolution in Network Automation

If you’ve never configured a Cisco router, you might not appreciate just how painful traditional network operations can be. Every vendor has its own CLI syntax. Automating configuration means scraping human-readable text output — brittle, version-sensitive, and entirely undocumented in machine-readable form.

YANG (Yet Another Next Generation) is the data modeling language that was supposed to fix this. I spent two years implementing it inside IOS-XR. Here’s what I learned.

What YANG Actually Is

YANG is a schema language. It lets you formally describe the configuration and state of a network device — what parameters exist, what types they have, what constraints they must satisfy, what relationships exist between them. A YANG model is like a strongly-typed API contract for your router.

OpenConfig is a set of vendor-neutral YANG models maintained by a consortium of network operators (Google, Microsoft, AT&T, and others). The goal is a common data model that works across Cisco, Juniper, Arista, Nokia — so automation code doesn’t have to know which vendor it’s talking to.

The Transport Layer

YANG models are exposed via two main protocols. NETCONF, the older one, runs over SSH and uses XML encoding. gNMI (gRPC Network Management Interface) is the newer, more performant one — it runs over gRPC with Protobuf encoding and supports streaming subscriptions for telemetry. For most new deployments, gNMI is the right choice.

My work was implementing OpenConfig YANG support in IOS-XR’s management plane: mapping the external OpenConfig model to IOS-XR’s internal data structures, ensuring CLI, NETCONF, and gNMI all presented consistent views, and handling the translation between OpenConfig’s vendor-neutral semantics and Cisco’s platform-specific behavior.

The Gap Between Model and Reality

OpenConfig models are beautiful in theory. In practice, every platform has corner cases. Cisco 8000 supports features that ASR 9000 doesn’t. Virtual platforms (XRv, XRd) have different constraints than physical line cards. The model must be the same; the behavior underneath can legitimately differ.

Handling this gracefully — returning accurate capability advertisements, raising meaningful errors when an unsupported feature is requested, ensuring telemetry only streams data the platform can actually provide — was most of the real engineering work.

Where This Is Going

Network-as-code is becoming real. Infrastructure teams at hyperscalers already manage tens of thousands of devices via YANG-driven automation. The next step is intent-based networking: you describe what you want the network to do, and the software figures out the configuration. That requires a solid, trustworthy data model underneath. YANG is that foundation.

I got to build part of that foundation. It’s unglamorous work — lots of data model mapping, lots of edge case handling, lots of reading RFCs — but it matters at a scale that’s easy to underestimate.