The IETF 99 is now over. Building on this tradition to write a blog explaining the progress for this YANG Catalog (here is the blog for the IETF 98), let me explain the latest developments after these two days of hacking on Saturday/Sunday before the IETF working group meetings.
First of, Joe Clarke improved his YANG DB search tool, with more and more options, based on experience and requests. For example, during a demo for the IEEE and IESG on Saturday afternoon, explaining the benefits to both organizations, it was highlighted that the etherType typedef found in the catalog was a version from an old IEEE document. Indeed, the catalog keeps all versions in his database. Anyway, the point was valid: when the goal is to reuse typedef’s, we should stress the most up-to-date ones. In a typical hackathon fashion, the next day, YANG DB search contained a new option: “Only Show Latest Revisions”, on by default. Next to that, there is now a new YANG 1.0 and/or YANG 1.1 selector.
Radek Krejci developed a command line W3C YANG regex validator tool, called yangre. There are many POSIX regex validators in the industry, including some graphic user interface tools around it, but YANG uses the W3C regex rules.
Pieter Lewyllie developed the GUI around it. Just introduce your YANG “pattern” statement or statements (multiple entries are possible), select whether you want the “invert match” (a possible option in YANG), populate the test string and the tool will validate it in green if it passes or red if it fails.
In terms of YANG module validation, Mahesh Jethanandani improved the yangvalidator.org with IEEE, MEF and Cisco specific yang plugins, and I improved my validation scripts: removed all submodules, updated the validators, added the revision (which is needed as a key field in the YANG catalog DB), validated the Open ROADM YANG modules, etc.
On the Impact Analysis front, Joe Clarke added a checkbox to eliminate sub-modules and added directionality selectors as a way to filter the Impact Analysis to only show dependents and dependencies
The “YANG module for yangcatalog.org” draft specifies specifies a YANG module that contains metadata related to YANG modules and vendor implementations of those YANG modules. In other words, the YANG module behind the yangcatalog.org. In a nutshell, it contains:
module: yang-catalog
+--rw catalog
+--rw modules
| +--rw module* [name revision]
| +--rw name yang:yang-identifier
| +--rw revision union
| +--rw datastore* identityref
| +--rw schema? inet:uri
| +--rw namespace inet:uri
| +--rw feature* yang:yang-identifier
| +--rw deviation* [name revision]
| | +--rw name yang:yang-identifier
| | +--rw revision union
| +--rw conformance-type enumeration
| +--rw submodule* [name revision]
| | +--rw name yang:yang-identifier
| | +--rw revision union
| | +--rw schema? inet:uri
| +--rw document-name? string
| +--rw author-email? string
| +--rw compilation-status? enumeration
| +--rw compilation-result? string
| +--rw reference? string
| +--rw prefix? string
| +--rw yang-version? string
| +--rw organization? string
| +--rw description? string
| +--rw contact? string
| +--rw maturity-level? enumeration
| +--rw implementations
| +--rw implementation* [vendor platform software-version software-flavor]
| +--rw vendor string
| +--rw platform string
| +--rw software-version string
| +--rw software-flavor string
| +--rw os-version? string
| +--rw feature-set? string
| +--rw os-type? string
+--rw vendors
+--rw vendor* [name]
+--rw name string
+--rw platforms
+--rw platform* [name]
+--rw name string
+--rw software-versions
+--rw software-version* [name]
+--rw name string
+--rw software-flavors
+--rw software-flavor* [name]
+--rw name string
+--rw protocols
| +--rw protocol* [name]
| +--rw name enumeration
| +--rw protocol-version? string
| +--rw capabilities* string
+--rw modules
+--rw module* [name revision]
+--rw name -> ../../../../../../../../../../../modules/module/name
+--rw revision -> ../../../../../../../../../../../modules/module/revision
Those metadata can be classified in three categories:
– the metatada that can extracted from the YANG module itself. Ex: revision, organization, etc
– the metadata that can’t be extracted from the YANG module and that must populated by hand. Ex: if the YANG module is not from the IETF, the maturity level, the author-email, the reference, the document-name, or the conformance-type.
– the metadata that can extracted, but not from the YANG module. Typically, a vendor would provide the NETCONF hello message for a specific platform to help populate the implementation specific metadata, i.e. the supported YANG modules, deviations, features, and capabilities.
See the brand new YANG catalog contribute page for details on how populate the YANG catalog. During the hackathon, Miroslav Kovac developed the respective APIs (including authorization and authentication) and William Lupton from BBF validated them, introducing all BBF modules and metadata in the catalog. As an example, here are all the metadata for the bbf-fast.yang YANG module.
In terms of different Standard Development Organizations and opensource projects, we now have YANG modules from the IETF, BBF, MEF, IEEE, and openconfig. Note that some non extratable metadata still needs to be populated for some organizations.
In terms of different vendors, we now have YANG modules from Cisco (with implementation metada) and from Huawei. Juniper also participated to the hackathon and the work to add their respective YANG modules is under way. As an example of the catalog capabilies, a single query can answer: “give me all YANG modules supported by the Cisco IOS-XR 6.2.1” 
Since this IETF hackathon, we’ve been facing a good problem: the YANG catalog has been a victim of its success, exhausting all of its memory and hard disk resources. Yesterday, I upgraded our yangcatalog.org:
– memory: from 2 to 8 GiB
– hard disk: from 8G to 20G
– CPU: from 1 to 2 vCPU
Bare with us (a day or two) while we’re busy re-populating all entries right now.
Another important point, which makes me happy. The IETF hackathon is two days hacking event at every IETF meeting, but we start to have a consistent team of passionate people who wants to improve the industry in terms of data modeling-driven management. This team is present at each hackathon and some of members have been present since the very first hackathon. We would for sure win the “best continuing work” prize, assuming one exists ;-). And the tools development continue in between IETF meetings, for everybody’s benefits.
Since the hackathon two weeks ago, the work has continued:
- Mahesh Jethanandani improved all the draft MEF YANG modules (they now pass validation), populated them in the catalog via the APIs (another good way to test the APIs), along with all the metadata. As a example, look here.
- We also augmented our metadata information. For example, we’re now able to report the YANG tree type:split, nmda-compatible, openconfig, etc. You can expect the new version of “YANG module for yangcatalog.org” pretty soon.
- A replacement tool for the YANG Explorer, which has the drawback of being-flashed based
- And much more…
To get updates about changes with YANG Catalog, subscribe to announce@yangcatalog.org.
Regards, Benoit (Operations and Management Area Director)
Comments are closed, but trackbacks and pingbacks are open.