Two protocols that you hear about when you jump into the network automation world…

In this post, I’ll go over each protocol, why they are used, and a personal take on their future.

NETCONF

When I was first looking at network programmability, NETCONF was one of the first protocols I stumbled upon. NETCONF runs over SSH (port 830) and only uses XML data formatting. If you’ve never ran into XML, it’s one of the easiest data formats to comprehend. Here’s a basic example of XML representing a person:

<Person personID=1>
<name>John Doe</name>
<address>111 Hollywood Blvd</address>
<city>Los Angeles</city>
<state>CA</state>
<zip>55555</zip>
</Person>

The verbosity of XML has it’s perks and downsides: The perk is that it’s extremely easy to follow and understand. The downside is that it can produce an extremely lengthy and messy configuration file when sending data to a network device vs. another data format like JSON.

I want to go over some the different components of NETCONF. Following the RFC [6241], there are four main components: Transport, Messages, Operations, and Content. I’ve already gone over the Transport component being SSH. The Messages and Operations are how NETCONF communicates and exchanges data with the network device. RPC calls are used for both use cases. More specifically, you may see these types of tags in your calls: <rpc>, <rpc-reply>, and <notification>. As you can guess, the <rpc> tag is used to initiate the NETCONF session, while the <rpc-reply> encapsulates the device’s response. The <notification> element is initiated from the server (network device) and sent out in response to an event occurring on the device. I like to think of notifications as SNMP traps, but in a push instead of pull model. There are plenty more element tags you’ll see when sifting through NETCONF-XML responses, but I wanted to highlight a few here.

NETCONF Operations

The Operations and Content components of NETCONF are expansive and can be individual posts themselves, but I wanted to highlight them here so that you can get a more complete understanding of the protocol. Before explaining the Operations, you’ll need to understand how the data is organized on the network device so that you know how to extract the data you’re looking for. NETCONF has a concept called configuration datastores. There are many datastores defined in the RFC, some that may not be supported by every device platform, but here are the few I wanted to highlight:

• <startup>: Startup configuration for the device
• <candidate>: Runs in parallel with the running configuration. Changes can be made to this data store without affecting the running configuration of the device. However, those changes can be committed to be the running datastore at a later time.
• <running>: Running configuration of the device
• <operational>: A read-only datastore that holds all the operational (state) information (interface statistics, routing adjacencies, etc.)

These datastores are important when it comes to the type of operations that can be performed on each one. Now that you have an idea of the different datastores that you can interact with, here are the different operations that can be performed (according to RFC 6241):

• get
• get-config
• edit-config
• copy-config
• delete-config
• lock
• unlock
• close-session
• kill-session

As you can see, there are many different operations, and this list may grow as more RFC revisions come out. For brevity, I wanted to highlight three of the operations mentioned: get, get-config, and edit-config. The get operation can be used to retrieve all device configuration and state information. Most of the time, you’ll see this used to retrieve only state information. Filters can be used to minimize the amount of data returned. The get-config operation is used to retrieve, like you can guess, all device configuration. This is the most common operation to use when gathering device configuration. Filters can also be used in this operation to minimize the amount of data returned. The edit-config operation is also literal – it’s used to edit the device configuration. One thing to note is that many of these operations have additional attributes and parameters that allow for more targeted execution. For example, the edit-config operation allows you to target a specific datastore (i.e. candidate before applying to the running config) and also include error-handing such as stopping or rolling back if an <rpc-error> message is generated by the server. These three operations will be the most common operations you’ll see when using NETCONF for the first time, but I encourage you to explore the RFC for more options!

As you can see, the Operations of NETCONF is huge and I can go on about the different datastores and operations available. However, I wanted to quickly highlight the Content portion of NETCONF.

When computers need to interact with one another, a common language needs to be established. This common language is established through data models. The current industry-standard data modeling language supported by IOS-XE devices is YANG. Like I mentioned previously, I could (and might) write an entire post on YANG alone. There are many components to YANG and I personally find the entry barrier pretty high. However, I may feel encouraged to create a separate post on YANG. For now, just know that YANG is the data modeling language used in the exchanging of data.

Now that you’ve had a brief overview of NETCONF and its operations, let’s move on to RESTCONF!

RESTCONF

After struggling through NETCONF, I was relieved to learn about RESTCONF…

RESTCONF runs over HTTPS (port 443) and provides the familiar HTTP methods when exchanging data: GET, POST, PATCH, PUT, DELETE. I say these are familiar because, being in the network automation journey, many of us are learning this new world of RESTful APIs, which use the same operations. Besides having some familiarity with the methods of exchanging data, RESTCONF also allows for another (possibly familiar) data format: JSON! Along with XML, JSON is another data formatting option available with RESTCONF.

RESTCONF Operations

Interacting with a network device via RESTCONF is essentially interacting with a REST API endpoint using HTTP methods, with the network device acting as the endpoint. RESTCONF follows REST principles including a client-server architecture, uniform interface, and being stateless. Being stateless brings up one of the big differences between NETCONF and RESTCONF: NETCONF is session-oriented and stateful, while RESTCONF is stateless. What this means is that RESTCONF interactions are one-and-done. The server will not keep an active session open with the client. This is a major security benefit since it can protect from session hijacking and other attacks that take advantage of open, consistent sessions.

So we have the transport down (HTTPS/port 443) and the different HTTP methods that can be performed against a network device (GET, POST, PATCH, PUT, DELETE). For more information on the HTTP methods, please find the link in the References section. Along with the HTTP methods, it would also be good to familiarize yourself with HTTP status codes. As part of every response, an HTTP status code will be provided to show the status of the call (find link in References section). These status codes can be crucial when learning an API or troubleshooting errors.

The last piece I want to discuss about RESTCONF is the content or payload. As with NETCONF, YANG is the data modeling language you’ll run into with RESTCONF on IOS-XE devices. For more information on YANG, please check out RFC 7950 in the References section. This is the latest RFC I could find. It specifies some additional standards for mapping with NETCONF. As mentioned previously, I may write a separate post just on YANG.

SO WHY CARE?

The biggest question I always ask myself after learning a new topic is, “How does this fit into the bigger picture of networking and why?”. This is important to note and ask yourself because if you figure out why and how each technology fits into the bigger picture, it will be easier to retain and much easier to explain to other people in the industry. If you constantly view each of these protocols/technologies in individual bubbles, you’ll never understand how they all connect or what they are used for. For example, one may ask, why wouldn’t we just keep using SNMP for monitoring and use an open-source Python library like Netmiko or pyATS/Genie to communicate and return structured output to us? Both are great questions and, depending on the use case, you may want to use those options over NETCONF or RESTCONF. That’s why it’s important to understand the how and why before assuming a newly-learned technology or protocol is the best… only because it’s new…

PERSONAL TAKE

As part of all my posts, I’ll finish each post with a personal take or opinion about the topic discussed. I prefer to do it this way, so that it hopefully sparks a thought or discussion point from you.

With network automation growing so rapidly and vendors, such as Cisco, releasing software that have built-in features that promote network programmability and automation (RESTCONF/NETCONF/On-box Python), I would not be surprised to see NETCONF disappear. I think it will disappear due to the high barrier of entry, lack of major adoption, and the complexity of XML versus JSON. Of course, it will not completely disappear, but I think RESTCONF will take over and become more prominent over time. By making every network device their own REST API endpoint, it will provide better manageability and be easier to scale and integrate into a larger SD-controller in the future. The uniformity of REST may provide more value and opportunity for both vendors and their customers by just keeping everything simple (as long as the REST API is consistent across the same family of devices (i.e. IOS-XE, NX-OS, etc.). For how obvious it sounds, many engineers would just like these vendor solutions to be simple to understand and operate. After understanding, we will then try to turn all the nerd knobs and customize it. I believe the many network automation frameworks that currently run over SSH will continue to be the de facto for the unforeseen future, since SSH is the lowest common denominator when it comes connecting to a plethora of devices (old/new, different vendors, etc.).

I hope you enjoyed my very first post and look forward to hearing from you!

References:

NETCONF
RFC 6241: https://tools.ietf.org/html/rfc6241
IETF-Revised datastores: https://tools.ietf.org/id/draft-ietf-netmod-revised-datastores-08.html#rfc.section.5.1.2
Cisco doc: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/169/b_169_programmability_cg/configuring_yang_datamodel.html

RESTCONF
RFC 8040: https://tools.ietf.org/html/rfc8040
Cisco doc: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/169/b_169_programmability_cg/restconf_programmable_interface.html
Cisco DevNet: https://developer.cisco.com/docs/ios-xe/#!enabling-restconf-on-ios-xe/restconf
HTTP Methods: https://restfulapi.net/http-methods/
HTTP Status Codes: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

YANG
RFC 7950: https://tools.ietf.org/html/rfc7950