Data Model-Driven Management
- 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
Provides a wide-angle perspective on the requirements for network management and automation, as well as the layers and components of the solution.
Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTICLE.
* See informit.com/terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter covers
The operator requirements, leading to the NETCONF and YANG specifications
YANG as a data modeling language
The data model properties and types
The different encodings (XML, JSON, and so on) and protocols (NETCONF, RESTCONF, and so on)
The server and client architecture
The datastore concept
Code rendering from data model–driven management
A real-life service scenario, putting all the pieces together
This chapter describes the architecture behind data model–driven management and covers high-level concepts with a minimum of technical detail. Occasionally, specific points are made or examples are given that contain concepts that have not yet been explained. Don’t fret. Chapter 3, “YANG Explained,” and Chapter 4, “NETCONF, RESTCONF, and gNMI Explained,” clarify it all. At the end of the chapter, you will understand the data model–driven management reference model and how all the different building blocks fit together.
The Beginning: A New Set of Requirements
During a workshop organized in 2002 between network operators and protocol developers, the operators voiced their opinion that the developments in IETF did not really address the requirements for network management. The “Overview of the 2002 IAB Network Management Workshop” (RFC 3535) documented the outcomes of this dialog to guide the IETF focus on future work regarding network management.
The workshop identified a list of relevant technologies (available or under active development) with their strengths and weaknesses. Among others, Simple Network Management Protocol (SNMP) and the command-line interface (CLI) were covered. As mentioned in Chapter 1, “The Network Management World Must Change: Why Should You Care?”, the SNMP protocol is not well adapted to be used for configuration but is well suited for monitoring, whereas the CLI is a very fragile application programming interface (API). Since no published material at the time clearly documented the collective requirements of the operators, they were asked to identify their needs not sufficiently addressed in standards. The results produced during the breakout session resulted in the following list of operator requirements (quoted from RFC 3535):
The output of this workshop focused on current problems. The observations were reasonable and straightforward, including the need for transactions, rollback, low implementation costs, and the ability to save and restore the device’s configuration data. Many of the observations give insight into the problems operators were having with existing network management solutions, such as the lack of full coverage of device capabilities and the ability to distinguish between configuration data and other types of data.
Some of the requirements outlined by the operators include ease of use for any new management system. This ease of use includes the ability to manage a network as a whole and not just a device in the network. In addition, there should be a clear distinction between a device’s configuration state, operational state, and statistics information. The configuration state is everything explicitly configured (for example, IP addresses assigned manually to network interfaces), the operational state is the state learned from interaction with other devices (for example, an IP address obtained from a Dynamic Host Configuration Protocol [DHCP] server), and the statistics are the usage and error counters obtained by the device. Furthermore, the requirements mention that it should also be possible to stage a configuration, to validate it before committing, and to roll back the previous configuration in case of failure.
It is important to note that, even though this document dates from 2003, its requirements and recommendations are still very valid. Every protocol designer involved in automation should read this document—and even re-read it on a regular basis. This is the primary reason for including the preceding 14 requirements in this book.
Based on those operator requirements, the NETCONF working group1 was formed the same year and the NETwork CONFiguration (NETCONF) protocol was created. This protocol defines a simple mechanism where network management applications, acting as clients, can invoke operations on the devices, which act as servers. The NETCONF specification (RFC 4741) defines a small set of operations but goes out of its way to avoid making any requirements on the data carried in those operations, preferring to allow the protocol to carry any data. This “data model agnostic” approach allows data models to be defined independently.
Lacking a means of defining data models, the NETCONF protocol was not usable for standards-based work. Existing data modeling languages such as the XML Schema Definition (XSD) [https://tools.ietf.org/html/rfc6244#ref-W3CXSD]2 and the Document Schema Definition Languages (DSDL; ISODSDL)3 were considered but were rejected because of the problem of domains having little natural overlap. Defining a data model or protocol that is encoded in XML is a distinct problem from defining an XML document. The use of NETCONF operations places requirements on the data content that are not shared with the static document problem domain addressed by schema languages like XSD and RELAX NG.
In 2007 and 2008, the issue of a data modeling language for NETCONF was discussed in the IETF Operations and Management area as well as in the Application area. Consequently, the NETMOD working group4 was formed. Initially named after “NETCONF modeling,” since NETCONF was the initial protocol to operate YANG-based devices, a recent charter update modified it to “Network modeling” to stress the fact that multiple protocols can make use of YANG modules these days.
Considering that the operators’ requirements are now 15 years old, it might seem like a long time for the data model–driven management paradigm to take off. This is a fair point, but it is important to observe that new management protocols take longer to adopt and deploy compared to nonmanagement protocols. As an example, specifying a new routing protocol (segment routing comes to mind)5 and deploying it in production may take a couple of years, but for management protocols (IPFIX6 or NETCONF comes to mind), the lifecycle is longer—up to 10 years. The reason is simple: The new management protocols must ideally be supported on all devices, old and new, as a prerequisite before the new network management systems start transitioning to the new management paradigm. However, these days, data model–driven management based on YANG/NETCONF is a well-established trend in the industry.