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 group¹ 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]² and the Document Schema Definition Languages (DSDL; ISODSDL)³ 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 group⁴ 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)⁵ and deploying it in production may take a couple of years, but for management protocols (IPFIX⁶ 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.

Network Management Is Dead, Long Live Network Management

A fundamental shift started in the industry some years ago: A transition from network operators managing the network to operations engineers automating the network. This transition resulted from the combination of multiple trends, as discussed in Chapter 1. These included the multiplication of the number of devices in the network, the increased number of network management configuration transactions per second (with the strong desire to lower the operational expenditure [OpEx]), the shift to virtualization, faster and faster services deployments, a new licensing model on a pay-per-usage basis—and maybe simply the realization that network management is essential to conduct business.

This transition brought the world of operations and development closer together. New buzzwords appeared: controller, DevOps, network programmability, management plane, network APIs, and so on. And new initiatives blossomed:

• Some in the open source world, such as OpenFlow,⁷ OpenStack,⁸ OpenDaylight,⁹ Open Vswitch,¹⁰ and OpenConfig¹¹

• Some in the research community, such as mapping the Unified Modeling Language (UML)¹² to YANG

• Some in standards organizations, such as the NETCONF and NETMOD working groups at the IETF, where some of the core building blocks for data model–driven management are specified

Interestingly, this new sandbox attracted many nontraditional, so-called network management people. Some came with a development background, some came from different technology areas, and some just surfed the wave. In the end, this was a good thing! For quite some time we were thinking of telling those people that their jobs were actually network management related. Although this was certainly the case, we didn’t want scare them away by labeling their new job with old-school terminology: network management. However, having an automation-related job is certainly cool these days. Therefore, to respect people’s sensibilities, a slightly less provocative section title would be “Network Management Is Dead, Long Live Automation,” or even “Network Management Is Dead, Long Live DevOps.”

Humor aside, the point is that the industry changed. It is common sense today to include security in all aspects of networking: from simply paying attention to the web server file permissions, to moving a web server to the secure Hypertext Transfer Protocol (HTTPS), to the full authentication and authorization mechanisms, and finally to the “let’s encrypt everything” paradigm. The industry slowly but surely will reach this point for automation. As mentioned already, some operators rightly assert nowadays, “If a feature cannot be automated, it does not exist.” Therefore, let’s assert that the coming years will be the years of automation.

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).

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).¹³ 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.

The Key to Automation? Data Models

In the world of data model–driven management, as the name implies, the essential part is the set of data models. From the data models, you deduce APIs. Figure 2-2 displays a YANG data model (granted, an incomplete one, but sufficient at this point in time) on the left and RESTCONF RPCs (GET, POST, PUT, and DELETE) to manage the respective resources on the right. Paying attention to the color scheme, notice how the RESTCONF operations are built from the YANG module keywords, showing how the APIs are generated from a YANG model.

Discussing how data models generate APIs is a good segue to stress one more time the differences between information models and data models. As specified in “On the Difference Between Information Models and Data Models” (RFC 3444), covered in Chapter 1, the main purpose of an information model is to model managed objects at a conceptual level, independent of any specific implementations or protocols used to transport the data. An extra distinction, in light of this YANG module figure, is that data models generate APIs. This is a key message: Automation is driven by APIs (not models that are a means to an end). However, an information model, typically expressed in Unified Modeling Language (UML) do not generate the full APIs, as they lack some of the implementation- and protocol-specific details (for example, rules that explain how to map managed objects onto lower-level protocol constructs). Generating APIs from UML is, however, a field of research and experimentation. In the authors’ view, if the information model would contain all the information to generate complete APIs, then that information model is really a data model.

To get a bit more concrete on the difference between an information model and data model, let’s consider an example. A UML information model might declare that a book object should have title, author, ISBN, language, and price attributes. It might say that the title should be a string, the author should be a reference to an author object, and the price should be a numeric type.

To turn that UML information model into a data model, you would need to add additional information—for example, that ISBNs need to adhere to a very particular format in order to be valid, that the author relation is mandatory while language is not, or that a book isn’t eligible for sale if its price is zero. You would also need to state that there will be a list of books called the catalog and that this list is to be indexed by title. It is only when you add this sort of detailed information that the model becomes usable as an API—that is, as a contract between the client and server where both peers know what to expect and implement for.

The Management Architecture

From an architecture point of view, there are multiple API locations, all deduced from YANG modules. A controller typically configures network elements (routers and switches in the networking world) based on the network element YANG modules—typically network interfaces, routing, quality of service, and so on—as shown in Figure 2-3.

Controllers focus on one specific network domain or a specific technology. On top of the controllers, the orchestrator configures one or more controllers based on the network YANG modules’ APIs. With the architecture in Figure 2-3 in mind, let’s introduce the notion of northbound and southbound interfaces. From a controller point of view (as an example), the northbound interface is the interface toward the orchestrator, whereas the southbound interface is the one toward the server. Operators can also automate the orchestrator northbound interface to create/modify/delete their services, based on the service delivery YANG modules. A service YANG model is the management interface toward a software application, whereas a device YANG model is generally attached to a physical or virtual device. The classical service example is a Layer 3 virtual private network, or L3VPN, which touches the configuration on multiple devices in the network, configuring network element YANG modules on each point. Then this service is decomposed in the controller, where the required servers are configured.

Note that separating the controller and orchestrator in two different systems is not a requirement: An orchestrator might also handle the tasks of the controller system or connect directly to network elements without any controller function. Examples of systems that can take on various roles in this space are OpenDaylight,¹¹ Network Services Orchestrator (NSO), Contrail, and CloudOpera.

Coming back to the different types of YANG modules, having network element YANG modules standardized for the industry offers some easier automation in case of cross-vendor development. The service delivery YANG modules, on the other hand, are mainly proprietary, as operators tend to differentiate themselves from the competition. There are two notable exceptions with the standardization of the L3VPN service delivery (RFC 8299) and L2VPN service delivery (soon an RFC). More details on the different YANG module types can be found in “YANG Module Classification” (RFC 8199) and “Service Modules Explained” (RFC 8309).

There is a need for standard mechanisms to allow system owners to control read, write, and execute access for particular parts of the YANG tree to different kinds of users. The Network configuration Access Control Model (NACM; RFC 8341) specifies the access control mechanisms for the operations and content layers of NETCONF and RESTCONF, thanks to the ietf-netconf-acm YANG module. This is the role-based access control (RBAC) mechanism most commonly used in the YANG model–driven world.

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.

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.

from __future__ import print_function
from ydk.types import Empty, DELETE, Decimal64
from ydk.services import CRUDService
import logging

from session_mgr import establish_session, init_logging
from ydk.models.openconfig.openconfig_interfaces import Interfaces
from ydk.errors import YError



def print_interface(interface):
    print('*' * 28)
    print('Interface %s'%interface.name)

    if interface.config is not None:
        print('  config')
        print('     name:-%s'% interface.config.name)
        if interface.config.type is not None:
            print('     type:-%s'%interface.config.type.__class__)
        print('    enabled:-%s'%interface.config.enabled)

    if interface.state is not None:
        print('  state')
        print('     name:-%s'% interface.state.name)
        if interface.state.type is not None:
            print('     type:-%s'%interface.state.type.__class__)
        print('     enabled:-%s'%interface.state.enabled)
        if interface.state.admin_status is not None:
            enum_str = 'DOWN'
            if interface.state.admin_status == interface.state.AdminStatusEnum.UP:
                enum_str = 'UP'
            print('     admin_status:-%s'%enum_str)
        if interface.state.oper_status is not None:
            oper_status_map = { interface.state.OperStatusEnum.UP : 'UP',
                                interface.state.OperStatusEnum.DOWN : 'DOWN',
                                interface.state.OperStatusEnum.TESTING : 'TESTING',
                                interface.state.OperStatusEnum.UNKNOWN: 'UNKNOWN',
                                interface.state.OperStatusEnum.DORMANT : 'DORMANT',
                                interface.state.OperStatusEnum.NOT_PRESENT :
                                'NOT_PRESENT',
                                }
            print('     oper_status:-%s'%oper_status_map[interface.state.oper_status])

        if interface.state.mtu is not None:
            print('      mtu:-%s'%interface.state.mtu)
        if interface.state.last_change is not None:
            print('      last_change:-%s'%interface.state.last_change)

        if interface.state.counters is not None:
            print('     counters')
            print('        in_unicast_pkts:-%s'%interface.state.counters
                           .in_unicast_pkts)
            print('        in_octets:-%s'%interface.state.counters.in_octets)
            print('        out_unicast_pkts:-%s'%interface.state.counters
                           .out_unicast_pkts)
            print('        out_octets:-%s'%interface.state.counters.out_octets)
            print('        in_multicast_pkts:-%s'%interface.state.counters
                           .in_multicast_pkts)
            print('        in_broadcast_pkts:-%s'%interface.state.counters
                           .in_broadcast_pkts)
            print('        out_multicast_pkts:-%s'%interface.state.counters
                           .out_multicast_pkts)
            print('        out_broadcast_pkts:-%s'%interface.state.counters
                           .out_broadcast_pkts)
            print('        out_discards:-%s'%interface.state.counters.out_discards)
            print('        in_discards:-%s'%interface.state.counters.in_discards)
            print('        in_unknown_protos:-%s'%interface.state.counters
                           .in_unknown_protos)
            print('        in_errors:-%s'%interface.state.counters.in_errors)
            print('        out_errors:-%s'%interface.state.counters.out_errors)
            print('        last_clear:-%s'%interface.state.counters.last_clear)

        if interface.state.ifindex is not None:
            print('     ifindex:-%s'%interface.state.ifindex)

    print('*' * 28)

def read_interfaces(crud_service, provider):

    interfaces_filter = Interfaces()

    try:
        interfaces = crud_service.read(provider, interfaces_filter)
        for interface in interfaces.interface:
            print_interface(interface)
    except YError:
        print('An error occurred reading interfaces.')


def create_interfaces_config(crud_service, provider):

    interface = Interfaces.Interface()
    interface.config.name = 'LoopbackYDK'
    interface.name = interface.config.name

    try:
        crud_service.create(provider, interface)
    except YError:
        print('An error occurred creating the interface.')



if __name__ == "__main__":
    init_logging()
    provider = establish_session()
    crud_service = CRUDService()
    read_interfaces(crud_service, provider)


    provider.close()
exit()

Obviously, other tools for code generation exist; for example, in the world of OpenConfig, see http://www.openconfig.net/software/.²⁰

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.

The Encoding (Protocol Binding and Serialization)

If YANG plus a YANG model can be compared to a language such as English, defined by a dictionary of known words and a grammar describing how the words can be combined, you still need to work out an encoding for your language before you can communicate. English has two very commonly used encodings: text and voice. The text encoding can be further divided into computer encodings like ASCII, Windows-1252, and UTF-8. Text can also be encoded as pixels of different colors in a photo file, as ink on paper, microfiche, or grooves on a stone or a copper plate.

Similarly, there are several different encodings of messages (also known as protocol bindings or serialization) relating to YANG-based models, each more or less suitable depending on the context. The most commonly mentioned (and used) YANG-related encodings are XML, JavaScript Object Notation (JSON; in two variants), and protobuf. As time has passed, new encodings have emerged. For example, this section also covers Concise Binary Object Representation (CBOR).

Figure 2-4, shown earlier in this chapter, displays the different possible encodings for a specific protocol. Keep in mind that more encodings are available all the time: It makes sense as, in the end, an encoding is just... an encoding.

The Server Architecture: Datastore

In the typical YANG-based solution, the client and server are driven by the content of YANG modules. The server includes the definitions of the modules as metadata that is available to the NETCONF/RESTCONF engine. This engine processes incoming requests, uses the metadata to parse and verify the request, performs the requested operation, and returns the results to the client, as shown in Figure 2-5.

The YANG modules, which model a specific problem domain, are loaded, compiled, or coded into the server.

The sequence of events for the typical NETCONF client/server interaction occur as follows:

1. A client application opens a NETCONF session to the server (device).

2. The client and server exchange <hello> messages containing the list of capabilities supported by each side. This hello exchange includes the list of YANG 1.0 modules supported by the server.

3. The client builds and sends an operation defined in the YANG module, encoded in XML, within NETCONF’s <rpc> element.

4. The server receives and parses the <rpc> element.

5. The server verifies the contents of the request against the data model defined in the YANG module.

6. The server performs the requested operation, possibly changing the configuration datastore.

7. The server builds the response message, containing the response itself, any requested data, and any errors.

8. The server sends the response, encoded in XML, within NETCONF’s <rpc-reply> element.

9. The client receives and parses the <rpc-reply> element.

10. The client inspects the response and processes it as needed.

The Protocols

As a quick introduction before we dive into the different protocols, Table 2-1 provides a comparison of the most common protocols used in data model–driven management: NETCONF, RESTCONF, and gNMI.

Table 2-1 Quick NETCONF/RESTCONF/gNMI Protocol Comparison

<ospf xmlns="http://example.org/netconf/ospf">

  <area>
   <name>0.0.0.0</name>

    <interface>
     <name>ge-0/0/0.0</name>
    <!-- The priority for this interface -->
    <priority>30</priority>
    <metric>100</metric>
    <dead-interval>120</dead-interval>
  </interface>

  <interface>
    <name>ge-0/0/1.0</name>
    <metric>140</metric>
  </interface>
</area>

<area>
  <name>10.1.2.0</name>

  <interface>
    <name>ge-0/0/2.0</name>
    <metric>100</metric>
  </interface>

  <interface>
    <name>ge-0/0/3.0</name>
    <metric>140</metric>
    <dead-interval>120</dead-interval>
  </interface>
 </area>
</ospf>

The Programming Language

Good scripts are based on good application programming interfaces (APIs). An API is a set of functions and procedures that allow the creation of applications that access the features or data of an operating system, application, or other service. Fundamentally, an API should provide the following features:

• Abstraction: The programmable API should abstract away the complexities of the underlying implementation. The network programmer should not need to know unnecessary details, such as a specific order of configurations or specific steps to take if something fails. Configurations should function more like filling in a high-level checklist (these are the settings you need; now the system can go figure out how to properly group and order them).

• Data specification: The key thing an API does—whether it is a software or network API—is provide a specification for the data. First, it answers the question of what the data is—integer, string, or other type of value. Next, it specifies how that data is organized. In traditional programming, that would be called the data structure—though in the world of network programmability, the more common term is “schema,” also known as “data models.”

• Means of accessing the data: Finally, the API provides a standardized framework for how to read and manipulate the device’s data.

You saw a YANG Development Kit (YDK)²⁵ example earlier (refer to Example 2-1). The main goal of YDK is to reduce the learning curve of YANG data models by expressing the model semantics in an API and abstracting protocol/encoding details. YDK is composed of a core package that defines services and providers, plus one or more module bundles²⁶ that are based on YANG models. Each module bundle is generated using a bundle profile and the ydk-gen tool. YDK-Py²⁷ provides Python APIs for several model bundles. Similarly, YDK-Cpp²⁸ includes C++ and Go APIs for the same bundles. A similar bundle exists for the C language.

Taking some more examples from the OpenConfig world this time, here are some more tools currently available:

• Ygot²⁹ (YANG Go Tools): For generating Go structures or protobufs from YANG modules.

• Goyang:³⁰ A YANG parser and compiler in the Go language.

• Pyangbind:³¹ A plug-in for pyang that converts YANG data models into a Python class hierarchy.

These examples prove one more time the importance of the toolchain, of which the programming language (C, C++, Python, Go, you name it) is just one component. Assuming that the operations engineers were developing and supporting scripts based on a specific language, it makes perfect sense to continue developing the YANG-based automation scripts in the same programming language.

Telemetry

The inefficiencies associated with a polling mechanism like SNMP needed to be removed. Network operators poll periodically because they want the data at regular intervals. So why not just send them the data they want when they want it and skip the overhead of polling? Thus the idea of “streaming” was born. Instead of pulling data off the network, you can sit back and let the network push it for you to a collector.

From Chapter 1, you already know that telemetry is a trend in the industry. Telemetry is a new approach for network monitoring in which data is streamed from network devices continuously using a push model and provides near real-time access to operational statistics. You can precisely define what data you want to subscribe to using standard YANG models, with no CLI required. It allows network devices to continuously stream real-time configuration and operating state information to subscribers. Structured data is published at a defined cadence or on-change, based on the subscription criteria and data type. Telemetry data must be structured in a sensible way to make it easy for monitoring tools to ingest. In other words, good telemetry data must be model based—hence the term data model—driven telemetry, even if everyone uses the term telemetry. The networking industry has converged on YANG as a data modeling language for networking data, making it the natural choice for telemetry. Whether you prefer your data in native, OpenConfig, or IETF YANG models, data model–driven telemetry delivers it to you.

Of course, you want all this data to be easy to use because you know that sooner or later someone will come to your desk and ask for data analytics. Telemetry data needs to be normalized for efficient consumption by Big Data tools. In the software world, encodings such as JSON, protobuf, and XML are widely used to transfer data between software applications. These encodings have an abundance of open source software APIs that make it easy to manipulate and analyze the data.

In terms of protocols, two are possible: the OpenConfig streaming telemetry and the IETF push mechanism. The OpenConfig streaming telemetry uses protobuf as the encoding: The protobuf compact mode is perfectly suited for this, as an efficient encoding (at the cost of managing the .proto files). In the IETF push mechanism, subscriptions are created over existing NETCONF sessions and are developed using XML RPCs. The establish-subscription RPC is sent from a client or collector to the network device.

Model-driven telemetry is your first step in a journey that will transform how you monitor and operate networks. With the power of telemetry, you will discover things you never imagined and will begin to ask more and better questions. More on telemetry can be found in Chapter 6.

The Bigger Picture: Using NETCONF to Manage a Network

It happens so easily when talking about management protocols that the conversation ends up being about its components—the client, server, and protocol details. The most important topic is somehow lost. The core of the issue is really the use cases you want to implement and how they can be realized. The overarching goal is to simplify the life of the network operator. “Ease of use is a key requirement for any network management technology from the operators point of view” (RFC 3535, Requirement #1).

Network operators say they would want to “concentrate on the configuration of the network as a whole rather than individual devices” (RFC 3535, Requirement #4). Since the building blocks of networks are devices and cabling, there is really no way to avoid managing devices. The point the operators are trying to make, however, is that a raised abstraction level is convenient when managing networks. They would like to do their management using network-level concepts rather than device-level commands.

This is seen as a good case for network management system (NMS) vendors, but in order for the NMS systems to be reasonably small, simple, and inexpensive, great responsibility falls on the management protocol. Thirty years of industry NMS experience has taught us time after time that with poorly designed management protocols, NMS vendors routinely fail on all three accounts.

What does NETCONF do to support the NMS development? Let’s have a look at the typical use case in network management: how to provision an additional leg on an L3VPN.

At the very least, a typical L3VPN consists of the following:

• Consumer Edge (CE) devices located near the endpoints of the VPN, such as a store location, branch office, or someone’s home

• Provider Edge (PE) devices located on the outer rim of the provider organization’s core network

• A core network connecting all the hub locations and binding to all PE devices

• A monitoring solution to ensure the L3VPN is performing according to expectations and promises

• A security solution to ensure privacy and security

In order to add an L3VPN leg to the network, the L3VPN application running in the NMS must touch at least the CE device on the new site, the PE device to which the CE device is connected, the monitoring system, and probably a few devices related to security. It could happen that the CE is a virtual device, in which case the NMS may have to speak to some container manager or virtual infrastructure manager (VIM) to spin up the virtual machine (VM). Sometimes 20 devices or so must be touched in order to spin up a single L3VPN leg. All of them are required for the leg to be functional. All firewalls and routers with access control lists (ACLs) need to get their updates, or traffic does not flow. Encryption needs to be set up properly at both ends, or traffic is not safe. Monitoring needs to be set up, or loss of service is not detected.

To implement the new leg in the network using NETCONF, the manager runs a network-wide transaction toward the relevant devices, updating the candidate datastore on them and validating it; if everything is okay, the manager then commits that change to the :running datastore. “It is important to distinguish between the distribution of configurations and the activation of a certain configuration. Devices should be able to hold multiple configurations.” (RFC 3535, Requirement #13). Here are the steps the manager takes in more detail:

STEP 1. Figure out which devices need to be involved to implement the new leg, according to topology and requested endpoints.

STEP 2. Connect to all relevant devices over NETCONF and then lock (<lock>) the NETCONF datastores :running and :candidate on those devices.

STEP 3. Clear (<discard-changes>) the :candidate datastore on the devices.

STEP 4. Compute the required configuration change for each device.

STEP 5. Edit (<edit-config>) each device’s :candidate datastore with the computed change.

STEP 6. Validate (<validate>) the :candidate datastore.

In transaction theory, transactions have two (or three) phases when successful. All the actions up until this point were in the transaction’s PREPARE phase. At the end of the PREPARE phase, all devices must report either <ok> or <rpc-error>. This is a critical decision point. Transaction theorists often call this the “point of no return.”

If any participating device reports <rpc-error> up to this point, the transaction has failed and goes to the ABORT phase. Nothing happens to the network. The NMS safely drops the connection to all devices. This means the changes were never activated and the locks now released.

In case all devices report <ok> here, the NMS proceeds to the COMMIT phase.

Next, commit (<commit>) each device’s :candidate datastore. This activates the change.

Splitting the work to activate a change into a two-phase commit with validation in between may sound easy and obvious when described this way. At the same time, you must acknowledge that this is quite revolutionary in the network management context—not because it’s hard to do, but because of what it enables.

Unless you have programmed NMS solutions, it’s hard to imagine the amount of code required in the NMS to detect and resolve any errors if the devices do not support transactions individually. In the example, you even had network-wide transactions. In a mature NMS, about half the code is devoted to error detection and recovery from a great number of situations. This recovery code is also the most expensive part to develop since it is all about corner cases and situations that are supposed not to happen. Such situations are complicated to re-create for testing, and even to think up.

The cost of a software project is largely proportional to the amount of code written, so this means more than half of the cost of the traditional NMS is removed when the devices support network-wide transactions.

The two-phase, network-wide transaction just described is widely used with NETCONF devices today. This saves a lot of code but is not failsafe. The <commit> operation could fail, the connection to a device could be lost, or a device might crash or not respond while sending out the <commit> to all devices. This would lead to some devices activating the change, while others do not. In order to tighten this up even more, NETCONF also specifies a three-phase network-wide transaction that managers may want to use.

By supplying the flag <confirmed> in the preceding <commit> stage, the transaction enters the third CONFIRM phase (going from PREPARE to COMMIT followed by CONFIRM). If the NMS sends this flag, the NMS must come back within a given time limit to reconfirm the change.

If no confirmation is received at the end of the time limit, or if the connection to the NMS is lost, each device rolls back to the previous configuration state. While the transaction timer is running, the NMS indulges in all sorts of testing and measurement operations, to verify that the L3VPN leg it just created functions as intended. And if not, simply close the connections to all the devices involved in the transaction to make it all go away. If all looks good, commit and unlock, as follows:

STEP 1. Give another <commit>, this time without the <confirmed> flag.

STEP 2. Unlock (<unlock>) the :running and :candidate datastores.

There are a lot more options and details on NETCONF network-wide transactions that could be discussed here, but the important points were made, so let’s tie this off. With this sort of underlying technology, the NMS developers can become real slackers. Well, not really, but they do get twice as many use cases completed compared to life without transactions. Those use cases also work a lot more reliably. This discussion highlights the value of network-wide transactions. “Support for configuration transactions across a number of devices would significantly simplify network configuration management” (RFC 3535, Requirement #5).

Let’s zoom out one level more and see how the network-wide transactions fit into the bigger picture. Look at network management from a control-theory perspective. As any electrical or mechanical engineer knows, the proper way to build a control system that works well in a complex environment is to get a feedback loop into the design. The traditional control-theory picture is shown in Figure 2-6.

Translating that into your network management context, the picture becomes what is shown in Figure 2-7.

As you can see in this figure, a mechanism to push and pull configurations to and from the network is obviously required. “A mechanism to dump and restore configurations is a primitive operation needed by operators. Standards for pulling and pushing configurations from/to devices are desirable” (RFC 3535, Requirement #7).

The network-wide transaction is an important mechanism for the manager to control the network. Without it, the manager would become both very much more complex and less efficient (in other words, the network would be consistent with the intent a lesser portion of the time). In order to close the loop, each of the other steps is just as important, however. When the monitoring reads the state of the network, it leverages the NETCONF capability to separate configuration from other data. “It is necessary to make a clear distinction between configuration data, data that describes operational state, and statistics. Some devices make it very hard to determine which parameters were administratively configured and which were obtained via other mechanisms such as routing protocols” (RFC 3535, Requirement #2).

With NETCONF, this data is delivered using standardized operations (<get> and <get-config>) with semantics consistent across devices. “It is required to be able to fetch separately configuration data, operational state data, and statistics from devices, and to be able to compare these between devices” (RFC 3535, Requirement #3). The data structure is consistent, too, through the use of standardized YANG models on the devices.

The diff engine then compares the intent performance to the original intent to see how well the current strategy to implement the intent works (remember the intent-based networking trend in Chapter 1), and it compares the actual network configuration with the desired one. If a change in strategy is required or desired (for example, because a peer went down, or the price of computing is lower in a different data center now), the manager computes a new desired configuration and sends it to the network. “Given configuration A and configuration B, it should be possible to generate the operations necessary to get from A to B with minimal state changes and effects on network and systems. It is important to minimize the impact caused by configuration changes” (RFC 3535, Requirement #6).

Clearly, for this to work, the definition of a transaction needs to be pretty strong. The diff engine computes an arbitrary bag of changes in no particular order. The complexity of the manager increases steeply if it has to sequence all of the diffs in some particular way. And unless that particular way is described in machine-readable form for every device in the network, that NMS remains a dream.

Therefore, it follows that the transaction definition used with NETCONF must describe a set of changes, that taken together and when applied to the current configuration must be consistent and make sense. It’s about consistent configurations, not about atomic sequences of changes. “It must be easy to do consistency checks of configurations over time and between the ends of a link in order to determine the changes between two configurations and whether those configurations are consistent” (RFC 3535, Requirement #8).

This is not the same as a sequence of operations that are carried out in the order they are given, and where each intermediate step must be a valid configuration in itself. The server (device) side is clearly easier to implement if the proper sequencing comes from the manager, like the tradition in the SNMP world, which is why many implementers are tempted to go with this interpretation. Let’s state clearly then that NETCONF transactional consistency is at the end of the transaction. Otherwise, the feedback controller use case dies, and you would be back to simple scripts shooting configurations at a network in the dark.

The same feedback capability is essential in those networks where human operators are allowed or required to meddle with the network at the same time as the manager. This is a common operational reality today and invariably leads to unforeseen situations. Unless there is a mechanism with a feedback loop that can compute new configurations and adjust to the ever-changing landscape, the more sophisticated use cases will never emerge.

Interview with the Experts

Summary

This chapter is by no means a complete account of everything you can do in YANG, but it aims at providing you a good grasp of all the most important concepts, what problems YANG solves, and how to go about making new YANG models.

In particular, you learned about the data model–driven management architecture and components. YANG is an API-contract language that creates a specification for the interface between a client and server (configure, monitor status, receive notifications, and invoke actions). The most common protocols used are NETCONF, RESTCONF, and gNMI, for which you understand the pros and cons in light of the tooling environment. Those protocols support different encodings: XML, JSON, protobuf, and so on. In the end, those data models generate APIs to be used directly in programming, thus hiding the low-level details of a YANG model or an encoding.

Even though “Overview of the 2002 IAB Network Management Workshop” (RFC 3535) is 15 years old, the requirements in this document are still applicable and relevant today. Therefore, this document is a good read for anyone wanting to understand the issues faced by operators.

References in This Chapter

To further extend your knowledge, you should look at the RFCs as a next step. They are actually quite readable and a good source of detailed information, and many have usage examples. In particular, have a look at the items referenced in Table 2-4.

Table 2-4 YANG-Related Documents for Further Reading

Endnotes

1. https://datatracker.ietf.org/wg/netconf/charter

2. https://tools.ietf.org/html/rfc6244#ref-W3CXSD

3. https://tools.ietf.org/html/rfc6244#ref-ISODSDL

4. https://datatracker.ietf.org/wg/netmod/charter/

5. https://datatracker.ietf.org/doc/rfc8402/

6. https://datatracker.ietf.org/doc/rfc7011/

7. https://www.sdncentral.com/what-is-openflow/

8. http://www.openstack.org/

9. http://www.opendaylight.org/

10. http://openvswitch.org/

11. http://openconfig.net/

12. http://uml.org/

13. https://www.ietf.org/

14. https://core.tcl.tk/expect/index

15. https://www.itu.int/en/ITU-T/Pages/default.aspx

16. https://www.mef.net/

17. https://www.broadband-forum.org/

18. http://www.openroadm.org/home.html

19. https://yangcatalog.org/

20. http://www.openconfig.net/software/

21. https://datatracker.ietf.org/doc/rfc8040/

22. https://tools.ietf.org/html/rfc8040#ref-REST-Dissertation

23. http://www.grpc.io/

24. https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/

25. https://developer.cisco.com/site/ydk/

26. https://github.com/CiscoDevNet/ydk-gen/blob/master/profiles/bundles

27. https://github.com/CiscoDevNet/ydk-py

28. https://github.com/CiscoDevNet/ydk-cpp

29. https://github.com/openconfig/ygot

30. https://github.com/openconfig/goyang

31. https://github.com/robshakir/pyangbind