The Cloud-Native Advantage: Intent-based Network Automation#

Alexander North - Swisscom (with Markus Vahlenkamp - Nokia)

• Why: Bridges the PM's two worlds in one talk — Kubernetes resource-model tooling applied to YANG/NETCONF/gNMI device configuration. The core problem is one anyone running CNFs or telco functions has hit: Helm deploys the pod, but the running config is still set with imperative per-instance NETCONF RPCs, outside any reconcile loop.
• What: Schema Driven Configuration (SDC), an open-source (initiated by Nokia, CNCF Sandbox since 2026) Kubernetes Operator that models device configuration as Config custom resources with priorities, and reconciles them against the device via NETCONF or gNMI. In production at Swisscom for the 5G mobile core — roughly 2000 pods, 5000 interdependent parameters, 14 network functions.
• How: Config CRs declare only their slice of the YANG tree, tagged with a target and a priority. SDC merges all Configs (priority resolves overlaps — a temporary ops override at prio 50 beats the platform baseline at prio 100, and deleting the override restores the baseline), validates the merged tree against YANG, diffs against the device's running config, and translates only the delta to NETCONF/gNMI with per-NOS rules. Drift is surfaced as Deviation CRs with typed reasons (NOT_APPLIED, OVERRULED, UNHANDLED brownfield config); revertive: true re-applies automatically. A kubectl sdc blame command shows, for every leaf, whether it came from which Config or from brownfield running config — "Config Blame is to Config apply what Git Blame is to commit."
• Where applicable: Anything with a YANG model — physical routers, VMs, containers. Note the abstract oversells "self-healing": default behavior reports drift rather than fixing it (revertive is opt-in), and RESTCONF is not yet supported. The Swisscom deployment is a large-scale telco core, but the mechanism itself is general and adoptable at docs.sdcio.dev.