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: RFC7684 - OSPFv2 Prefix/Link Attribute Advertisement RFC7777 - Advertising Node Administrative Tags in OSPF RFC7855 - Source Packet Routing in Networking (SPRING) Problem Statement and Requirements RFC8355 - Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks RFC8370 - Techniques to Improve the Scalability of RSVP-TE Deployments RFC8402 - Segment Routing Architecture RFC8660 - Segment Routing with the MPLS Data Plane RFC8662 - Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels RFC8665 - OSPF Extensions for Segment Routing 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.

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!

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.

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.