The above illustration is a very straight forward “Module” for YANG, and the components of coding elements that make up YANG Modules, this is an actual tiny piece of real code formatting for YANG to reference when looking at Terminology / Concepts below.
Now this first part will tie back to my previous post on SNMP and MIBs so it may be worth a look back, but if you still decide to skip it, this will basically catch you up.
An overview of YANG Data Models / Language
YANG = Yet Another Next Generation, which is a pretty odd name, right?
This plays off my last posts SNMP MIB discussion, as when SNMP was created, a Data Modeling language was also needed to Standardize how Data was interpreted – This is where the very first Model and Langueage came from.
ASN.1 is the original Standardized Data Modeling for SNMP MIBs to utilize, it relied on its Data Modeling Languages shown below that updated over time, leading into YANG:
- SMI (Structured Management Information) – The Original Data Modeling Language
- SMIv2 – The next iteration of SMI Data Modeling Language
- SMIng – SMI Next Generation – No explanation for the Next Gen name, and it never really got used by the IETF for SNMP, so it became unused for some time
At around the same time as SMI Next Gen, the IETF Developed NETCONIG (Network Configuration Protocol) as a more secure way to Read and Write to your Network devices similar to SNMP, they then used a lot of the concepts of “SMIng” to develop a similar Data Model Language which we’ve come to know as YANG.
So YANG is to NETCONF / RESTCONF as SMI is to SNMP MIBs, its their Data Model Standardization and Languages.
YANG is an IETF standard defined in RFCs 6020 and RFC 7950, not vendor Proprietary.
YANG is a “Language” for building and defining data models, that can describe data about anything, beyond networking you could build a data model to describe a tree.
YANG Models that describe something are actually called YANG Modules, these are made up of YANG Models in describing something, and there are hundreds or thousands of different YANG Modules in existence created by the IETF or Private Companies – So these are already in existence out on the Internet and you don’t need to code YANG Data Models from scratch to describe your Router as a Yang Module comprised of dozens of Yang Models.
And Routers will use hundreds of these different pre-defined “standardized” YANG modules to describe their different components (interfaces, route table, ACLs), so its really just more about knowing that they exist, and how they are structured / work.
YANG Terminology and Concepts
- YANG uses a tree-like XML format to represent its data
- YANG “Container” Modules start with Top level “Container” objects that is a generic construct that further describes “child nodes” which is an odd concept to me, but I look at it as a YANG Module Top Container is like the Top of a Vine of Grapes, the Vine serving as the Generic Construct that is holding together child nodes
- Containers can be something like an “interface” and how to describe that, an IP Route and how to describe all the components of that (subnet, protocol, AD, Metric)
- YANG “Leafs” are what fills the “Containers” with descriptions of the different attributes of that Container, or the ‘grapes’ on the ‘vine’ analogy I first envisioned
- Each “Leaf” will have things like interface description / status / ip address / speed / duplex / etc
- Each “Leaf” must have an associated “Type” of how it is described in several ways, for example by String / Integer / Boolean (true/false) / and many more
I like the Grape Vine Analogy as the main take away from all this is that YANG is made up of multiple Containers (Grape Vines) that are a collection of descriptions for a component of the network devices, and “Leaves” which are all the Grapes on the Grape Vine (the generic construct) which holds all the actual descriptions of that element of the network device.
Container:
-Interface
Leaves:
— Description
— Status
— IP Address
— Speed
— Duplex
— Access-Group
— Etc.
Which is then represented appropriately by strings / integers / boolean / various ways.
RW and RO again using “interface” as a Container example:
Read Write (RW) refers to configurable items (Leaves) such as IP Address, Interface State (shut / no shut), Description, Duplex, Speed, etc. Read-Only (RO) Leaves refers to things like the state of an object, for example the state of an interface, the error counters, etc.
Some things obviously fall into both Category of WR and RO such as most configurable items are used by SNMP in a Read-Only manner for device health, which NETCONF was made to replace / as explained within the intro.
Where do you YANG Models come from?
These are not easy to find with a quick google search, or maybe I am looking for the code word “container” somewhere in the code and not seeing it, however it does exist out there in certain places.
“Native Models” or “Vendor Models” are made by Private Companies AKA vendors like Cisco or Juniper, “Standard Bodies” are something available from the IETF though I failed to find any (admittedly did not look extremely hard), and also Companies may Collaborate on creation of YANG Models for example the OpenConfig Organization.
Ultimately it is on the Software Team for a Network Devices software to have built-in Yang Data Models already baked into the code, however if you are curious (or a plan to be a developer some day) you can actually Google “GitHub YANG” and will see Respositories for the IETF, the IEEE, etc – Though Network Engineers only need to know the theory of all this to understand how these different APIs in our Networks work.
This will wrap up a look at YANG Terminology / Concepts / Data Model structures
Next up we’ll actually look at how to view YANG Data Models, I took a sneak peak and it appears I’ll be dusting off the Ubuntu Desktop for some hands on labbing (Yaaaaay!!!), so until next time fellow geeks! 🙂
The DEVNET GRIND! 