DENOG18

Network operators share a vocabulary built on VRFs, EVPN-VXLAN, and BGP underlays. What doesn't travel is how it gets written down. Every vendor and orchestrator has its own dialect, and most automation tools still push device-specific config from an orchestrator down to all involved devices. Translation, not domain-specific problems, becomes a bottleneck.

We build Wire-API with a different model in mind: Instead of targeting devices, operators declare the state they want and controllers work out which devices are affected and what config to push. In the case of an EVPN fabric for example: describe it with objects like Network, RoutingDomain, and ExternalConnection, and adding a network becomes one object rather than a coordinated change across every leaf and firewall that participates. The shift is in what gets declared: desired state instead of a device's running config. From there, drift correction and HA-aware maintenance stop being separate runbooks and become properties of the reconcile loop, and the same model extends to anything else on the network expressed as intent.

The core is Kubernetes. Wire-API is a set of CRDs and controllers that reuse the contract that made Kubernetes work in "compute"—declared state, continuous reconciliation, honest status—and apply it to the network domain.

The presentation argues for the Wire-API model and walks through a live EVPN-VXLAN example—one intent object, vendor-specific config on Cisco NX-OS and Nokia SR Linux—then covers design decisions and partial-failure handling. Wire-API already operates production fabrics across multiple availability zones; the model works today even as the framework continues to grow.

Wire-API is Apache-2.0 and is being contributed to the NeoNephos Foundation (Linux Foundation Europe) as part of the ApeiroRA workstream under the EU IPCEI-CIS program.