As|I|was going through email received over my end-of-2020 break, I came across a great question.  Or more accurately, a greatset of questions all related to the cornucopia of YANG models available to network automation engineers.

As I dive deeper into YANG models, I am realizing that there are two ways for networking YANG models: the OpenConfig and the IETF. What I've read is that vendors implement natively the OpenConfig model, but they also build the IETF model to be compliant with the IETF. Is that right?  Are these two models working in (all) Cisco devices? Will OpenConfig model converge with the IEFT model in a relatively near future? What is (really) the Cisco approach about this? 

Man, what a great set of questions. Let's dive into them.

Where do models come from?

YANG models either come fromVendorsor from some "Other Group". Vendors are companies like Cisco who make hardware and software products. "Other Groups" could be referred to as "Standards Bodies" but not all groups creating YANG models are technically Standards Bodies so we'll go with the totally generic "Other Groups" name here.

Models created by Vendors are often referred to as "Native" models -as in they areNativeto the devices/software for which they are associated with.

IETF and OpenConfig are two "Other Groups" that create YANG models. They are different groups with different members and goals. IETF is a standards body that builds models through the same process that brings other IETF standards (YANG, NETCONF, and RESTCONF are all IETF Standards). OpenConfig is a group of network operators, primarily from large service providers or web companies, who came together to build a set of YANG models that met their requirements.

Due to pressure from customers as well as interest in working with the wider network ecosystem, vendors will often support models from "Other Groups" in addition to the native models. Think of this like a router supporting RIP, OSPF, BGP, EIGRP all at the same time.

Youwill often find Native, IETF, and OpenConfig models that all target the same basic network feature supported on a single device. There will be differences between them in areas such as:

• Basic format of how data is represented
• Configuration elements available
• Operational details available

Note: the IETF and OpenConfig are NOT the only "Other Groups" that create YANG models. For example there is work in the IEEE on YANG standards as well.

Example of same data, different models

Using the DevNet IOS XE Always On Latest Sandbox, we can look at how these models compare when looking at a single network interface.

First, we have the IETF model of ietf-interface

curl https://sandbox-iosxe-latest-1.cisco.com/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1 \  -u developer:C1sco12345 \  --header 'Accept: application/yang-data+json'{    "ietf-interfaces:interface": {        "name": "GigabitEthernet1",        "description": "MANAGEMENT INTERFACE - DON'T TOUCH ME",        "type": "iana-if-type:ethernetCsmacd",        "enabled": true,        "ietf-ip:ipv4": {            "address": [                {                    "ip": "10.10.20.48",                    "netmask": "255.255.255.0"                }            ]        },        "ietf-ip:ipv6": {}    }}

Second, the OpenConfig interfaces model

curl https://sandbox-iosxe-latest-1.cisco.com/restconf/data/openconfig-interfaces:interfaces/interface=GigabitEthernet1?content=config \  -u developer:C1sco12345 \  --header 'Accept: application/yang-data+json' {    "openconfig-interfaces:interface": {        "name": "GigabitEthernet1",        "config": {            "name": "GigabitEthernet1",            "type": "iana-if-type:ethernetCsmacd",            "description": "MANAGEMENT INTERFACE - DON'T TOUCH ME",            "enabled": true        },        "subinterfaces": {            "subinterface": [                {                    "index": 0,                    "config": {                        "index": 0,                        "description": "MANAGEMENT INTERFACE - DON'T TOUCH ME",                        "enabled": true                    },                    "openconfig-if-ip:ipv4": {                        "addresses": {                            "address": [                                {                                    "ip": "10.10.20.48",                                    "config": {                                        "ip": "10.10.20.48",                                        "prefix-length": 24                                    }                                }                            ]                        }                    },                    "openconfig-if-ip:ipv6": {                        "config": {                            "enabled": false                        }                    }                }            ]        },        "openconfig-if-ethernet:ethernet": {            "config": {                "mac-address": "00:50:56:bf:78:ac",                "auto-negotiate": true,                "enable-flow-control": true            }        }    }}

Note: The IETF and Native models for IOS XE use separate containers/models for operational data and configuration data, while the OpenConfig combines both config and operational data into the same container. To keep the examples consistent, I have included the "content=config" query parameter in the OpenConfig URL.

Lastly, the IOS XE native interface model

curl https://sandbox-iosxe-latest-1.cisco.com/restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=1 \  -u developer:C1sco12345 \  --header 'Accept: application/yang-data+json'{    "Cisco-IOS-XE-native:GigabitEthernet": {        "name": "1",        "description": "MANAGEMENT INTERFACE - DON'T TOUCH ME",        "ip": {            "address": {                "primary": {                    "address": "10.10.20.48",                    "mask": "255.255.255.0"                }            }        },        "mop": {            "enabled": false,            "sysid": false        },        "Cisco-IOS-XE-ethernet:negotiation": {            "auto": true        }    }}

But what model should Iuse?

Choosing which model to use for a project is up to individual developers or teams. However here is some basic advice I give.

1. Start with the "non-Native" models. For interoperability of code/scripts it is great if you can use an IETF or OpenConfig model.
   • Note -the OpenConfig models are often more comprehensive than the IEFT models for the same feature. When just starting out the IETF models can be great options to learn the protocols, features, and tooling for model driven programmability. However, more "production grade" projects should probably look at OpenConfig models first.
2. If necessary, look to the Native models for you projects. The Native models will be the only place you'll likely find support for networking features that are specific to a vendor or platform. Native models may also provide access to features and data before the IETF and OpenConfig models are updated to support "new things".
3. You cancertainly build projects that leverage both Native and OpenConfig/IETF models, however the effort to maintain a project increases with each external dependency that you bring in. Less dependencies is typically a good choice. My advice is to pick a set of models that provide needed capabilities and stick with them.
   • Cautionary Note -You should avoid using two models for the same network feature as it could result in unexpected configuration issues. For example, don't use both Native AND OpenConfig models for network interfaces. If you chose to use models from two different groups, they should be for different network features.

One model to rule them all?

You asked if OpenConfig will converge with IETF in the future. With the information above you likely know the answer to this already. They are two different groups, and while there is overlap between what they are working on, there is enough difference that I would expect both to exist for the foreseeable future.

What is (really) the Cisco approach about this?

Cisco platforms (IOS XE, IOS XR, NX-OS) will continue to support IETF, OpenConfig and Native models. There are legitimate needs for all three from customers, and we want to enable the choice. The best place to see what models are supported on a platform is up on GitHub at YangModels/yang/vendor/cisco. With each software release, the models supported are published publicly for anyone to find.

Final Thoughts

Model Driven Programmability topics are some of my favorite to talk about and explore. It is a foundation technology for the automation engineer. This makes it important for us to truly understand and dive into. This makes it ripe for great questions from engineers at all stages of their network automation journey. Do you have a question?  Let me know in the comments, or on Twitter (@hfpreston) or via email at [email protected].

And here are some great resources for exploring Model Driven Programmability

• DevNet IOS XE on CSR Always On Sandbox
• Network Programmability Basics Video Course Network Device APIs Module
• Learning Labs: Introduction to Model Driven Programmability

We'd love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel