- The Beginning: A New Set of Requirements
- Network Management Is Dead, Long Live Network Management
- YANG: The Data Modeling Language
- The Key to Automation? Data Models
- The Management Architecture
- Data Model-Driven Management Components
- The Encoding (Protocol Binding and Serialization)
- The Server Architecture: Datastore
- The Protocols
- The Programming Language
- Telemetry
- The Bigger Picture: Using NETCONF to Manage a Network
- Interview with the Experts
- Summary
- References in This Chapter
This chapter is from the book
This chapter is from the book
This chapter is from the book
Interview with the Experts
Q&A with Jürgen Schönwälder
Jürgen Schönwälder is professor of computer science at Jacobs University Bremen. His research interests include network management and measurement, network security, embedded systems, and distributed systems. He has co-authored more than 40 network management–related specifications and standards in the IETF, with major contributions to network management protocols (SNMP and NETCONF) and associated data modeling languages (SMIv2, SMIng, and YANG). He supervised the work on YANG 1.1 while serving as co-chair of the NETMOD working group.
Question:
Jürgen, you have been a key designer for many protocols and data models at the IETF, starting with SNMP, MIB, NETCONF, RESTCONF, and YANG. What is so special about data model–driven management based on YANG?
Answer:
Network management was always about automation. I got involved in network management technologies in the early 1990s, when SNMP became widely implemented and deployed. The design of SNMP was relatively simple (let’s ignore the ASN.1/BER details, which clearly were not that simple), but due to the way data was organized and communicated, SNMP was relatively difficult to use to automate configuration tasks. Even basic operations like retrieving a snapshot of the configuration of a device for backup and restore purposes was difficult to implement via SNMP. (Some devices allowed you to trigger configuration snapshots via SNMP, but the configuration data was then typically delivered via FTP in a proprietary format.)
Given the assembly language nature of SNMP, operators often found it more convenient to configure devices via proprietary command-line interfaces. Since command-line interfaces were not designed to be used as programmatic APIs, automation via scripted command-line interfaces turned out to be somewhat brittle since the data representation was often optimized for human readers but not for programmatic access.
While there were attempts to evolve the SNMP technology and its data modeling language at the beginning of this millennium, they failed to reach sufficient momentum, and the IETF finally started an effort to create a new management protocol to solve the configuration management problem. The goal was to provide a robust API to manage the configuration of a device. Once the initial protocol work was done, a group of people gathered in 2007 to design a data modeling language supporting the new configuration protocol, which was the origin of YANG. All this took place at a time where XML and XML Schema were hot topics in the industry, but the designers of YANG felt that a domain-specific language was needed that’s easier to read and write than XML Schema and is designed to assemble rather complex data models in an incremental fashion.
At the same time, configurations of devices became increasingly dynamic, amplifying the need for robust configuration transactions running almost constantly and affecting many devices. The YANG language started to fill a niche, as it was readily available, including basic tool support. While YANG originally used XML to encode instance data, it was relatively straightforward to support other data representations. In addition, the YANG language was designed to be extensible. As a consequence, vendors and operators were able to replace proprietary APIs with APIs that were driven by YANG data models, even though in several cases nonstandard data encodings and protocols were used. The fact that YANG allowed this to happen was a benefit for its adoption. Another driving force was the movement toward software-defined networks, where certain control functions are moved from devices to external controllers. YANG started to play a role here as well, both as an interface to the devices managed by a controller (the southbound interface) but also as a higher-level interface toward other controller and service management systems (the northbound interface).
While YANG was a success story, there is ongoing work to further improve the technology. Just recently, an architecture for network management datastores was published, which develops the architectural concept of datastores, on which YANG rests, further. Once implemented, applications managing devices or controllers will be able to access configuration data at different stages in the internal configuration processing workflows of devices and controllers and key metadata becomes available, explaining how a specific setting became effective, which enables new applications that can reason about why the actual behavior of a device differs from its intended behavior.
Data-driven management via programmatic APIs derived from YANG data models started to evolve network management toward service management. In the future, one can expect that there will be less focus on the individual devices and their APIs. Novel network and service programming concepts will appear, allowing network operators to build and extend service management systems orchestrating complex services at a much higher pace than ever before.