YANG Data Models in the Industry: Current State of Affairs (March 2018)

During IETF 101, we published the new Network Management Datastore Architecture (NMDA) as RFC 8342 and, along with that, some NMDA-compliant YANG modules. Three RFCs have been revised to produce NMDA-compliant YANG modules: interface, IP management, and routing. I’m also happy to report that an entire industry is working towards adopting NMDA. As an example, Scott Mansfield mentioned to me, “I would like to note that IEEE (802.1, 802.3, and 802.11), ITU-T, and MEF have embraced NMDA.”

In total, since last week, we saw the publication of the following RFCs:

• RFC 8340, YANG Tree Diagrams
  
• RFC 8341, Network Configuration Access Control Model
  
• RFC 8342, Network Management Datastore Architecture (NMDA)
  
• RFC 8343, A YANG Data Model for Interface Management
  
• RFC 8344, A YANG Data Model for IP Management
  
• RFC 8345, A YANG Data Model for Network Topologies
  
• RFC 8346, A YANG Data Model for Layer 3 Topologies
  
• RFC 8347, A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)
  
• RFC 8348, A YANG Data Model for Hardware Management
  
• RFC 8349, A YANG Data Model for Routing Management (NMDA Version)
  

With RFC 8342 bottleneck removed, many YANG modules are now published. We are finally seeing exponential growth in the number of IETF YANG modules published, as can be seen in the recently updated figure below (most up-to-date figure here).

Some more YANG modules are in the RFC-editor queue, part of this edition cluster:

• draft-ietf-lime-yang-connectionless-oam-methods-13.txt,
  
• draft-ietf-lime-yang-connection-oriented-oam-model-07.txt, 
  
• draft-ietf-lime-yang-connectionless-oam-18.txt, 
  
• draft-ietf-rtgwg-yang-rip-10.txt, 
  
• draft-ietf-rtgwg-ni-model-12.txt,
  
• draft-ietf-rtgwg-lne-model-10.txt, 
  
• draft-ietf-netmod-syslog-model-26.txt.  
  

So plenty of YANG modules will be published soon to further improve the hockey stick figure. And there are some more in the pipeline, for sure.

Recently, the NETMOD working group finalized the “Guidelines for Authors and Reviewers of YANG Data Model Documents”,  draft-ietf-netmod-rfc6087bis-20.txt. It’s a RFC bis document that incorporates an extra seven years of experience with RFC 6087, a key document that many should read.

During the IETF meeting in London, we found a way to escape from the schema mount impasse, an issue that lasted since the Working Group last call in November. As a quick reminder, the schema mount defines a mechanism to combine YANG modules into the schema defined in other YANG modules. Sometimes, magic happens when people speak to each others face to face. It did happen last week, when the version 9 of draft-ietf-netmod-schema-mount was posted: this version makes everybody a little bit happier! After the Working Group last call, it should move quickly to RFC publication, unblocking two key YANG documents already in the RFC editor queue: the logical network element (LNE), an independently managed virtual device made up of resources allocated to it from the host or parent network device, and the network instance module, which can be used to manage the virtual resource partitioning that may be present on a network device such as VRF and VSI.

The NETCONF Working Group rechartered, with a more open-ended charter:

In NETCONF, the YANG push and event stream subscriptions have three drafts now in Working Group last call. YANG Push was referenced often by other drafts in the I2NSF & SACM Working Groups.

In the IETF Hackathon, Joe Clarke and I dedicated our time to the maintenance of the YANG catalog, while Mahesh Jethanandani added the MEF YANG modules, and Vladimir Vassilev focused on the validating YANG examples. The YANG catalog now contains information about 3455 unique YANG modules from the entire industry: IETF, IEEE, Broadand Forum, MEF, cz.nic, sysrepo, openconfig, and some vendors (Cisco, Huawei).

Do we still have some issues in the world of YANG & data model-driven management? Absolutely, but we passed the advertisement phase (YANG is used), we are on the right track for the coordination phase (the YANG knowledge is spread across IETF Working Groups and the industry), and we should now focus on the optimization phase. To mention just a few problems to tackle next:

• Knowing that examples are key to help implementations, we should develop the toolchain to validate examples automatically. And we should have the ability to add more examples to existing published YANG modules.
  
• We should define a way to update YANG modules in a backward incompatible way. Indeed, because the RFC7950 update rules are so strict, the YANG module needs to perfect day one, which causes some delay in the specifications. It would also solve an important issue for generated YANG module, also known as native models.
  
• Publishing the RFC might be perceived as the end goal, however let’s not forget that the YANG module is really the useful part of the RFC, as it can generate code. IMO, IANA should be the source of truth for YANG modules. This is work-in-progress, with the goal to retrieve all YANG in a single rsync command: the latest IANA-maintained modules such as the iana-if-type.yang, the newly published modules from RFCs with potentially the inclusion of errata.
  
• Also, at some point in time, we might have to run our IETF process directly on the product of the RFCs (read the YANG modules), as opposed to the RFC itself.
  

Regards, 

Benoît 

(happy ex-OPS Area Director and now an individual IETF contributor)

This post was originally published on 27 March 2018 as: 

"YANG Data Models in the Industry: Current State of Affairs (March 2018)"

Note also the previous “YANG Data Models in the Industry: Current State of Affairs” published following  the IETF 100 meeting in Singapore.