How to Add gNMI to ConfD

gNMI Support for ConfD

A new example project called confdgnmi has been started at ConfD-Developer on GitHub. The project implements an example gNMI Adapter using existing ConfD APIs. ConfD is a data model driven management plane framework which provides a variety of northbound interfaces (NBIs): NETCONFRESTCONF, JSON-RPC WebAPI, CLI, and SNMP. ConfD also provides application development APIs in a variety of language bindings. One of these APIs is the Management Agent API (MAAPI) which enables the development of additional NBIs.

Recently, the gNMI (gRPC based) management protocol, which makes use of YANG data models, has become popular; primarily around OpenConfig. gNMI has mainly seen adoption for streaming telemetry. While gNMI does support configuration management, the limited configuration support of gNMI compared to NETCONF has made it less popular for configuration management. While ConfD does not directly provide a gNMI NBI, as mentioned above, it does provide APIs that can be used to implement (full or partial) gNMI functionality.

This example gNMI Adapter project does not aim to provide full, production grade gNMI functionality. Rather, it should be seen as a starting point. The code can be directly used (or used with minor modification) with all gNMI messages. A full description as well as limitations are described in the project’s documentation. The documentation describes several usage scenarios and examples, including simple telemetry. The project includes automated tests to ensure that existing functionality is not broken during development.

Summary and Lessons Learned

The gNMI protocol is based on gRPC. This allows to the use of this management API in many environments and programming languages. gNMI functionality can be added to ConfD with the use of an external application.

If we take a look at the gNMI specification, we can see it has evolved around OpenConfig. Some gNMI messages may seem complicated or duplicated. For example, some variants of SubScribe behave as Get. Also, there are many parameters for the implementation of STREAM subscriptions. Transport of data elements as gRPC messages (protobuf data) or bytes seems nice and performant, but breaks in general approach as both the server and client have to fully understand the YANG data model to encode and decode messages. Text based messages (JSON) do not differ too much from existing NETCONF or RESTCONF standards.

A Python implementation for this example project works well and for basic usage it does not encounter performance issues. In the case where there is no extensive data processing and transfer (e.g. only basic telemetry), it is sufficient for most scenarios. A port of this project to other languages should be straightforward.

A drawback of gNMI is that it is not standardized as an IETF RFC. There is a NETCONF standard for model driven telemetry called YANG Push. There are pros and cons for both variants. The ConfD network programmability approach focuses around NETCONF. This example project demonstrates that gNMI support is possible as well.

The gNMI Adapter is written in a modular (plugin) way and it could be adapted to add support to other (not ConfD) management agents or interfaces, for example, to create a pure gNMI over NETCONF adapter.

Check out the code from ConfD-Developer on GitHub today!