Like many ideas at the IETF, the YANG Catalog started as a side discussion with Carl Moberg. Maybe in a corridor? maybe in a bar? Or maybe we were having a drink in a corridor? Our memories get blurry.  Anyway, somewhere in 2015, Carl and I discussed the idea of having a YANG catalog, as a place to lookup YANG modules. At that time, we were thinking: it would great if this catalog would contain not only all the IETF YANG modules but all known YANG modules in the industry!

Starting with the first hackathon at the IETF 92 meeting in 2015 in Dallas, we started to focus on YANG tools development with two important building blocks. Carl focused on the yangvalidator.org, born a little bit later in June 2015, and I was focusing on the IETF YANG modules validation. The team of volunteers working on YANG tools grew by each hackathon, with some tool development such as xym, to extract YANG modules out of IETF documents, and YANG validators such as pyang, yanglint, etc.

The need for a YANG catalog became painfully obvious a little bit later, when as Operations & Management Area Director focusing on YANG, I was trying to evaluate the status of the different YANG modules. The difficulty being that those YANG modules are interdependent (based on the import YANG keyword), but coming from different IETF drafts, and sometime even from different working groups. I recall spending quite some time drawing the below figure, focusing on the relationship between routing-related YANG modules with the ultimate goal to provide guidance to the IETF as to which YANG modules/IETF drafts to focus on as a next step. In other words, trying to find out the next bottleneck in the standardization process.

In the mean time, the OpenConfig group formally proposed the catalog idea in the “Catalog and registry for YANG models” IETF draft in October 2015

Abstract

   This document presents an approach for a YANG model catalog and
   registry that allows users to find models relevant to their use cases
   from the large and growing number of YANG modules being published.
   The model catalog may also be used to define bundles of YANG modules
   required to realize a particular service or function

The draft went through two iterations and is now expired but the goals are obviously aligned with the actual YANG catalog. The YANG module used to manage the YANG catalog, authored with Joe Clarke, is inspired from the Openconfig work and became, along the time, a superset of it. This YANG module contains metadata pertinent to each YANG module, as well as a list of vendor implementations for each module. The structure is laid out in such a way as to make it possible to locate metadata and vendor implementation on a per-module basis as well as obtain a list of available modules for a given vendor’s platform and specific software release. Since the YANG catalog is managed through a YANG module, this implies that APIs are available to query the YANG catalog content. Note that’s it’s always fun to explain the recursion of how one YANG module is used to “manage”, or “report on” to be more precise, other YANG modules.

The attached picture is a napkin-type of old drawing explaining the vision of how the different tools could interact together.

Granted, it’s not really a napkin but most decent old IETF stories involve a napkin 🙂

As displayed, the end goal was to “disrupt the IETF process for YANG models”, stressing the need to think differently how we approach the automation standardization.

 

 

 

 

 

 

 

 

 

At every single hackathon since the very first one, a team of people help to create this vision. I’m hesitant to start listing names, fearing to forget a few. So refer to the “YANG Updates” series of blogs on this web site. For example, the “YANG Opensource Tools for Data Modeling-driven Management” blog is interesting if you are new to YANG-based automation as it describes some of the foundation opensource tools, and therefore the underlying building blocks behindg the YANG catalog:

• The YANG validator, a web frontend that allows for validation of YANG modules and IETF drafts
• The YANG search, a web frontend that allows for searches over the content of the YANG module and related metadata
• The impact analysis tool, a visualization tool for YANG module dependencies across the industry.
• The YANG Regex Validator, a YANG regular expression validator to experiment with W3C YANG “pattern” statements
• The YANG Development Kit (YDK), generated APIs that can then be used to simplify the implementation of applications for network automation.

After year of development, today marks the transition of YANG catalog to the IETF LLC, with the official announcement here. It’s not the end but a revival as the YANG catalog will be supported by the IETF tools team, along with an awarded contract with Pantheon Tech for the following independent project tasks:

1. Support transitioning the operation of the YangCatalog to the IETF Secretariat;

2. Support operating the YangCatalog web site; and

3. Adding features of the yangvalidator project to the YangCatalog.

Still the community of developers and supporters will continue the joint development efforts (in hackathon, for example).

In the end, this tool support transition stresses the importance of the YANG catalog in the IETF toolchain and for the entire industry as a whole. As an example, the IEEE YANGsters, a group responsible for discussing common practice for YANG models supporting IEEE 802 protocols, integrated the YANG catalog into the IEEE development process. Practically, the IEEE shares the YANG modules and related metadata with the YANG catalog.

Next to the community effort, which started the YANG catalog, its development would not have been possible without the support of Cisco, which sponsored a contractor for a year to bring the YANG catalog to the professional level where it is today. That is an automation toolchain used by operators, YANG modules designers, opensource projects, vendors, consortia, and the different standard development bodies.

If you want to know more about the YANG catalog, here is a good place to start.

Regards, Benoit