Decentralizing Software Defined Networking: The Hidden Complexities of SDN & What We Can Do About Them#

Alexander Krentsel — Google / UC Berkeley

• Why: A rare quantified indictment of centralized SDN: at Google, >50% of large outages are root-caused to the control plane itself — the dedicated controller infrastructure, control-plane network, instrumentation services, and fallback protocols that SDN drags in. For anyone building WAN control systems, this is the architecture conversation to have.
• What: Decentralized SDN (dSDN): run the operator's SDN control program as a container on every router instead of on external servers. Each node floods its local state (topology, link capacities, demand), each node independently computes all paths with the operator's TE algorithm, and traffic follows strict source routes programmed at the ingress. This removes central/regional controller jobs, dedicated servers, the control-plane network, instrumentation services, and traditional fallback protocols from the critical path while keeping SDN's benefits (operator-defined code, global-view TE, consensus-free path selection) and restoring fate-sharing between control and data planes.
• How: Enabled by three industry shifts: on-router third-party containers, standardized APIs (gRIBI, gNMI, OF/P4), and multi-core router CPUs. Source routing makes decentralization simple — historically infeasible in WANs due to path length in the header, now practical via hardware advances and a novel encoding (details in the paper). Evaluation: a production-grade implementation on real routers, fed live B4 topology and demand, replaying production failure events — convergence 120-150x faster than centralized SDN (faster propagation and programming outweigh slightly slower local computation) with markedly lower convergence impact on low-priority traffic.
• Where applicable: Global WAN operators (Google B4-class). Requires vendor on-router container support and vendor-neutral programmatic APIs — realistic on modern platforms but a real dependency. Research-to-production direction from Berkeley NetSys + Google, not a deployable product; the simplification argument (fewer components on the critical path → fewer complex cascading outages) generalizes to any control-plane design review.