- 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
YANG: The Data Modeling Language
YANG has been mentioned numerous times so far, but what is it exactly? YANG is an API contract language. This means that you can use YANG to write a specification for what the interface between a client and server should be on a particular topic, as shown in Figure 2-1. A specification written in YANG is referred to as a “YANG module,” and a set of YANG modules are collectively often called a “YANG model.” A YANG model typically focuses on the data that a client manipulates and observes using standardized operations, with a few actions and notifications sprinkled in. Note that, in the NETCONF and RESTCONF terms, the controller is the client and the network elements are the server, as the controller initiates the configuration session. It’s interesting to note that YANG is not an acronym—at least, it’s never expanded or referenced as an acronym in any documentation. However, there is a special meaning behind the term, as a kind of joke. Indeed, it stems from Yet Another Next Gen (data modeling language).
)
Figure 2.1 The Basic Model
Say you are designing the next cool server application. This application may or may not have some sort of interface for ordinary users, but it will almost certainly have a management interface, which the owner of the application can use to administrate and monitor the application. Obviously, this administrative interface needs to have a clear and concise API.
A YANG-based server publishes a set of YANG modules, which taken together form the system’s YANG model. These YANG modules declare what a client can do. The four areas listed next are the same for all applications, but the specific data and operations will vary. For the sake of clarity, let’s say that the application is a router. Other applications might have wildly different kinds of data and operations—it all comes down to what the YANG model contains.
Configure: For example, decide where the log files are stored, state which speed a network interface uses, and declare whether a particular routing protocol is disabled or enabled, and if so, which peers it will have.
Monitor status: For example, read how many lost packets there are on each network interface, check what the fan speeds are, and list which peers are actually alive in the network.
Receive notifications: For example, hear that a virtual machine is now ready for work, be warned of the temperature crossing a configured threshold, or be alerted of repeated login failures.
Invoke actions: For example, reset the lost packet counters, run a traceroute from the system to some address, or execute a system reboot.
As the author of the next cool application, it is up to you to decide what goes in the YANG module for your application. In the context of YANG, the application is an abstract service, such as a Layer 3 virtual private network (L3VPN) or access control service. Those applications often use networking devices, such as a router, load balancer, and base station controller. They could equally well be devices from other domains, such as a power distribution grid controller, a warehouse robot control system, and an office building control system. What else goes in your YANG module? In collaboration with the application operations engineer, you are perhaps able to select which authentication mechanism the application will use and where the authentication server sits. You may also want to provide the operations engineer with an operational status field indicating how many users are currently served by your application. Maybe the application will have a notification to report users abusing the application in some way? How about an action to produce a debug dump of the database contents for troubleshooting? In the end, your application would probably have a lot more that goes in the management interface.
The YANG model of a device is often called its “schema,” as in database schema or blueprint. A schema is basically the structure and content of messages exchanged between the application and the device. This is very different from the instance data—the actual configuration and monitoring data in the system. The instance data describes the current configuration and the current monitoring values. The schema describes the potential configuration, potential monitoring data, potential notifications, and potential actions a manager decides to execute.
The YANG language also incorporates a level of extensibility and flexibility not present in other model languages. New modules can augment the data hierarchies defined in other modules, seamlessly adding data at appropriate places in the existing data organization. YANG also permits new statements to be defined, allowing the language itself to be expanded in a consistent way. Note that the YANG model (keep in mind the API contract) does not change unless there is a software upgrade of the server, or perhaps if a license for a new feature is installed. The instance data changes as soon as a manager decides to change the configuration or if the system state changes due to internal or external events.
A small YANG model may declare just a dozen different elements, or even a single one (for example, a model that just defines the reboot operation). Some YANG models are very large, however, with thousands of elements. In a car or factory, each element would correspond to a button, control dial, indicator gauge, meter, or light. A modern car might have over a hundred elements on the dashboard and around the vehicle. A nuclear power plant might have over a thousand. Core routers are vastly more complicated, however, with well over 100,000 control interface elements.
Since the schema defines elements that can have many instances (for example, interfaces or access control rules), the instance data can be very much larger than the schema, with many millions of instances.
The YANG language itself is defined by the Internet Engineering Task Force (IETF).13 The latest version is YANG 1.1, defined in RFC 7950, and YANG 1.0 is an older version defined in RFC 6020. As of this writing, both YANG 1.0 and YANG 1.1 are in popular use. This new YANG 1.1 (RFC 7950) does not obsolete YANG 1.0 (RFC 6020). YANG 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. As a reference, YANG concepts are explained in Chapter 3. The extra YANG 1.1 capabilities are documented in Section 1.1 of RFC 7950. These days, YANG 1.1 should be the default when you’re writing YANG modules.