RESTCONF JSONRPC NETCONF May17 Public

Selecting your Management Protocol:
RESTCONF vs JSON-RPC vs NETCONF
Imran Baig, Syed ZiaUllah & Jan Lindblad
Solution Architects
NETCONF, RESTCONF & JSON-RPC
Standard Standard Tailored to our needs

Selecting Northbound Protocol to Use
NETCONF RESTCONF NSO JSON-RPC
Standard RFC 6241/… RFC 8040/… Only RPC layer standard
Available since 2006 2017 2015
Functionality NETCONF Less than NETCONF More than NETCONF
Sweet spot Manage many network Manage NSO or single Build WebUI or script
devices device towards NSO
Message encoding XML XML or JSON JSON
RESTCONF is modeled after NETCONF. The goal with RESTCONF is to make a simplified version of NETCONF, so
RESTCONF functionality is a subset of NETCONF. One of the fundamental reasons for this is that the REST
architecture, by definition, does not have a session concept. The lack of sessions rule out certain types of NETCONF
operations, like network-wide transactions. RESTCONF will therefore never have all the functionality of NETCONF.
The RESTCONF functionality may well be sufficient for many use cases. Using RESTCONF, however, you will always
run the risk that in a future use case, you might need some NETCONF feature that isn't available in RESTCONF.
RESTCONF
Pros: Cons:
• Stateless communication – doesn’t maintain state • No security in protocol if over HTTP, so run near NSO or through
• Use standard HTTP methods. i.e. GET, POST, PUT, secure tunnel
PATCH, DELETE, OPTIONS & HEAD. • RESTCONF specification still young, so implementations and
• The REST API is always independent of the type of interoperability are still in build-up phase.
platform or languages. • PATCH operation very limited when compared to edit-config in
• Resources with multiple representations. Can receive NETCONF, so a new media type has been invented to handle
request and send response in XML and JSON edits which address more than one location in the data tree. This
format. media type may not be well supported by many of the traditional
REST toolchains.
• Industry standard for years so easy for programmers
to implement. • RESTful system is tied to uniform interface of the supporting
protocol HTTP.
• Need to perform multiple http requests for batch processing under
different transactions. Certain operations not possible due to this,
or will be difficult to roll back, or will have undesired effects on the
network.
• Each resource will have an different URI.

• Cannot attach labels to transactions, hence transactions cannot be
easily tracked.
JSON RPC
Pros: Cons:
• JSON-RPC is quick and easy to consume. • JSON-RPC is a standard, but the operations on
top are not standardized, but proprietary to
• JSON-RPC has 1 end-point URL for all requests. Tail-f products.
• In JSON-RPC, any request is sent the same way • No security in protocol, so run near NSO or
(i.e. via HTTP POST) with the method and through secure tunnel
parameters in it.
• JSON RPC Clients are required to know
• The JSON-RPC session ties the client and the procedure names.
server via an HTTP cookie.
• Procedure parameters order, types and count
• Can handle batch requests so northbound system matters.
has more flexibility to implement workflows.
• Number of calls made via JSON RPC are more
• As state is maintained hence support is available than REST as it has to maintain session.
for operations like “Commit DryRun” and attaching
labels to each transaction.
• Response for each request in a batch can be easily
consumed, making it easier to find issues in batch.
NETCONF
Pros: Cons:
• The Network Configuration Protocol • NETCONF protocol consistently carries a higher
(NETCONF) is a network management amount of bytes in the protocol payload and thus has
protocol developed and standardized by IETF. higher bandwidth utilization requirements.
• Support for robust configuration change using • NETCONF is a session-based protocol, This adds
transactions involving a number of devices. additional overhead for the connection handshaking.
NETCONF is a session based protocol.
• No built-in support for attaching labels to transactions,
• Distinction between configuration and state hence transactions cannot be easily tracked for
data Rollback
• Configuration testing and validation support
• Selective data retrieval with filtering
• Extensible procedure call

• NETCONF is running over SSH and therefore
has security built into the transport.
RESTCONF vs NETCONF Operations
RESTCONF NETCONF
GET <get-config>, <get>
(single location in tree)
POST <edit-config> (operation="create")
PUT <edit-config> (operation="replace")
PATCH <edit-config> (operation="merge")
PATCH <edit-config> (operation="merge")
(multiple locations using
yang-patch media type)
DELETE <edit-config> (operation="delete")
OPTIONS Not needed
HEAD Not needed

RESTCONF JSONRPC NETCONF May17 Public

Uploaded by

RESTCONF JSONRPC NETCONF May17 Public

Uploaded by

Selecting your Management Protocol:

RESTCONF vs JSON-RPC vs NETCONF

Imran Baig, Syed ZiaUllah & Jan Lindblad

Standard Standard Tailored to our needs

• Each resource will have an different URI.

• Configuration testing and validation support

• Selective data retrieval with filtering

• Extensible procedure call

HEAD Not needed

You might also like