Xyna & NETCONF & YANG
Xyna Bulletin #22
Dear friends, partners, and customers of Xyna,
No April Fools' joke – the latest bulletin newsletter is presented to you today by me as a guest author: I'm Kai from Xyna Consulting & Innovation; many of you might know me, as I've been involved in numerous projects and product developments over the past 15 years.
In a few weeks, the legendary IAB Network Management Workshop [RFC3535] will be 23 (!) years old. Back then, the foundation for the development of the NETCONF protocol was laid. The goal was to finally move away from CLI scripting, which, according to participants' estimates, was used to perform around 70% of network configurations at the time.
Well, over the past 20 years, we've also come across NETCONF (and the later proposed YANG data modeling) at one point or another. A great project, but the ultimate goal of a market-dominating methodology hasn't been achieved yet – and is probably utopian. The use cases and scenarios of today's provider networks are too diverse for that.
And yet, we are seeing a renaissance of NETCONF & YANG in various areas, so much so that last year we began developing and expanding functions for modeling NETCONF RPCs based on standardized YANG structures. With the recently released version 10.3, Xyna brings a fresh wave of additional features.
Enjoy reading!
Best regards from Mainz,
Dr. Kai Schorstein
::
Xyna NETCONF & YANG
The development of NETCONF (Network Configuration Protocol) and YANG (Yet Another Next Generation) began in the early 2000s, when the need for better network management tools became apparent due to the increasing complexity and size of networks.
NETCONF was originally developed by the IETF to provide a better alternative to existing configuration protocols such as SNMP and CLI. The first version of NETCONF [RFC 4741] was published in December 2006. It aimed to create a standardized interface for configuring network devices, complemented by useful features such as transaction-based changes (implemented via versioned config datastores in the NETCONF server), which commit network configurations only upon complete and successful execution.
In parallel, YANG was developed as a modeling language for the data transferred by NETCONF. YANG was designed to overcome the shortcomings of existing data modeling languages: in particular, the models should be both machine-readable and easy for humans to understand. YANG was officially published in October 2010 [RFC 6020].
In summary, YANG provides the structure and parameters that can be configured (the configurable elements of the network device, e.g., routing protocols, services on ports, or security settings), while NETCONF represents the protocol with which the configuration data is exchanged securely and efficiently between the management system and the network device. "Exchanged" because NETCONF was designed from the outset to allow messages to be sent "downstream" from the provisioning system to the network via RPCs, and, conversely, messages and status from the network to be passed back "upstream" in the form of notifications.
In newer (SDN) scenarios, multi-level settings are often found, based on TM Forum domain structures or other layering paradigms. Here, Xyna can assume the role of both a higher-level orchestrator and a network-level controller thanks to its flexible configuration via modeled workflows and services:
The concrete implementation in Xyna, illustrated below using the example of a top-down RPC for service provisioning, essentially takes place in three major steps:
1a) Importing Models
By importing the YANG modules, the basic data structures are created in the factory. We support both open (e.g., IETF or OpenConfig) and native models (e.g., from Cisco or Juniper). Additionally, the vendor-specific device capabilities are read in or queried via a yang-library request.
This is where the tension between standardization (IETF, ETSI, etc.) and native models becomes apparent: due to proprietary extensions, especially for complex services, the NETCONF client must be able to handle vendor-specific extensions and interpretations in the YANG model. It remains the task of the activation system to provide the configuration parameters in the required structure for each network element.
2) Modeling Operations
Operations are elementary transactions between the client (Xyna in the role of controller) and the server (device), which are defined via capabilities. An operation, for example, is an atomic command to persist the current /running config in the config datastore.
Xyna supports all relevant YANG structures (keywords) such as leaf, deviations, identity, extension, feature, list, choice, assignments, etc.
3) Automation Workflows
In the final step, the basic operations can be further developed into complex fulfillment workflows in the style of the usual Xyna models and integrated into a system and process landscape.
::
NETCONF & YANG – A miracle tool for everything?
As always and forever: nothing is just great and works perfectly. NETCONF and YANG also have their advantages and disadvantages, perhaps due to their long history and the key areas that were important in network management 20 years ago.
We've written a bit above about the advantages and opportunities of API-based, standardized network configuration. One of the biggest challenges is probably the strong focus of device support on service configuration—the "PUSH" component. The PULL area (monitoring, events, status), which was included from the beginning via the notification mechanism, hasn't made it into reality as much over time. Which is a shame, because the more dynamic networks become, the more important a 360° view of the network becomes—not just configuration (and monitoring via separate channels), but a mindset more toward integrated DevNetOps for true closed-loop operation.