OpenConfig Interfaces - Some Examples

              · · · · · · ·

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.


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

              · · ·

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

              ·


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.


Error Handling in BGP (Again!)

              · ·

It looks like, once again, there's another attribute flying around the global BGP table causing Quagga instances to crash (if based on 0.99.9 - I believe the bug is fixed in 0.99.10). This relates to the 2007 draft that introduced AS_PATHLIMIT - see ietf.org - draft-ietf-idr-as-pathlimit. This attribute is actually relatively interesting, from an operator's point of view, where control that is more granular than setting the common no-export or no-advertise communities does not suffice.


Visualising MPLS-TE Networks

              · · ·

For all network deployments, there is a requirement to present information relating to both topology, and various utilisation statistics to some human operator. In many cases, this process has become so ingrained in network requirements that there are almost ubiquitous solutions to the visualising data - for example, link utilisation is almost always presented via some framework or tool powered by RRDTool. Other tools, such as network "weathermap" diagrams linking this utilisation information into an overview of a network topology are also seen in many NOCs. In most cases, the problem of visualising data relating to a flat MPLS or IP network is solved for most common deployments.


LINX 65 Presentation

              · · · · · · · ·

Further to my previous post - I presented this issue at LINX65 - video and slides can be found below.

Video
Fixed Slides - LINX’s PowerPoint install seems to have corrupted my slides on the day.




Comments and feedback are most welcome.


Django

              · · ·

Since I’ve got a few moments, and I’ve decided to actually write down some rants rather than deciding that I can’t be bothered to - I’m going to use some space to single the praises of Django.

I’ve been using Django for a couple of years now - since around the autumn of 2005, and as such, feel that I’ve got a pretty good grasp of how the framework works. I haven’t really hacked around that much with the innards of Django (although I did propose a patch), however, what I really like about this framework isn’t particularly the internals, but just the whole philosophy that there seems to be in terms of building a web application.


Linking against GSL With Xcode

              ·

Further to the previous comment, you can also link against GSL from within an Xcode project: