OpenConfig Public Projects

              · ·

OpenConfig Public Projects

There are a number of public projects that we’ve been working on over the last few years in OpenConfig, and published from Google. It seemed like it might be worth giving a brief “hitchhikers guide” that glues together some of the different projects that we’ve published on GitHub.

Of course, the initial output of OpenConfig, which has motivated much of this ecosystem is the data models — which are publicly available on GitHub.

gNMI - Streaming Telemetry in Production

Whilst working on streaming telemetry, we observed that there were many different implementation decisions going in to the way that telemetry was being sent from a device. Initial implementations had tried to use UDP-based streaming from a network device to a collector, but our initial experiments with this in a production environment showed that there were a number of problems with this approach. When we moved on to implementations that streamed data over gRPC, we initially gave an abstract specification — however, our observation was that this was driving complexity in the stack, and making it harder for us to deliver a consistent telemetry experience across different implementations. To that end, we decided to define a standard gRPC service for interacting with network devices - and called this gNMI, the gRPC Network Management Interface. Since then, we’ve published specifications, extensions, and implemented code to the industry:

On top of these code artifacts, we’ve also spoken publicly about a few of these projects, particularly:

gNMI is now widely implemented across the industry. A number of network devices now implement gNMI - for example, Cisco IOS XR and IOS XE, JUNOS, Arista EOS (both as OpenConfig native, and sysdb paths), Nokia SROS, SONiC, Mojo/Arista WiFi, Ciena optical and others. There’s support in closed source (e.g., Arista CloudVision, Kentik’s platform, YumaWorks and open source management solutions,

ygot - Making .yang files actually do something

As I wrote way back in 2015, YANG models themselves are not particularly useful without a toolchain. Prior to joining Google, I’d written and open sourced pyangbind — which provided generated Python code from a YANG model. This code was adopted by a good number of folks across the industry, and continues to be used (although I haven’t quite had the time that I’d like to dedicate to it of late). After joining Google, where our management stack is written mainly in Go, I picked up and refactored some of the work that had been started internally to extend this approach to generate Go code from YANG models, and provide a runtime around them. Subsequently, this was further extended to generate protobufs from YANG models programmatically — which allows other languages to get at least the data structure side of the problem solved. Additionally, this provides a means to have a binary-encoding of the a YANG modelled schema on the wire, giving significant reductions in data volumes.

The toolchain that we have published is broken down into a few subcomponents:

This toolchain has been in use in production in Google for a number of years — we’ve been using it both for configuration generation, as well as handling telemetry. It continues to be actively extended for additional use cases. It’s also in use across a number of open source projects — for example, SONiC and ONOS.

YANG Modelling Helpers

As we’ve developed YANG models, we’ve found that there are a tonne of different things that aren’t very mature in the industry. We’ve tried to put together tools to help with this:

Other OpenConfig Projects

Alongside these projects, there are a number that I haven’t mentioned — and don’t fit into the categories above:

Closing Thoughts

It’s funny looking back at the almost 5 years since the initial OpenConfig commits — although Anees’ first commit pre-dates this by a year (September 2014) and mine is a few weeks later in October 2014. In this time - we’ve published a lot of different artifacts, and even done a historical podcast. Yikes, how time flies.

I think this work represents a significant change to how we’re interacting between off-box and on-box components of a networking system — but there’s still more to go, it’ll be interesting to see how things continue to evolve.