Choosing a Configuration Model: A Lesson Learned

We found out in this tutorial that a device may support several YANG models (e.g. interfaces-related modules(). In most cases, these models expose the same underlying configuration in different ways. The reality is:

  • The device (or its datastore) has one underlying source of truth for interface configuration.
  • Multiple YANG modules can each provide a view onto that source of truth (a native vendor model, an IETF model, or an OpenConfig model) and more than one of those views may be used to write configs.
  • The operator or automation team picks one model family to standardize on for their own automation.

Here are some example:

  1. Cisco IOS XR: native and OpenConfig, same datastore

    IOS XR exposes both its native YANG models and OpenConfig models for interfaces. For instance, a native path under interface-configurations/interface alongside an OpenConfig path under interfaces/interface/config. Both can be written. Cisco's own programmability documentation explains that changes made through OpenConfig show up in the native model too, because they map onto the same underlying datastore.

    The guidance from Cisco's automation documentation is to pick one YANG model family and stick with it, because mixing native and OpenConfig writes across different tools invites aliasing and synchronization problems.

  2. Nokia SR Linux: native and OpenConfig, mapped to each other

    SR Linux is explicit about supporting both its own vendor-specific models (srl_nokia-interfaces) and OpenConfig models (openconfig-interfaces), available over both NETCONF and gNMI. Nokia even ships mapping files (oc-srl*.json) that describe how OpenConfig paths translate to native SR Linux paths.

    The documentation mentions that you can configure through either model, but production automation frameworks are advised to standardize on one for consistency.

Both Arista cEOS and SR Linux in this lab implement IETF-style interface models alongside OpenConfig. Automation guides and lab walkthroughs for cEOS consistently demonstrate OpenConfig payloads for configuration, and SR Linux's documentation is explicit that OpenConfig is meant for vendor-neutral configuration and management once enabled on the device.

References