Skip to main content
  • Banishing the bane of bufferbloat

    Bufferbloat affects everyone who uses the Internet, resulting in frustratingly slow web browsing, laggy video calls, and overall poor quality of experience for Internet users and there's a lot of work underway in the IETF to address it.

    • Bjørn Ivar TeigenIETF Participant
    23 May 2023
  • IETF 116 post-meeting survey

    IETF 116 Yokohama was held 25-31 March 2023 and the results of the post-meeting survey are now available on a web-based interactive dashboard.

    • Jay DaleyIETF Executive Director
    26 Apr 2023
  • Reducing IETF Meeting Scheduling Conflicts

    With many IETF participants active across a number of active working groups and limited time slots in an IETF meeting week, we aim to arrange sessions in the agenda to minimize conflicts that prevent participants from joining sessions that are of interest to them. In each post-meeting survey we ask meeting participants to comment on the scheduling conflicts they experienced in the meeting agenda and we then use this information to improve the meeting agenda.

    • Alexa MorrisIETF Managing Director
    1 Apr 2023
  • Messaging Layer Security: Secure and Usable End-to-End Encryption

    The IETF has approved publication of Messaging Layer Security (MLS), a new standard for end-to-end security that will make it easy for apps to provide the highest level of security to their users. End-to-end encryption is an increasingly important security feature in Internet applications. It keeps users’ information safe even if the cloud service they’re using has been breached.

    • Nick SullivanMLS Working Group Chair
    • Sean TurnerMLS Working Group Chair
    29 Mar 2023
  • Next steps towards a net zero IETF

    Built with input from the IETF community, we now have an initial approach and tools for calculating the IETF’s carbon footprint and a strategy for carbon offsetting. For 2023, we will implement this approach with data already available and seek to further improve it for future years.

    • Greg WoodIETF LLC Director of Communications and Operations
    22 Mar 2023

Filter by topic and date

Filter by topic and date

YANG Data Models in the Industry: Current State of Affairs

  • Benoît ClaiseOperations and Management Area Director

16 Mar 2016

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.

YANG Model compilation

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 (NETCONFYANGpyang), 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.

Share this page