YANG Catalog Latest Developments (IETF 100 Hackathon)

As a reminder, we have been present since the very first hackathon at IETF 92. Even though many were not physically present in Singapore, we represented a virtual team of many members. This virtual team included those who have worked through on the year on projects, including some full time on tool development and maintenance. The team won the “Best Continuing Work” award during this IETF 100 hackathon and this is well deserved. And no, I’m not THAT biased .

This summary contains the hackathon achievements and an update since the previous hackathon in July. As background information on the previous developments, feel free to review the YANG Catalog Latest Developments (IETF 99 Hackathon) here.

Dave Ward stressed the importance of the YANG Catalog during his presentation at IETF 100 titled, “3 years on: Open Standards, Open Source, Open Loop.” (video here, slides here). His point (among others) was that the IETF should focus on the deployment of the product of the RFCs (so YANG modules in this case) as opposed to the RFC publication. Here are a couple of Dave’s relevant quotes: “Publishing an RFC SHOULD not be the metric for IETF success!”, “A technology is successful when it’s deployed.”, “Develop tooling & metadata at the same time as specification.”, “Create your dependency map and reach out to your IETF customers.”. The YANG catalog was taken as THE example in this train of thought.

At this hackathon, Joe Clarke and Miroslav Kovac demonstrated a new tool called YANG Suite, along with its integration with the YANG catalog set of tools and its integration with the YANG Development Kit (YDK).

You might remember the YANG Explorer tool, an useful tool, demonstrated a few IETF hachatons ago. It has been suffering from an important inconvenience: it is flash-based. YANG Suite is the next generation YANG Explorer, without this limitation.

YANG Suite automatically imports YANG modules (and dependent YANG modules) from the catalog.  The YANG module trees are parsed and displayed. From there we can generate CRUD (Create, Read, Update, Delete) RPCs, by interacting with the GUI. YANG Suite also integrates with YDK, which facilitates network programmability using YANG data models. YDK can generate APIs in a variety of programming languages using YANG models. These APIs can then be used to simplify the implementation of applications for network automation. YDK has two main components: an API generator (YDK-gen) and a set of generated APIs. Today, YDK-gen takes YANG models as input and produces Python APIs (YDK-Py) that mirror the structure of the models.

If you prefer a different set of python tool, YANG Suite also offers ncclient python library for NETCONF server. If you want to generate APIs from another language, you can develop a new YANG Suite package. As always, the tools are opensource: This is work in progress and the documentation will follow soon.

With the goal in mind to create a full toolchain, we integrated the YANG Suite directly in the YANG catalog, as shown in the previous figure. What does it mean? From the YANG catalog, you search for the relevant YANG module(s), evaluate its relevance with some health metrics (validation result, maturity, number of import, etc.), check the related metadata, launch the YANG Suite, and generate the python script based on the introduced value in the GUI such as YANG module content, CRUD operations, datastore, etc. The end user can now focus on automation as opposed to having to know the YANG language. For the end user, YANG is a means to an end, and should be hidden.

For the IETF draft writers, Henrik Levkowetz added links to the YANG catalog metadata and impact analysis directly in the data tracker. A real gain of productivity! The next step is to work on the  synchronization of the data, with an direct update as soon as the draft is posted.

In terms of metadata, we have introduced new ones (see draft-clacla-netmod-model-catalog):

•  Dependencies and dependent YANG modules
  Use case: Provide a comprehensive store for metadata from which to drive tools
•  Tree type: NMDA, transitional-extra, openconfig
  Use case: Illustrate whether or not modules are NMDA-compliant
•  Add leafs for semantic versioning (semver): semantic_version and derived_semantic_version
  Use case: Given a module, compare its semantic version over multiple revisions to understand what types of changes (e.g., backward-incompatible changes) have been made.Do the same given a vendor, platform, software release for all modules

Below is an example of semantically different YANG module revisions.

Vladimir Vassilev worked on automated testcases, running against confd and netconfd based raw NETCONF session scripting. Practically he focused on the the ietf-routing YANG modules in netconfd, both the non-NMDA and the NMDA (in progress) versions. I believe associating some validation tests with YANG modules in the catalog would be an extremely useful addition. Recently, I received the feedback that working on very simple scenarios for service YANG modules is a complex task: working from example is the way to go.

https://www.ietf.org/blog/wp-content/uploads/2017/11/semvver-2.jpg

Pieter Lewyllie developed an REST API for the regex validator,  the YANG regular expression validator to experiment with W3C YANG “pattern” statements.

We’re committed to maintaining and continuing to develop these tools. If you want to join the effort, you know where to find us:

• Contribute to the Catalog at https://yangcatalog.org/contribute.php
• Updates about the Catalog at announce@yangcatalog.org