Questions tagged [ietf-netconf]

The NETCONF protocol allows the device to expose a full, formal application programming interface (API). Applications can use this straightforward API to send and receive full and partial configuration data sets.

Two versions of the protocol have been published at the time of writing, NETCONF 1.0 and 1.1. The first version was published as RFC4741 and was later obsoleted by RFC6241. Both versions are still in circulation.

The protocol uses a remote procedure call (RPC) paradigm. A client encodes an RPC in XML and sends it to a server using a secure, connection-oriented session. The server responds with a reply encoded in XML. The contents of both the request and the response are fully described in XML DTDs or XML schemas, or both, allowing both parties to recognize the syntax constraints imposed on the exchange.

A typical exchange between a client and server would look like this:

<rpc message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:ex="http://example.net/content/1.0"
     ex:user-id="fred">
  <get/>
</rpc>

<rpc-reply message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:ex="http://example.net/content/1.0"
     ex:user-id="fred">
  <data>
    <!-- contents here... -->
  </data>
</rpc-reply>

The protocol is conceptually structured into several layers:

         Layer                 Example
    +-------------+      +-----------------+      +----------------+
(4) |   Content   |      |  Configuration  |      |  Notification  |
    |             |      |      data       |      |      data      |
    +-------------+      +-----------------+      +----------------+
           |                       |                      |
    +-------------+      +-----------------+              |
(3) | Operations  |      |  <edit-config>  |              |
    |             |      |                 |              |
    +-------------+      +-----------------+              |
           |                       |                      |
    +-------------+      +-----------------+      +----------------+
(2) |  Messages   |      |     <rpc>,      |      | <notification> |
    |             |      |   <rpc-reply>   |      |                |
    +-------------+      +-----------------+      +----------------+
           |                       |                      |
    +-------------+      +-----------------------------------------+
(1) |   Secure    |      |  SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
    |  Transport  |      |                                         |
    +-------------+      +-----------------------------------------+

1. The Secure Transport layer provides a secure and reliable transport of messages between a client and a server. SSH is the most commonly used protocol for this layer of NETCONF, followed by TLS. RFC6242 and RFC7589 describe how they are utilized as secure NETCONF transport.
2. The Messages layer provides a mechanism for encoding remote procedure calls (RPCs) and notifications.
3. The Operations layer defines a set of base protocol operations to retrieve and edit the configuration data.
4. The Content layer consists of configuration data and notification data.

While the RFC does not specify how Content and Operations layers are modeled, a (initially) NETCONF specific modeling language, called YANG, has been developed for this purpose (see ietf-netmod-yang tag for more information).

Basic NETCONF operations have been standardized and consist of:

• get
• get-config
• edit-config
• copy-config
• delete-config
• lock
• unlock
• close-session
• kill-session
• validate
• commit
• confirmed-commit
• cancel-commit
• create-subscription*
• get-schema*
• partial-lock*
• partial-unlock*

_{*specified in a separate RFCs}

Learn more about NETCONF here:

• NETCONF Wikipedia page
• the specification
• NETCONF wiki
• NETCONF Workgroup tracker

_{(also the sources of most of the content on this page)}