Saying ‘open networking’ is a little like saying ‘SDN’. Without context, it can mean almost anything. Some argue it’s more around options on platforms while others believe it’s more to do with software. When I think about open networking, I think about these main points…
Generic Platforms – White box switches are all the rage these days and for good reason. A white box switch gives you the option to run a variety of different software platforms on generic hardware. This means you don’t need to buy a piece of proprietary hardware to run your proprietary software on. The net result here is that vendor lock in goes away. It also means that you don’t need to wait years and years to buy new hardware to get new software.
Linux – Linux is used EVERYWHERE. As it turns out, it’s already used quite extensively in networking platforms, but not how you might imagine. Most networking vendors use a highly customized version of Linux and the Linux kernel. The reason for this is simple – Linux wasn’t built for networking. Long story short, traditional network vendors had to modify the Linux kernel to get it to perform fancy network functions. So while we’re starting to see a much larger emphasis on networking in Linux, we aren’t to a point where native Linux has feature parity with all network functions. That being said, some vendors believe they can soon deliver feature parity and build their products with a native Linux operating system. This is a win for numerous reasons. First off, stability just went through the roof. You’re now working off of a base that’s not just used by your company and your platform, its used everywhere. Secondly, if the platform is based off of native Linux that means that all of my other native Linux software will just work. Again – this comes back to giving us more options which is hugely significant here.
Open source software – While I’m not (yet) a huge contributor to open source software, I see tons of value in the concept. Look at it this way, a vendor open sourcing code just went from tens or hundreds of programmers working on their platform code to millions. This opens the door for all sort of possibilities. Improved testing, quick resolution of defects, quicker implementation of new features, and greater flexibility to name just a few. However, open sourcing code does not guarantee any of this. It’s very important for successful projects to have a strong community around them. Without a community interested in the project’s success, you haven’t changed anything besides where you store your code.
So while I agree that open networking is a win, I also think we’re at the very beginning of a long journey. Vendors are just starting to see the value in this model and not all of them are going to jump all the way in. And while we as end users see extreme value in many aspects of what open networking promises, most vendors have spent years making their money off of proprietary closed systems.
On a closing note – I think it’s also fair to mention the topic of support. Our primary opponent in network design and operation used to be complexity. Building a network that was too complex likely meant you’d have issues down the road with supportability. While this should still be a guiding principle, I’m going to argue that complexity is now our secondary opponent. Our primary challenge in modern networking is change. As networking systems become more open, your skill set as a network engineer will need to change with it. As more of the platforms move towards native Linux your skill set should plan on following right along with. Matt Oswalt wrote a great post on this last year that you should check out if you haven’t. He also talks about other skills that we should all be focusing on or looking to learn in the near future.
I’m excited about what the next few years will bring to the network space. The trend certainly seems to be going in the right direction and I’m hoping to see more and more vendors take this approach.
What do you think? Is your definition of open networking different? The same?