Just before the IETF 95 in Buenos Aires, let’s analyze the current state of affairs in the YANG Data Models world.

As anticipated by the IESG some time ago (and for which the IESG reorganized itself), the YANG data models trend continue, with about 200 YANG data models in the IETF drafts now, on top of the already published ones.

This trend is also observed in different Standard Development Organization such as the BBF (Broadband Forum), the Metro Ethernet Forum (MEF), the Institute of Electrical and Electronics Engineers (IEEE), without forgetting the opensource projects OpenDaylight and Open Config.

In January, ETSI NFV organized an Information Modelling Workshop, which brought together participants from 3GPP, ATIS, Broadband Forum, DMTF, ETSI NFV, IETF, ITU-T SG15, MEF, OASIS/TOSCA, Open Cloud Connect, ONF, OpenDaylight, OPNFV and TM-Forum. The goal was to collaborate on the information model and data model in this SDN and NFV world. I participated as OPS AD, stressing the importance of data models and of YANG as THE data modeling language. Presentations can be downloaded here.

The YANG Model Coordination Group has been spending time on the inventory of those YANG models in the industry, the tooling aspects, the help with the compilation, the training & education (NETCONF, YANG, pyang), the coordination across SDOs/opensource, the model coordination with the IETF. On the tooling front, the YANG model extraction and compilation is now integrated in the IETF draft submission tool, thanks to Henrik Levkowetz. So no more excuses for producing YANG models that don’t compile.

The industry demands open YANG data models right now. Indeed, YANG data models is the basis for the data-model driven management which allows automation. So with so many YANG data models in IETF drafts right now, why does it take so long to publish the final RFCs? Let me expand on two reasons.

The first reason is that the NETMOD and NETCONF community has been busy with some key deliverables lately.
– YANG 1.1: Based on the development and implementation experience of some of the YANG models, the 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.
– RESTCONF: HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF, and two companion documents: the YANG Patch Media Type   and the YANG Module Library
– JSON Encoding: The definition of encoding rules for representing configuration data, state data, parameters of RPC operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. While NETCONF supports the XML encoding, RESTCONF supports both the XML and JSON encodings
– YANG Metadata: The definition of a YANG extension statement that allows for defining metadata annotations in YANG modules.
– NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively.

Now that those major deliverables are in their final stages, the NETMOD and NETCONF WG resources will be free to tackle the next challenge.

The second reason 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 each others. The end goal is to automate the creation of services (like the L3VPN service data model effort, which is almost complete), in a physical or virtual environment. If you consider the coordination of all the YANG data models within the IETF difficult, think twice, as the coordination is actually required for an entire industry. Before publishing the 200 YANG data models, we need to solve two important issues, which will influence the design of all standard data models:

1. How to consistently model the operation status? NETMOD already collected the operational state requirements and now works on the solution space.
2. How to structure all those models? As a practical example, how do we model the logical and virtual resource representations that may be present on a network device, such as Virtual Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs). Should all YANG data models contain a logical network element container, just in case a router supports a VRF or VSI? On that front, the NETMOD WG is currently working on “mount” solution, a mechanism to combine YANG modules into the schema defined in other YANG modules. This mechanism would allow a simplification of the device model, particularly for “lower-end” devices which are unlikely to support multiple network instances or logical network elements.

Once those two issues are resolved, this will for sure open the gate to publish all these much-needed models.

I’m not only a strong believer in data modeling driven management, but a strong believer in standard data models. The standard aspect, based on the consensus based approach, requires some time, but this is the price to pay for standard-based automation.

Benoit Claise, OPS Area Director