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.

Lecture at Ecole Polytechnique: Taking Network Management into the 21st Century

         imported      Presentations · OpenConfig · YANG

Mark Townsley and Jean-Louis Rougier again invited me to come and lecture at École Polytechnique this year. Their course there focuses on analysing the success of network protocols - using the (fantastic) framework laid out in RFC5218. Given that I’d spoken about SR for the last couple of years in my lecture there, and was giving a (slightly) updated version of the SR lecture at Telecom ParisTech for JLR’s ‘Future Internet’ course earlier in the week, I decided to shift the focus of my lecture at X this year to the management plane. Particularly, looking at some of the issues with SNMP, and how these have pushed adoption of alternative management approaches, and what this has fundamentally meant for the way that we build network management today. I then shifted to explaining what we are doing in OpenConfig, and how we might address some of those issues - again, using the framework in 5218.

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.

The right tool for the job: Choosing where to use RSVP-TE or SR.

         imported      Work · MPLS · RSVP · MPLS_TE · IETF · SR

I noted that at NANOG64 this week in San Francisco, there are talks (both from Juniper) about both SPRING/Segment Routing and RSVP-TE. These are both protocols/technology approaches (since one can’t really call SR a protocol) that I’ve been involved in the evolution of over the last few years. A question that I’ve been asked more times than I’d like is why we chose to look at a new approach (SR) rather than go with a technology that exists RSVP-TE.

Working with YANG Models - A brief intro to 'pyangbind'

         imported      Code · IETF · SDN · python

Both the Hawaii IETF meeting (IETF91) and the subsequent meeting we had a few weeks ago in Dallas were somewhat YANG-heavy. Following work to move towards YANG as a standard modelling language for network configuration, and the subsequent IESG statement effectively deprecating SNMP as the way that we present network configuration - the IETF, and especially the routing area, has dived head-first into YANG.

Indeed, I’ve been occupied somewhat with some really great collaborative work with a number of awesome engineers from Google, Microsoft, AT&T, Level3, Yahoo!, Facebook, Cox, Verizon and others on the OpenConfig initiative. We’re trying to take an operator and use-case driven approach to developing YANG modules for both configuration and defining the schema for telemetry. This work has turned up a few times in the press, and I should probably write something separate about it in the near future.

However, one observation that a number of people have made, is that there’s really limited tooling available to work with YANG modules. We have (the rather excellent) pyang, which provides a validation tool for YANG modules and the corresponding JNC plugin that creates Java classes – but after that, options start to run pretty dry for what one might use, other than commercial products such as tail-f NCS. In some cases, the way that these modules work is also a bit esoteric, requiring quite a lot of care around what the YANG types are in the consuming code.

To drive adoption of YANG and NETCONF for making the network more programmable – we need to make it easy to program the network. To this end, I started some work, with the aim of:

March 2013 - December 2014 on TfL

         imported      Code · London


Oyster usage data from TfL for my Oyster card, March 2013 - December 2014. Data visualisation is with D3.js - mouse-over a station to isolate journeys to and from that location. Larger version.

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!

SPRING Forward(ing)

         imported      Work · MPLS · RSVP · MPLS_TE · Presentations · UKNOF · SR

I recently gave a talk at UKNOF relating to Segment Routing/SPRING and the operational challenges that we are trying to resolve through it. You can see it on YouTube below - or the slides are on this site - SPRING Forward(ing) - UKNOF27


  

Almost Two Years On: Where is SDN?

         imported      Work · MPLS_TE · SDN

Almost two years ago I wrote a post on this site entitled Some Initial Thoughts on the SDN. Clearly, since then the SDN concept gained some more legs (and entered a new stage of the hype cycle) - so, where are we right now?

Firstly, I think its fair to say that the concept presented by Scott Shenker of having a single centralised computational element controlling COTS OpenFlow-speaking switches has fallen out of favour somewhat (based on the discussions with other network architects, engineers, and implementors that I have had). Somewhat as predicted, there are real challenges with this approach within high-scale, distributed networks: