Some reflections on the development of Software-Defined Networking, and how it has impacted the ongoing re-imagining of network devices that OpenConfig, and associated projects has driven. Almost 10 years ago, there was a shift in the IP networking industry. The move towards SDN, and its adoption by hyperscalers as a means to break apart traditional network architectures had set the scene for disruption. The question of “how are we using SDN?
tech Tech · OpenConfig · YANG · k8s
Marcus Hines and I spoke at NANOG86 on some of the work that we’ve been doing related to emulating network topologies in Kubernetes, and how this relates to improving network testability. The slides can be found here and there is a video on YouTube.
tech Tech · OpenConfig · YANG
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.
Older » Post Index