Open Source NOS Demos At the OCP Summit

From sdxcentral: Facebook, Google, and Big Switch Networks at this week’s Open Compute Project (OCP) Summit will demonstrate three approaches to network operating systems all built with Open Network Linux (ONL) and all running on OCP switch hardware. All built with ONL is interesting to me. This is making the case ONL is simply an underlying Linux distribution. Why this wasn’t clear to me before is because of the poor messaging around all of these projects.

Open Source NOS: Response

My blog post on dNOS caused some interesting discussions to happen. My thinking was most people, be they open source people or networking people, don’t care about open source network operating systems. I have my theories as to why, and this Twitter thread contains my thoughts: I'm beginning to think my assumption most people don't care about open source network operating systems is valid. — Kyle Mestery (@mestery) March 14, 2018 It could also be that some of them are initially marketed as open source but with a long lead time until the code is released for public consumption.

dNOS: Another Open Source Network Operating System

This, from an AT&T press release at the end of January: AT&T* is working to provide the industry with a more open, flexible and cost-effective alternative to traditional integrated networking equipment. We intend to open source a project that we call the Disaggregated Network Operating System, or dNOS, hosted by The Linux Foundation. So far so good. Another network operating system, which is also open source, but I’m following along.

Stratum: An Open Source, Silicon Independent, Switch Operating System

Fun times continue in the land of Open Source Networking, as the ONF launches Stratum into the wild today. From the splash page of the project: Backed by a broad spectrum of organizations from across the networking industry, Stratum is building an open, minimal, production-ready distribution for white box switches. Stratum exposes a set of next-generation SDN interfaces including P4Runtime and OpenConfig, enabling interchangeability of forwarding devices and programmability of forwarding behaviors.

Ryu and OpenStack: Like Peanut Butter and Jelly

Increasingly, I’ve been spending more and more time playing around with and utilizing OpenStack. If you’re looking for a highly configurable and quickly maturing cloud operating system, you can’t go wrong with OpenStack. One of the more interesting parts of OpenStack to a networking guy like me is Quantum. Quantum allows you to create rich topologies of virtual networks, encompassing as much or as little as you want by utilizing different plugins.

SDN Adoption in the Enterprise

This post by Brad Casemore is rather interesting. Specifically, I love this comment: When it comes to technologies and markets, our inherent optimism occasionally is thwarted by our intrinsic resistance to change. This is true everywhere, but especially true in technology. I’m not saying SDN won’t penetrate the enterprise market, and neither is Brad. It will take time, for sure. What will help SDN penetrate this market is the value built on top of it.

Open vSwitch Kernel Code Moves Upstream

Just a note that over the weekend, after a few weeks of reviews, the Open vSwitch Kernel Code has moved upstream. Dave Miller pulled the code this weekend. Getting this upstream will be really helpful for OpenStack Quantum, as the default plugin for that code uses OVS. This is also great for distributions who want to include OVS, but have been hesitant because of it’s lack of existence in the upstream kernel.

ForCES: SDN You’ve Never Heard Of

With all the hoopla surrounding SDN, in all of it’s forms, I thought it would be interesting to look at a possible predecesor to OpenFlow, at least in spirit: The ForCES protocol. From RFC 5810, we have the following description of ForCES: Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE).

Building Value with SDNs: RouteFlow

With all of the talk regarding Software Defined Networks (SDN), it’s easy to get lost trying to understand where the value will be. The general consensus here is that value will be built on top of SDN. SDN is, in essence, a building block. One interesting project providing value by using SDN as a building block is the RouteFlow project. The goal of the project, taken straight form the front page, is: