Series · Designing a Netconf Manager · Part 1 of 4

The shape of the problem

What a Netconf manager has to do, written as one small equation, and why it splits into a library and a service.

2014 · 3 min read

This series is about thought process more than code. The design here is not a comparison with any existing product, and it is not built for one OSS server's requirements. It is a service meant to act as an efficient middleware between any client and NETCONF-based network elements. So it will ignore some requirements real systems have, and add a few of its own.

A basic understanding of NETCONF and networking helps. If you don't have one, read on anyway, as if it were a trip into the unknown.

What it is

A Netconf manager is a service that lets clients talk to NETCONF-based network elements, or nodes. Being a service, it runs as its own process and takes responsibility for its own resources, besides doing what the protocol asks.

Like everything since our first day of computer education, it takes some input, processes it and gives back some output. Three kinds of input are possible:

  1. NETCONF operation requests (get, get-config, edit-config and so on), counted as r;
  2. subscription requests, counted as s;
  3. basic service information requests, such as capabilities, counted as i.

And five kinds of response:

  1. responses to operation requests;
  2. responses to subscription requests;
  3. notifications from subscribed nodes, counted as n;
  4. responses to information requests;
  5. errors and failures, counted as e.

The definition, as an equation

That gives a definition compact enough to design against:

For every r + s + i requests, the manager responds with at most r + s + i + n + e responses and at least r + s + i, where n > 0 only if s > 0.

Every request gets an answer. Notifications exist only if someone subscribed. Errors are the only other thing allowed out.

ClientsOSS, tools, scriptsNetconf ManagerManager serviceNetconf libraryNetwork nodesNETCONF serversr + s + i≤ r + s + i + n + er + h + c + sr + h + c + s + n
The manager sits between clients and nodes. r: operation requests, s: subscriptions, i: information requests, n: notifications, e: errors, h and c: the hello and close messages the manager adds itself.

Towards the nodes the counts change. The manager sends r + h + c + s messages and receives r + h + c + s + n, where h counts the hello messages exchanged when a connection opens and c the close requests and their replies. Those extra messages are the manager's own business: opening and closing NETCONF connections is something it does for its clients, not something they ask for.

Two components

To keep the solution general and flexible, the service does not implement the protocol itself. It uses a library. So the design has two major parts:

  1. a Netconf library, which handles the functional side of the protocol;
  2. a Netconf manager service, which uses that library efficiently on behalf of many clients.

Subscriptions and notifications wait until the end of the series. They are defined in a separate RFC (5277) from the base protocol (6241), which is a good hint that they are an extension, so the design treats them as one.

Next: the Netconf library.

Drafted in 2014
Updated for site in 2026