NANOG 90: Pondering Abstractions

         tech      Tech · OpenConfig · YANG

I had the pleasure of giving the keynote presentation at NANOG90 - sharing some thoughts and lessons that we have learnt in the 10 years since we started the OpenConfig project.

This was a really enjoyable presentation to put together and give. It balanced being able to look back at what we’ve learnt, and also think about some important lessons that I wanted to share with the networking community.

Published IETF RFCs

         tech      Tech · IETF

Over the years I have published a number of RFCs in the IETF. They are listed below.

As primary author:

As contributor:

Reimagining Network Devices

         tech      OpenConfig · Tech · YANG

Some reflections on the development of Software-Defined Networking, and how it has impacted the ongoing re-imagining of network devices that OpenConfig, and associated projects has driven.

Almost 10 years ago, there was a shift in the IP networking industry. The move towards SDN, and its adoption by hyperscalers as a means to break apart traditional network architectures had set the scene for disruption. The question of “how are we using SDN?” was on the lips of vendor and telco executives — and lead to many initiatives in the industry - both those that can be thought of “SDN” and those that were more incremental.

NANOG 86: Emulating Network Topologies in k8s

         tech      Tech · OpenConfig · YANG · k8s

Marcus Hines and I spoke at NANOG86 on some of the work that we’ve been doing related to emulating network topologies in Kubernetes, and how this relates to improving network testability.

The slides can be found here and there is a video on YouTube.

OpenConfig Public Projects

         tech      Tech · OpenConfig · YANG

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.

IETF98: OpenConfig Observations

         tech      Tech · OpenConfig · YANG

Anees Shaikh and I put together some thoughts that we shared with rtgwg at IETF 98 in Chicago. The slides are linked below.

FutureNet: Model-Driven Automation

         tech      Tech · OpenConfig · YANG

Anees Shaikh and I presented at future:net talking about automation work that we’ve been doing in OpenConfig, and I shared some of the NMS implementation I’ve been working on recently. Slides are linked below.

OpenConfig and IETF YANG Models: Can they converge?

         imported      Tech · IETF · OpenConfig · YANG

At IETF96 in Berlin, the chairs of the NETMOD working group, and Operations Area Director (Benoit Claise) published a statement to say “Models need not, and SHOULD NOT, be structured to include nodes/leaves to indicate applied configuration”. Now, this might seem a pretty innocuous statement, but it actually has a number of implications for the data models for network configuration and state that are being produced in the industry.

What is applied configuration?

The first question to an uninitiated reader might be, what is “applied configuration”? It’s not a term that has been in the common network nomenclature - and hence does need some further explanation. To define it, we need to look at the way that configuration is changed on a network element.

OpenConfig Interfaces - Some Examples

         imported      Code · Tech · Work · ISP · IETF · python · OpenConfig · YANG

I’ve talked a little on this site before about what we’re trying to achieve with OpenConfig. However, one of the observations that it’s easy to make is that YANG models alone don’t really achieve anything in terms of making the network more programmable. To make the network more programmable, we need to have tooling that helps us create instances of those modules, manipulate them, and then serialise the into a format that can be used to transmit data that conforms to the model to a device.

RFC5218, RSVP-TE and Segment Routing.

         imported      Tech · MPLS · RSVP · MPLS_TE · IETF · Presentations · SR

After my presentation at UKNOF on SR, Mark Townsley asked me whether I'd be interested in presenting to his class at the Ecole Polytechnique in Paris, around the thinking (from an ops perspective) of delivering the 5218 concept of "net positive value" through the SR technology, and how the existing protocols that are available might measure up against the criteria that 5218 gives us to consider. We managed to co-ordinate logistics, and I presented to INF566 on Wednesday afternoon, which was a really cool experience. It's always nice to see how networking is taught, and hear from students in such a high-ranking uni. I've included the slides below for posterity - Mark filmed the presentation, so perhaps there'll be video at some point in the future!