[Slightly improved from in the IETF Journal, for the IETF 94]

In 2003, RFC 3535, “Overview of the 2002 IAB Network Management Workshop” documented the outcomes of a dialog started between network operators and protocol developers to guide the IETFs focus on future work regarding network management. The workshop identified 14 operator requirements. Some of the requirements outlined by the operators include an ease of use of any new management system. This ease of use includes an ability to manage a network and not just a device in the network. That there should be clear distinction between configuration, operational and statistics information of the device. It should also be possible to stage a configuration, to validate it before committing, and to roll back the previous configuration in case of failure.

Those 14 operator documented requirements led to the sequential creation of the NETCONF Working Group the same year, the NETMOD Working Group in 2008, and the development of core data models. The work resulted in XML-based Network Configuration Protocol (NETCONF) RFCs 6241, 6242, 6243, and 6244, in 2011 (respectively revised from 4741, 4742, 4743, 4744) and the associated data modeling language YANG RFCs 6020 and 6021 in 2010.

For the last couple of years, NETCONF and YANG have started to gain traction, moving from a definition phase into an implementation phase. At the IETF, the number of YANG models currently under development has seen an incredible growth. New YANG models are not only seen in the OPS area, but also in the RTG, INT, TSV, and SEC areas.

The most impressive YANG model adoption however comes from the OpenDaylight opensource project where the Lithium release includes more than 480 YANG models.

Other Standard Development Organizations (SDOs) have also seen projects being requested or started to develop YANG models. For example, the Metro Ethernet Forum was an early pioneer in developing a Service OAM (SOAM), Fault Management (FM), and Performance Management(PM) YANG models and is currently working on service level YANG models (requires a login). The IEEE, has approved a project for 802.1x and 802.1q models, with interest in developing an 802.3 model. Similarly, the ITU-T is seeing an interest in the development of a G.8032 model. Models from all the SDOs can be found in GitHub.

The rapid growth of YANG models has not come without its challenges. Primary among the challenges is the coordination of all these models. While all models are doing a great job of defining how a particular feature can be configured or monitored, they need to interact with other models that are being developed – not only in IETF but other SDOs. The first practical coordination is happening in the routing area where The Routing Area YANG Coordination Forum has been doing a great job. Coordination of the YANG development work in IETF and other SDOs falls under the umbrellas of the OPS Area Director, Benoit Claise, with the help of YANG Model Coordination Group.

The IETF has seen a few working groups created with YANG model development in mind. They include:
– LIME, focusing on OAM YANG models
– L3SM, focusing on a L3VPN service YANG model
– SUPA, focusing on consistent policy YANG models
– I2NSF, focusing on security related YANG models.

To help with the development of YANG models, the YANG doctors are available via email, but also during the IETF week with the YANG advice/editing session. There are several tools available for the development and compilation of YANG models. For a complete list of tools check out this site. Probably the most important of them is pyang, a python based YANG compilation tool that does syntactic checking of the model and allows generation of output formats including UML, a tree based model, YIN etc. This tools needs to be run with “–-ietf” (pyang –-ietf) option, to check for YANG guidelines in RFC 6087. There are many YANG models that still don’t compile correctly. The graphical equivalent of the pyang tool is a web based tool that can take a YANG file or an IETF draft/RFC, extract the model and validate the model.

With the development and implementation experience of some of the YANG models, the NETMOD WG has been getting feedback on YANG 1.0. Based on the feedback, a YANG version 1.1 is now being finalized. This new version is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.

With NETCONF and YANG specified, operators could start to use them for configuration and monitoring. However, some operators had already started to use proprietary REST APIs provided by different vendors to manage their boxes. RESTCONF is a REST like protocol running over HTTP for accessing data defined in YANG. The REST-like API is not intended to replace NETCONF, but rather provide a simplified interface for application developers. Therefore the NETCONF WG decided to add support for the RESTCONF protocol in their charter. RESTCONF supports two encoding formats, XML and JSON.

Often forgotten as a capability, devices can also send notifications defined in the YANG model. The newly adopted NETCONF charter includes an update to the NETCONF Event Notifications and the development of a subscription and push mechanism that allows client applications to request notifications for changes in the datastore. These capabilities will open NETCONF to the world of telemetry, i.e. pushing data towards the NMS applications.

The popularity of YANG has led to operators wanting to develop their own protocol to use YANG as the data modeling language. This includes CoMI (Constrained Application Protocol for Management Interface) that defines a management interface for constrained devices. Even amongst existing protocols, NETCONF and RESTCONF, we see different encodings (XML, JSON) for YANG models. Ultimately, what counts is the data models. And there is a clear need across the industry for standard data models, as a way to ease the management and more precisely the programmability of multi-vendor networks. YANG has clearly positioned itself as THE data model language for these standard models. Most SDOs are adopting this language, and the adoption is coming fast. It will be up to us at IETF to coordinate all the YANG models for them to work seamlessly.

Mahesh Jethanandani and Benoît Claise