Native, IETF, OpenConfig… Exactly why so many YANG versions?
As I was going right through e-mail received over my end-of-2020 split, I ran across a great issue. Or more accurately, an excellent set of questions all linked to the cornucopia of YANG versions open to network automation engineers.
As I dive deeper into YANG models, I’m realizing there are two methods for networking YANG versions: the OpenConfig and the IETF. What I’ve study is that suppliers implement the OpenConfig design natively, however they build the IETF model to be compliant with the IETF also. Is that correct? Are both of these models employed in (all) Cisco products? Will OpenConfig design converge with the IEFT design in a forseeable future relatively? What’s (really) the Cisco method about this?
Man, just what a great set of queries. Allow’s dive into them.
Where do models result from?
YANG models either result from Suppliers or even from some “Some other Group”. Vendors are businesses like Cisco who create software and hardware items. “Other Organizations” could be known as “Standards Bodies” however, not all organizations generating YANG models are usually technically Standards Bodies therefore we’opt for the totally generic “ ll;Other Groups” title here.
Models developed by Vendors are usually often known as “Native” models – since in they’re Indigenous to the gadgets/software that they are connected with.
IETF and OpenConfig are two “Additional Groups” that induce YANG models. They’re different groups with different goals and members. IETF is really a standards entire body that builds versions through exactly the same procedure that brings additional IETF standards (YANG, NETCONF, and RESTCONF are IETF Specifications). OpenConfig is really a band of network operators, from large providers or web businesses primarily, that came together to create a couple of YANG versions that met their specifications.
Because of pressure from customers along with interest in dealing with the wider network ecosystem, vendors will most likely support models from “Various other Groups” as well as the native models. Consider this like a router helping RIP, OSPF, BGP, EIGRP all simultaneously.
You will discover Native often, IETF, and OpenConfig models that target exactly the same basic network feature supported about the same device. You will have distinctions between them in locations such as:
- Simple format of how data is usually represented
- Configuration elements available
- Operational details accessible
Take note: the IETF and OpenConfig aren’t the only real “Other Groupings” that induce YANG models. For instance there’s work in the IEEE on YANG specifications as well.
Example of exact same data, different versions
Utilizing the DevNet IOS XE Always On Latest Sandbox, we are able to look from how these models evaluate when looking at an individual network interface.
First, the IETF is had by all of us model of ietf-interface
curl https://sandbox-iosxe-many recent-1.cisco.com/restconf/data/ietf-interfaces:interfaces/user interface=GigabitEthernet1
-u developer:C1sco12345
--header 'Accept: software/yang-data+json'
"ietf-interfaces:interface":
"name": "GigabitEthernet1",
"description": "MANAGEMENT User 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":
2nd, the OpenConfig interfaces design
curl https://sandbox-iosxe-newest-1.cisco.com/restconf/data/openconfig-interfaces:interfaces/user interface=GigabitEthernet1?content=config
-u developer:C1sco12345
--header 'Accept: program/yang-data+json'
"openconfig-interfaces:interface":
"name": "GigabitEthernet1",
"config":
"name": "GigabitEthernet1",
"type": "iana-if-type:ethernetCsmacd",
"description": "MANAGEMENT User interface - DON'T TOUCH ME",
"enabled": true
,
"subinterfaces":
"subinterface": [
"index": 0,
"config":
"index": 0,
"description": "MANAGEMENT User 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
Notice: The IETF and Indigenous versions for IOS XE use individual containers/versions for operational information and configuration data, as the OpenConfig combines both config and operational information in to the same container. To help keep the examples constant, I’ve included the “articles=config” query parameter in the OpenConfig URL.
Finally, the IOS XE indigenous interface model
curl https://sandbox-iosxe-most recent-1.cisco.com/restconf/data/Cisco-IOS-XE-native:indigenous/interface/GigabitEthernet=1
-u developer:C1sco12345
--header 'Accept: app/yang-data+json'
"Cisco-IOS-XE-native:GigabitEthernet":
"name": "1",
"description": "MANAGEMENT User 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 I use?
Choosing which model to utilize for a task is around individual teams or even developers. Here’s some basic advice We give however.
- Begin with the “non-Native” models. For interoperability of program code/scripts it really is great when you can use an OpenConfig or IETF model.
- Note – the OpenConfig models are more comprehensive than the IEFT models for the same feature often. When just getting started the IETF models could be great options to understand the protocols, functions, and tooling for design driven programmability. However, even more “production grade” tasks should possibly look at OpenConfig versions first.
- If necessary, turn to the Native models for you personally projects. The Native versions would be the only location you’ll likely find assistance for networking features which are particular to a vendor or system. Native models could also provide usage of features and data prior to the IETF and OpenConfig versions are updated to aid “new things”.
- You can certainly build tasks that leverage both Native and OpenConfig/IETF models, nevertheless the effort to keep a task increases with each exterior dependency that you generate. Less dependencies is a great choice typically. My advice would be to pick a group of models offering needed stay and capabilities using them.
- Cautionary Note – You need to stay away from two models for exactly the same network function as it you could end up unexpected configuration problems. For example, don’t use both OpenConfig and Native models for network interfaces. If you thought we would use versions from two different groupings, they must be for different network functions.
One model to principle them all?
You asked if OpenConfig shall converge with IETF later on. With the info above you likely already know the answer to the. They’re two different groups, even though there’s between what they’re working on overlap, there’s enough difference that I’d expect both to can be found for the near future.
What is (actually) the Cisco approach concerning this?
Cisco systems (IOS XE, IOS XR, NX-OS) will continue steadily to support IETF, Native and openconfig models. You can find legitimate needs for several three from clients, and you want to enable the choice. Where to see what versions are backed on a system is through to GitHub at YangModels/yang/vendor/cisco. With each software program release, the models supported are published for anybody to find publicly.
Final Thoughts
Model Driven Programmability subjects are a few of my favorite to speak about and explore. This is a foundation technologies for the automation engineer. This helps it be important for us to comprehend and dive into truly. This helps it be ripe for great queries from engineers at all levels of these network automation journey. Are you experiencing a relevant question? I want to know in the remarks, or on Twitter (@hfpreston) or via email at hapresto@cisco.com.
And are some very nice resources for exploring Design Driven Programmability here