Home · Documentation · Technology · NETCONF & YANG

NETCONF, YANG & Zero-Touch Provisioning

Modern operators don't ship boxes with golden configs on USB sticks anymore. OcNOS gives you the full model-driven config surface — NETCONF over SSH/TLS, OpenConfig and IETF YANG, candidate datastore with commit/rollback, and a Zero-Touch Provisioning flow that takes a brand-new chassis from box-open to operational state with a DHCP lease.

Day-0 Zero-Touch Provisioning Flow

A factory-fresh OcNOS router boots, requests a DHCP lease, fetches the correct image from the staging server, downloads its YANG-rendered config from the config server, commits to the running datastore, and reports operational — no operator on-site.

NETCONF and Zero-Touch Provisioning flow Sequential ZTP and NETCONF provisioning flow. An OcNOS switch boots, requests DHCP, downloads its NOS image from an image server, pulls running configuration via NETCONF/YANG from a config server, and reaches operational state. Boot factory image DHCP opt 67 / 239 Image HTTP / TFTP Config NETCONF / YANG Op in service STEP 1 STEP 2 STEP 3 STEP 4 DONE factory NOS lease + URL install + reboot commit datastore callback ZTP · NETCONF · OPENCONFIG YANG · CANDIDATE DATASTORE · COMMIT/ROLLBACK

Why model-driven config matters

CLI scripts don't compose, don't roll back, and don't validate inputs against a schema. NETCONF + YANG gives you a typed, transactional config surface — push a candidate, validate, commit, or rollback if any leaf is rejected. OcNOS exposes both OpenConfig models (BGP, interfaces, network-instance, platform) and IETF models (ietf-interfaces, ietf-routing, ietf-system) plus IP Infusion native models for OcNOS-specific knobs. Combined with Zero-Touch Provisioning, the operations workflow becomes: rack a box, plug in management, walk away.

The OcNOS NETCONF, YANG & ZTP implementation

NETCONF

SSH + TLS transport

RFC 6241 NETCONF over SSH and TLS, with full Get / Get-Config / Edit-Config / Commit / Validate / Lock / Discard-Changes RPC support.

YANG Models

OpenConfig + IETF + native

OpenConfig BGP, interfaces, network-instance, platform, telemetry; IETF system, interfaces, routing; IP Infusion native models for unique features.

Datastores

Candidate + commit / rollback

Full candidate datastore with confirmed commit (RFC 6243), explicit rollback to N prior commits, and config-history retrieval.

ZTP

Day-0 provisioning

DHCP option 67 / 239-driven boot — fetch image, signature-verify, install, reboot; then fetch config bundle and commit. Idempotent retry on partial failure.

Ansible / Salt

Reference modules

Ansible Galaxy collection and Salt formulas for OcNOS NETCONF — idempotent BGP, interface, and EVPN role plays out of the box.

gNMI

Coexistence with NETCONF

gNMI Set and NETCONF Edit-Config target the same model store — pick the protocol that fits your tooling, the device behaves the same way.

What you get with OcNOS automation

  • One config surface, two protocols. NETCONF and gNMI both target the same YANG-modelled datastore — no protocol-specific feature gaps.
  • Verified ZTP. Day-0 image fetch is signature-verified; config bundle integrity is checked before commit. Zero on-site touch with confidence.
  • Open tooling. Reference Ansible collection, Salt formulas, and Python client examples published — no proprietary SDK lock-in.
  • Operational rollback. Every commit is tracked. Roll back to any prior state with a single RPC if a change goes wrong.
Streaming Telemetry OcNOS-SP OcNOS-DC Network Automation

Standing up a model-driven operations stack? Talk to a network architect.

Request a Technical Demo →