Network Configuration in the Real World: Standards, Surprises and 'Creative' Implementations#

Jens Vogler (Init7)

• Why: Everyone building network automation hits the same wall: model-driven configuration (NETCONF/YANG) promises vendor-agnostic, atomic, validated changes — and then reality intervenes. This is a candid operator postmortem of that gap, from an ISP that actually tried to industrialize service provisioning rather than demo it.
• What: A practitioner's account of automating end-to-end service provisioning from OSS/BSS inventory to device configuration at Init7. The core finding: IETF YANG models are barely usable for real configs, OpenConfig's vendor support is very limited, and what vendors call "NETCONF support" varies wildly in practice — enough that the team fell back to pushing CLI via Ansible. The honest learnings: single source of truth doesn't solve everything, escape hatches are still necessary for urgent fixes, abstract data models will always contain gaps, and once synchronization exists, divergence is possible.
• How: NetBox as the network inventory feeding a glue system that reconciles OSS (network operations) and BSS (CRM/billing) around the customer order flow. The intended path was NETCONF (RFC 4741) with YANG schemas for atomic commit and section-level config replacement; the working path ended up template-driven CLI with Ansible — well-understood tooling, but non-atomic applies and no reliable section replacement.
• Where applicable: Broadly applicable. The lessons are from an ISP's service-provisioning pipeline but transfer directly to any enterprise or cloud operator running NetBox-driven automation: verify vendor NETCONF/YANG claims before betting on them, keep deterministic escape hatches, and treat model-reality gaps as a design constraint, not a bug. Notable tooling observations (Cisco YANG Suite is powerful but slow and closed-source; pyang/ncclient are the friendliest automation entry points) are useful shopping guidance.