Data Model-Driven Management

This chapter is from the book

Network Programmability with YANG: The Structure of Network Automation with YANG, NETCONF, RESTCONF, and gNMI

Learn More Buy

This chapter is from the book

This chapter is from the book 

Network Programmability with YANG: The Structure of Network Automation with YANG, NETCONF, RESTCONF, and gNMI

Learn More Buy

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

NETCONF

The NETCONF protocol addressed many of the issues raised during the “Overview of the 2002 IAB Network Management Workshop” (RFC 3535). Here are just a few of them:

• Transactions: NETCONF provides a transaction mechanism that guarantees the configuration is correctly and entirely applied.

• Dump and restore: NETCONF provides the ability to save and restore configuration data. This can also be performed for a specific YANG module.

• Configuration handling: NETCONF addresses the ability to distinguish between distributing configuration data and activating it.

NETCONF provides a transaction mechanism, which is a major advantage compared to a protocol such as SNMP. A transaction is characterized by the “ACID test” (which comes from the database world):

• Atomicity: All-or-nothing. Either the entire change is applied or it is discarded. This constitutes a major advantage for error handling.

• Consistency: All-at-once. The data needs to be valid with respect to YANG rules. There is no concept of time inside the transaction, no “before” and “after.” No “first this, then that.” This is great for simplicity.

• Independence: No cross-talk. Multiple clients can make configuration changes simultaneously without the transactions interfering with each other.

• Durability: Once executed, the transaction is guaranteed to stick, even if there is a power outage or a software crash. In other words, “when it’s done, it’s done.”

Here is how RFC 6241, “Network Configuration Protocol (NETCONF),” defines the NETCONF protocol:

XML’s hierarchical data representation allows complex networking data to be rendered in a natural way. Example 2-2 places network interfaces in the OSPF routing protocol areas. The <ospf> element contains a list of <area> elements, each of which contains a list of <interface> elements. The <name> element identifies the specific area or interface. Additional configuration for each area or interface appears directly inside the appropriate element.

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

NETCONF includes mechanisms for controlling configuration datastores. Each datastore is a specific collection of configuration data to be used as source or target of the configuration-related operations. The device indicates whether it has a distinct “startup” configuration datastore, whether the current or “running” datastore is directly writable, and whether there is a “candidate” configuration datastore where configuration changes can be made that will not affect the device operations until a “commit-configuration” operation is invoked.

The NETCONF protocol provides a small set of low-level operations, invoked as RPCs from the client (the application) to the server (running on the device), to manage device configurations and retrieve device state information. The base protocol provides operations to retrieve, configure, copy, and delete configuration datastores. The Table 2-2 lists these operations.

Table 2-2 NETCONF Operations

NETCONF’s “capability” mechanism allows the device to announce the set of capabilities that the device supports, including protocol operations, datastores, data models, and other capabilities, as shown in Table 2-3. These are announced during session establishment as part of the <hello> message. A client can inspect the hello message to determine what the device is capable of and how to interact with the device to perform the desired tasks. This alone is a real advantage compared to a protocol such as SNMP. In addition, NETCONF fetches state data, receives notifications, and invokes additional RPC methods defined as part of a capability.

Table 2-3 Optional NETCONF Capabilities

This collection of capabilities effectively offers a robust network-wide configuration, via the :rollback-on-error, :candidate, :confirmed-commit, and :validate capabilities. With this ACID concept in place, you can view the network as a distributed database. When a change is attempted that affects multiple devices, these capabilities hugely simplify the management of failure scenarios, resulting in the ability to have transactions that dependably succeed or fail atomically. This network-wide transaction mechanism is known as a three-phase transaction (PREPARE, COMMIT, and CONFIRM) in the database world.

NETCONF also defines a means of sending asynchronous notifications from the server to the client, described in RFC 5277.

In terms of security, NETCONF runs over transport protocols secured by Secure Shell (SSH), or optionally HTTP/TLS (Transport Layer Security), allowing secure communications and authentication using well-trusted technology.

RESTCONF

Just as NETCONF defines configuration datastores and a set of Create, Read, Update, Delete, Execute (CRUDX) operations to be used to access these datastores, RESTCONF specifies HTTP methods to provide the same operations. Exactly like NETCONF, RESTCONF is a programmatic interface for accessing data defined in YANG.

So why did the IETF specify yet another protocol, similar to NETCONF? In Chapter 1, you learned that automation is only as good as your toolchain. Furthermore, at this point in this book, you understand a key message: In the world of data model–driven management, what is important is the set of YANG data modules from which APIs are deduced. Therefore, because some operations engineers were developing HTTP-based tools, it was natural to specify a data model–driven management protocol using the same HTTP-based toolchain.

The following is from the RESTCONF specifications (RFC 8040) so that you will understand the relationship between NETCONF and RESTCONF.

Note that Chapter 4 provides a more technical comparison of NETCONF and RESTCONF. RESTCONF adds a new possible encoding, as compared to NETCONF, because it supports XML or JSON. With RESTCONF, the server reports each YANG module, any deviations, and features it supports using the ietf-yang-library YANG module, defined in the YANG Module Library (RFC 7895) and the brand new YANG library [RFC8525] that obsoletes the previous version.

The RESTCONF protocol has no concept of multiple calls making up a transaction. Each RESTCONF call is a transaction by itself, as it uses the HTTP POST, PUT, PATCH, and DELETE methods to edit data resources represented by YANG data models. RESTCONF lacks any way of validating without also activating a configuration. However, the validation is implicit, part of the RESTCONF calls, which succeed or fail transactionally.

With the capabilities of NETCONF in mind, the natural service automation flow is the NETCONF <lock> operation (on the running and candidate datastores), editing the configuration in the candidate configuration datastore, validating the configuration, committing to apply the configuration in the candidate datastore to the running datastore, and finally the unlock operations. These operations are done on multiple devices in parallel from an orchestrator, to achieve network-wide transactions. RESTCONF doesn’t provide the notion of locking, candidate configuration, or commit operations; the configuration changes are applied immediately. RESTCONF does not support transactions that happen in three phases (PREPARE, COMMIT, and CONFIRM). However, it supports transactions that happen in two phases (PREPARE and COMMIT), but only for data given in a single REST call.

Therefore, RESTCONF does not support network-wide transactions, but only device-by-device configuration. RESTCONF is therefore suitable between a portal and an orchestrator (because there is only one), but not from an orchestrator toward a network with many devices.

It is a little bit over-simplistic to think that, if you are a web developer, you “just” select RESTCONF as the protocol, as opposed to NETCONF. However, remember the importance of tooling. Automation in general, and specifically network configuration, implies the integration of an entire toolchain. And, if the existing toolchain (for example, storage and compute) is centered around HTTP, the RESTCONF option might be the best one. In the end, it is all about seamless integration and reduced costs.

It’s important to understand the disadvantages of using RESTCONF for device configuration so that you know the consequences of choosing RESTCONF simply because it uses HTML. As a piece of advice, when you have the choice (that is, you are not constrained by the toolchain), use NETCONF for network elements configuration. RESTCONF might be fine as the northbound interface of the orchestrator or/and controller.

gNMI (gRPC)

The gRPC Network Management Interface (gNMI) protocol comes from the OpenConfig consortium,²⁰ a group of network operators led by Google, with the following mission: “OpenConfig is an informal working group of network operators sharing the goal of moving our networks toward a more dynamic, programmable infrastructure by adopting software-defined networking principles such as declarative configuration and model-driven management and operations.”

The initial focus of OpenConfig was on compiling a consistent set of vendor-neutral data models written in YANG, based on actual operational needs from use cases and requirements from multiple network operators. While OpenConfig continues to evolve the set of YANG modules, Google developed gNMI as a unified management protocol for streaming telemetry and configuration management that leverages the open source gRPC²³ framework.

There is sometimes a confusion between gNMI and gRPC—hence the two names in this section. To clarify, gNMI is the management protocol and gRPC is the underlying RPC framework.

One of the gNMI encodings is protobuf, discussed earlier. Protobufs have the advantage of being more compact on the wire, but they also provide an operationally more complex deployment. With NETCONF and RESTCONF, only the YANG schema is required to understand the payload. With gNMI over gRPC with protobuf transport, distribution of .proto files is also required. This adds complexity, especially when some devices are upgraded and so on.

CoMI

The CoAP Management Interface (CoMI) protocol extends the set of YANG-based protocols (NETCONF/RESTCONF/gNMI) with the capability to manage constrained devices and networks.

The Constrained Application Protocol (CoAP; RFC 7252) is designed for machine-to-machine (M2M) applications such as smart energy, smart city, and building control, for use with constrained nodes and constrained (for example, low-power, lossy) networks. The IoT nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over low-power wireless personal area networks (6LoWPANs) often have high packet error rates and a typical throughput of tens of kilobits per second.

Those constrained devices must be managed in an automatic fashion to handle the large quantities of devices that are expected in future installations. Messages between devices need to be as small and infrequent as possible. The implementation complexity and runtime resources also need to be as small as possible.

CoMI specifies a network management interface for those constrained devices and networks, where CoAP is used to access datastore and data node resources specified in YANG. CoMI uses the YANG-to-CBOR mapping²⁴ and converts YANG identifier strings to numeric identifiers for payload size reduction. In terms of protocol stack comparison, CoMI runs on top of CoAP, which in turn runs on top of User Datagram Protocol (UDP), while NETCONF/RESTCONF/gNMI all run on top of Transmission Control Protocol (TCP).

At the time of writing, CoMI is in its last stage of standardization at the IETF.