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:

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.

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:

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!

Reinforcing the Kitchen Sink - Another BGP Presentation

         imported      Work · ISP · BGP · IETF · Presentations · netnod

On Friday, I presented at the Netnod meeting in Stockholm, Sweden - again about BGP error handling - this time presenting a bit of an update as to why this continues to be a problem for the Internet (and private BGP deployments) - and why this work is still really relevant. In addition, I tried to give an overview of what the solution space looks like. I’m not sure whether there’s video, but as usual, the slides are linked below!

Some Initial Thoughts on the Software-Defined Network (SDN).

         imported      Tech · MPLS · MPLS_TE · IETF · SDN · Thoughts

At one of the Ericsson R&D days, Professor Scott Shenker - who's an academic at the University of California in Berkeley, presented on a concept that he calls the "software defined network'. Now, if you haven't seen the presentation - it's definitely worth watching (it's on YouTube, here), and provides quite an engaging look at the problem of network scaling from the perspective of academia, and especially in terms of a comparison to the more rigorous disciplines of computer science, like OS design.

Progress with Error Handling for BGP

         imported      Tech · BGP · IETF · Presentations

It's been quite a while since I updated this blog, very lax of me, sorry!

The lack of updates appears more indicative of how busy I appear to have been since presenting the error handling draft work at NANOG (which looks to be the last post!). Since January, I've presented at the IETF in Prague, and then again in Québec City - particularly on a number of aspects of the work that I've been documenting here for some time!

NANOG 51 Presentation

         imported      Tech · LINX · BGP · IETF · UKNOF · Presentations · NANOG

The video from the presentation I gave a NANOG, LINX and UKNOF has now been posted. You can find the video at the following URL - NANOG 51: BGP Error Handling or by clicking on the image below. The full slide deck is also on this site - here.