In 2003, Request for Comment (RFC) 3535, “Overview of the 2002 IAB Network Management Workshop”1 documented the outcomes of a dialog between network operators and protocol developers about focusing the IETF on future network management work. The workshop identified 14 operator requirements and identified ‘ease of use’ as a key requirement for any new network management system. This ease of use includes an ability to manage a network, not just a device in the network, and asserts that there should be a clear distinction between the configuration, operational, and statistical information of the device. The requirements also include the ability to stage a configuration, validate it before committing, and roll back to the previous configuration in case of failure.
These 14 operator requirements led to the creation of the NETCONF Working Group (WG) that same year, the NETMOD Working Group in 2008, and the development of core data models for network management. The work resulted in XML-based Network Configuration Protocol (NETCONF) RFCs 6241, 6242, 6243, and 6244 in 2011 (respectively revised from 4741, 4742, 4743, and 4744), and the associated data modeling language YANG RFCs 6020 and 6021 in 2010.
Over the last couple of years, NETCONF and YANG have gained traction in the networking industry. They’ve moved from the definition phase into the implementation phase. At the IETF, the number of YANG models under development has seen incredible growth. New YANG models are being developed in the Operations and Management (OPS) area, as well as in the Routing (RTG), Internet (INT), Transport (TSV), and Security (SEC) areas. But the most impressive YANG model adoption comes from the open source OpenDaylight project, where the Lithium release has seen the publication of more than 480 YANG models2.
Other Standards Development Organizations (SDOs) have also initiated YANG model development projects. For example, Metro Ethernet Forum was an early pioneer in developing Service OAM (SOAM) Fault Management (FM) and Performance Management (PM) YANG models; it is currently working onservice-level YANG models3 (Figure 1). In addition, the Institute of Electrical and Electronics Engineers (IEEE), has approved a project for 802.1x and 802.1q models, with interest in developing an 802.3 model. Similarly, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) is seeing interest in the development of a G.8032 model. Models from all the SDOs can be found inGitHub (https://github.com/YangModels/yang).
The rapid growth in the number of YANG models is not without its challenges, primary among them is the coordination of models. While all models do a great job of defining how particular features can be configured or monitored, they also must interact with models being developed in both the IETF and other SDOs. The first practical coordination is happening in the routing area undertaken by the Routing Area YANG Coordination Forum4. Coordination of the YANG development work in the IETF and other SDOs falls under the umbrella of the Operations and Management Area (OPS) area director, Benoît Claise, with the help of the YANG Model Coordination Team5.
IETF Working Groups that cover aspects of YANG model development include:
LIME (OAM YANG models)
L3SM (L3VPN service YANG model)
SUPA (consistent policy YANG models)
I2NSF (security-related YANG models)
To help with the development of YANG models, the YANG doctors6 are available both via email and during the week of IETF meetings in YANG advice/editing sessions. In addition, there are several tools available for the development and compilation of YANG models (seehttp://trac.tools.ietf.org/area/ops/trac/wiki/YangModelCoordGroupfor a complete list).
Probably the most important tool is pyang, a python-based YANG compilation tool that does syntactic checking and enables generation of output formats, such as UML, a tree based model, YIN, and so forth. These tools must be run with an IETF option set in order to check for YANG guidelines in RFC 6087. Many YANG models still don’t compile correctly (seehttp://www.claise.be/IETFYANGPageCompilation.html). An online, graphical equivalent of the pyang tool is found at http://yangvalidator.com; it takes a YANG file or an IETF draft/RFC, extracts the model, and then validates the model.
Thanks to the extent of the development and implementation experience of some YANG models, the NETMOD WG has been getting feedback on YANG 1.0. Based on the feedback, a YANG version 1.1 is currently being finalized. This new version is a maintenance release of the YANG language; it addresses ambiguities and defects in the original specification.
With NETCONF and YANG specified, operators can start using them for configuration and monitoring. Some operators, however, have already started to use the proprietary REST APIs provided by different vendors to manage their networks. RESTCONF is a REST-like protocol running over HTTP for accessing the data defined in YANG. The REST-like API is not intended to replace NETCONF, but rather provide a simplified interface, thereby meeting a need of application developers. For that reason, the NETCONF WG decided to add support for the RESTCONF protocol in its charter. RESTCONF supports two encoding formats: XML and JSON.
Although often overlooked 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 Notifications7 and the development of a subscription-and-push mechanism that allows client applications to request notifications about changes in the data store. These capabilities will open NETCONF to the world of telemetry: pushing data towards the network management system (NMS) applications.
One result of the popularity of YANG is that now operators wanting to develop their own protocol for management use YANG as the data modeling language. This includes CoMI, which defines a management interface for constrained devices. Even among existing protocols NETCONF and RESTCONF, there are different encodings (e.g., XML and JSON) for YANG models.
Ultimately, what counts is the data models. There is a clear need across the industry for standard data models in order to ease the management and, more precisely, the programmability of multivendor networks. YANG has clearly positioned itself as the data model language for these standard models. It is up to us at IETF to coordinate all the YANG models if we want them to work seamlessly together.
References
1 http://tools.ietf.org/html/rfc3535.
2 http://www.claise.be/YANGPageMain.html.
3 https://wiki.mef.net/ (requires login).
4 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoord.
5 http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html.
6 http://www.ietf.org/iesg/directorate/yang-doctors.html.
7 http://datatracker.ietf.org/doc/rfc5277/.