RESTCONF or NETCONF for Network Automation and Programmability??

I usually receive this query in my inbox, So let's explore RESTCONF vs NETCONF.

In this blog post, I will compare and contrast two popular protocols for network automation and programmability: RESTCONF and NETCONF. I will explain what they are, how they work, and what are their advantages and disadvantages.

What is NETCONF?

NETCONF stands for Network Configuration Protocol. It is a standard protocol defined by RFC 6241 that provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF runs over SSH (port 830) and uses XML as the data format to exchange data.

NETCONF has four main components:

• Transport
• Messages
• Operations
• Content

The Transport component is SSH, which provides secure and reliable communication between the client and the server. The Messages component defines how NETCONF communicates and exchanges data with the network device using RPC (Remote Procedure Call) calls. The Operations component defines the actions that can be performed on the network device, such as get, edit-config, copy-config, delete-config, lock, unlock, etc. The Content component defines the data structures that are used to represent the configuration and state of the network device.

NETCONF uses a concept called configuration datastores to organize the data on the network device. There are several datastores defined in the RFC, but the most common ones are:

- <startup>: Startup configuration for the device        

- <candidate>: Runs in parallel with the running configuration. Changes can be made to this datastore 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.)        

NETCONF also supports notifications, which are messages initiated from the server (network device) and sent out in response to an event occurring on the device. Notifications are similar to SNMP traps, but use a push instead of pull model.

Sample Python Script to get running-config from Network Device using NETCONF:

#replace the device parameters as required and import ncclient library

from ncclient import manager
import xml.dom.minidom

# Define the device IP,Port, username and password
conn = manager.connect(
        host='ios-xe-mgmt.cisco.com',
        port=10000,
        username="root",
        password="D_Vay!_109",
        hostkey_verify=False,
        device_params={'name': 'default'},
        look_for_keys=False)

hostname_filter = '''
<filter>
                          <native         xmlns="https://cisco.com/ns/yang/Cisco-IOS-XE-native">
                          </native>
                      </filter>
                      '''

       # Pretty print the XML reply
xmlDom = xml.dom.minidom.parseString( str( conn.get_config('running', hostname_filter)))
print(xmlDom.toprettyxml( indent = "  " ))        

What is RESTCONF?

RESTCONF stands for Representational State Transfer Configuration Protocol. It is a standard protocol defined by RFC 8040 that provides a subset of NETCONF functionality implemented on top of HTTP/HTTPS. RESTCONF exposes a REST-like interface to network devices, which means that it uses HTTP methods (GET, POST, PUT, PATCH, DELETE) to perform CRUD (Create, Read, Update, Delete) operations on the network device resources.

RESTCONF uses YANG as the data modelling language to describe the data structures exchanged in RESTCONF messages. YANG is similar to XML in that it uses tags to define elements, but it is more concise and expressive than XML. YANG also supports features such as data types, constraints, grouping, inheritance, etc.

RESTCONF supports both XML and JSON as the data formats to exchange data. JSON is more compact and human-readable than XML, which makes it easier to work with in web applications and scripting languages.

RESTCONF uses URIs (Uniform Resource Identifiers) to identify and access network device resources.

A URI consists of a base URI (e.g., https://example.com/restconf/) followed by an API path like :

/data/ietf-interfaces:interfaces/interface=eth0        

The API path can be either a YANG module name or a YANG instance identifier.

RESTCONF also supports operations that are not directly mapped to HTTP methods, such as lock/unlock or validate/commit.

These operations are invoked using RPC methods that are appended to the base URI. e.g.

https://example.com/restconf/operations/ietf-netconf:lock        

Sample Python Script to access the data from the network device using RESTCONF:

# Import requests library for sending HTTP requests
import requests

# Define the device IP, username and password
device_ip = "ios-xe-mgmt.cisco.com"
username = "root"
password = "D_Vay!_109"

# Define the restconf URL for getting the running config
restconf_url = f"https://{device_ip}/restconf/data/Cisco-IOS-XE-native:native"

# Define the headers for restconf request
headers = {
    "Accept": "application/yang-data+json",
    "Content-Type": "application/yang-data+json"
}

# Send a GET request to the restconf URL with authentication and headers
response = requests.get(restconf_url, auth=(username, password), headers=headers, verify=False)

# Check if the response status code is 200 (OK)
if response.status_code == 200:
    # Print the response content as JSON
    print(response.json())
else:
    # Print the response status code and reason
    print(f"Request failed with status code {response.status_code} and reason {response.reason}")
        

Comparison

Both NETCONF and RESTCONF are protocols that enable network automation and programmability by providing standardized methods to configure and manage network devices. However, they have some differences that make them more suitable for different use cases and scenarios.

Some of the main differences are:

- Transport: NETCONF uses SSH as the transport protocol, while RESTCONF uses HTTP/HTTPS. SSH provides more security and reliability features than HTTP/HTTPS, such as encryption, authentication, compression, etc. However, HTTP/HTTPS is more widely supported and easier to integrate with web applications and tools.

- Data format: NETCONF uses XML as the data format, while RESTCONF supports both XML and JSON. XML is more verbose and structured than JSON, which makes it easier to validate and parse. However, JSON is more compact and human-readable than XML, which makes it easier to work with in web applications and scripting languages.

- Data model: NETCONF uses YANG as the data modelling language, while RESTCONF also uses YANG as the data modelling language. YANG is a powerful and expressive language that can describe complex data structures and constraints. However, YANG is not very well-known or widely adopted outside of the networking domain.

- Interface: NETCONF uses RPC calls to perform operations on the network device, while RESTCONF uses REST-like URIs to access network device resources. RPC calls are more flexible and expressive than REST-like URIs, which can perform only CRUD operations. However, REST-like URIs are more intuitive and consistent than RPC calls, which can vary depending on the vendor or device.

Conclusion

In this blog post, I have compared and contrasted two popular protocols for network automation and programmability: RESTCONF and NETCONF. I have explained what they are, how they work, and what are their advantages and disadvantages.

There is no definitive answer to which protocol is better or worse, as they both have their strengths and weaknesses. The choice of protocol depends on the use case, the scenario, the requirements, and the preferences of the user.

I hope this blog post has been informative and helpful for you. If you have any questions or feedback, please feel free to leave a comment below or message.

Note: Blog content is taken from the Internet and sample code can be found in my GitHub.

Refer:

GitHub