Transition Plan Enters New Phase
Many of us have been working over the last two years on a small change to the way the IANA functions are managed.
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: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.
Many of us have been working over the last two years on a small change to the way the IANA functions are managed.
My previous blog post was about the IETF BoFs, but there are also new meetings in the research arm of the IETF, the IRTF.
With the preliminary agenda just published (or soon will be), I wanted to report what Birds-of-Feather (BoF) sessions there will be at IETF-95. This time there is quite a lot of work following up on a recent IAB workshop on the effect of encryption on network operators.
Some time ago I mentioned the Internet of Things Semantic Interoperability (IOTSI) workshop organised by the IAB. This workshop is important for the work on application data formats, semantic definitions, and interoperability in the Internet of Things space.
This blog post is not about technology. A while ago I asked for volunteers to help us understand some of the non-technical changes around the IETF.
Show all