The work on YANG started as a direct response to the initial traction of the NETCONF protocol. Basically users saying that a protocol is good and well, but unless there is a formal description of the content that clients can manipulate, there may be not much win to be had. So off we went to write a data modeling language, and with some luck (e.g. we gained some help from people that had previously worked on SMI-NG) we successfully delivered.
We fired up a working group around network modeling in the IETF in 2008, submitted the first round of drafts in early 2010 and published RFC 6020 in October of the same year.
There are many exciting and challenging aspects of developing a language (looking at you, ABNF grammar). But perhaps the most interesting is to figure out if the language is expressive enough to actually capture what you expect to express.
Pragmatically, the only way to do this is to gather a set of real world examples and go through the exercise of applying the language-under-construction to them and see how it comes out. In our case we had some great networking vendor peers in the industry to work this through for the network layer (i.e. using YANG to describe box-level configuration parameters), but we also knew that we had to do it for the service layer. So we approached some service providers friendlies and asked to work with them to take their service-level offerings and try to encode them in pre-release YANG. Much to our delight (and frankly, relief) we managed to nicely break down the portfolios of both consumer (e.g. direct internet access, triple play) and business (e.g. point-to-point VPN, branch connectivity) offerings into YANG language constructs.
Not only was this valuable feedback to the YANG working group. But it was exciting enough for us as a small company at the time, that we literally built a product around the concept. It was built with the fundamental belief that YANG was to become the modeling language not only for network-layer management (i.e. routers, switches) but also for expressing service-layer constructs at the heart of the service provider value chain. This then became what is now the Network Services Orchestrator (NSO) product.
So here we are, about ten years into the life of YANG, reading the outcomes of the first openly interop-tested service-layer YANG work coming out of The European Advanced Networking Test Center (EANTC). Of special interest is the the “NETCONF/YANG” section, specifically the “L3VPN Service Creation and Termination” and “Virtual CPE Integration with NETCONF” bits.
Participation from six vendors, strict focus on service provisioning using YANG, what’s not to like! The tests involved both L2 and L3 VPNs according to published standard models (e.g. IETF L3VPN Service delivery) as well as a virtual CPE integration case with a virtual router. All managed by NSO in a variety of scenarios.
This document is well worth a read due to it’s detailed breakdown of the constituent parts and gives a clear indication of how far along we are in the industry after ten years. And I personally think it gives us a glimpse of where we may be going with this (insider hint: up the stack!)
Carl Moberg,
NSO Developer Days 2018
At Cisco Live USA, please note we will also be demoing in booth 1627.
CONNECT WITH US