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.
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.
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.
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.
imported Blitherings · Tech · Thoughts
A question that came up at an event I was at yesterday: How will the time between the first (commercial) deployment of a telephony service, and a regulated universal service obligation for telephony compare to that of the time between the first (commercial) Internet services being deployed and a USO for IP connectivity (e.g., Broadband)? Based on this, is the cycle time of the telephony regulatory bodies, and mechanisms through which changes are implemented within these bodies suitable for Internet services?
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.
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!
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.
imported Tech · ISP · BGP · IETF · Presentations · UKNOF
As I presented at UKNOF 18, I have now written an Internet-Draft to address the requirements of Network Operators for how BGP should handle errors in UPDATE messages. The draft can be found on the IETF site, and I'm currently seeking opinions as to whether this reflects the an operational consensus! If you're an Operator (DFZ, MSE or otherwise), it would be great to hear from you! I'll be presenting the draft at NANOG 51 in Miami on Tuesday - if you're there, feel free to ping me!
imported Tech · Work · ISP · Presentations
I spoke at LINX71 about the testing that we (C&W) have been doing in the lab with 100GigE - we got a pre-production card and hence had a look at the technology for real. Thanks to LINX, the presentation video can be seen by clicking on the image below. Once again, however, whatever LINX use as a presentation laptop didn't render my slides properly - even though I'd submitted PDF too!
Older » Post Index