- 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
Data Model–Driven Management Components
Data model–driven management is built on the idea of applying modeling languages to formally describe data sources and APIs. This includes the ability to generate behavior and code from the models. YANG is the data model language of choice; it allows a modeler to create a data model, to define the organization of the data in that model, and to define constraints on that data. Once published, the YANG module acts as a contract between the client and server, with each party understanding how its peer expects it to behave. A client knows how to create valid data for the server and knows what data will be sent from the server. A server knows the rules that govern the data and how it should behave.
As displayed in Figure 2-4, which covers the data model–driven management components, once the YANG models are specified and implemented, a network management system (NMS) can select a particular encoding (XML, JSON, protobuf, thrift, you name it) and a particular protocol (NETCONF, RESTCONF, or gNMI/gRPC) for transport. Yes, there are differences in capabilities between the different protocols and, yes, there are some limitations in the combination of the encodings and protocols (marked by the arrows in the figure), and those are reviewed later in this chapter.
Figure 2.4 The Data Model–Driven Management Components
Typically, an orchestrator delivers service automation through multiple protocols/encodings. Based on the encoding and protocol selections, you can generate behavior or code to access the YANG objects on managed devices (for example, in Python, C++, Go, or basically any programming language). Note that as time passed, more and more arrows were added to this figure. In the end, all combinations become possible.
Orchestrators use code generation in their automation. A good showcase to demonstrate data model–driven management concepts and how the related code is rendered might be an open source tool such as the YANG Development Kit (YDK), which provides APIs directly based on YANG models and ready to use in scripts. The main goal of YDK is to reduce the learning curve involved with YANG data models by expressing the model semantics in an API and abstracting the protocol/encoding details. Example 2-1 shows a sample Python program illustrating the use of a generated API, oc-interfaces.py, which in turn is derived from the open-config-interfaces YANG module.
Obviously, other tools for code generation exist; for example, in the world of OpenConfig, see http://www.openconfig.net/software/.20
Notice that the primary source of information to generate code is the set of YANG modules. This is the reason why the IETF and the industry in general are spending so much energy specifying these YANG modules as precisely as possible.