YANG Catalog Latest Development (IETF 99 Hackathon)

The IETF 99 is now over. Building on this tradition to write a blog explaining the progress of this YANG Catalog (here is the blog for the IETF 98), let me explain the latest developments from the IETF hackathon, 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, an IEEE/IESG meeting took place on Saturday afternoon, during the IETF hackathon week-end. We demoed our tool, explaining the benefits to both the IEEE and IETF. During the demo, 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, we should stress the most up-to-date. In a typical hackathon fashion, the next day, YANG DB search contained a new option: « Only Show Latest Revisions », on by default.

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.






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 a nutshell,

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

The 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. 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: 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 those APIs (including authorization and authentication) and William Lupton from BBF validated them, introducing all BBF modules and metadata. 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.

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
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 « most consistent hackathon project » 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.

To get updates about changes with YANG Catalog, subscribe to announce@yangcatalog.org.

Regards, Benoit (Operations and Management Area Director)


Les commentaires sont fermés, mais les rétroliens et les pings sont ouverts.