I’m currently attending the semi-annual ONUG conference in New York City this week and, as one would expect, open networking is at the heart of just about every conversation. One of the more engaging sessions of the event is something named “The Great Debate” where two people, usually incredibly intelligent and even more ridiculously credentialed, take opposite sides of a topic to explore the nuances of each argument. The title of this years’ debate was “Two Roads To Open Networking”, where the presenters argued the merit of open source networking software as compared the utilizing abstraction and automation to lead to more open networks.
I’ve inherently seen open source software as the eventual end goal of any open networking initiative. There are strong parallels with how server infrastructure has progressed to open source software running a majority of the services and applications being deployed. There’s also something appealing and altruistic about the notion of our software coming from experienced practitioners, rather than cold vendors doing only what was necessary to lighten our companies wallets a little bit more. But when you start looking at it a bit more critically, depending on open source software to lead the way to open networks may not work out as well as we would like.
How Can Open Source Go Wrong
At the heart of it, open source software development takes time to get right. Our best example of a successful full-scale open source infrastructure project is Linux, and it took 20 years of development to be trusted enough to become the preferred server OS. Remember 10 years ago when running Linux meant tinkering until you could find the right combination of driver and hardware to do what you needed, and even then it usually meant forgoing the newest and best technologies? Dr. David Cheriton made a great point in the debate that lock-out (due to unsupported features) is far worse than being locked-in to a product that meets your requirements.
Another point that Cheriton made is that open source projects tend to require a hero or champion to head them up and organize the effort (think Linus Torvalds and Linux). I certainly couldn’t think of a successful open source project that didn’t have some motivated individual or group at the top, guiding the way. Unselfish people, looking to donate their time and highly technical backgrounds, are few and far between. This might be the reason why we see so many open source initiatives now being led by large corporations and service providers. The problem is that when the vendors run the open source projects, what motivational drivers are determining their priorities and effort?
Support is another issue when we look at open source software. It’s an inevitable problem that needs to be addressed, but one that organizations are not going to be tackling in the near term. There is a certain level of comfort when your networking software vendor(s) are contractually compelled to ensure your network remains operational. Running OSS at the network layer muddies the water a bit. Until we see “corporatized” support offerings around OSS distributions of network operating systems and protocol stacks, there is a pretty compelling argument for holding off on OSS deployments in the network.
If Not Open Source, Then What?
Rather than waiting for the perfect storm required for OSS to take over networking, as practitioners we should be vocal with our vendors and insist that they are more responsive to our needs.
- We need vendors to provide hardware and software that is easily interoperable with competing products
- We need the platforms to be customizable and extensible outside of just what the vendor wants to expose.
- We need hardware and software to be disaggregated
With the introduction of viable merchant silicon and whitebox switching, there are vendors who are already seriously listening and moving in this direction. Now, more than ever, customers have a voice in what the next generation of network products are going to look like, and alternatives if a vendor chooses not to respond to the things that we need.
Final Thoughts
The last things you should take away from this blog post is that, somehow, open source is having a negative impact on open networking. The opposite is true and open source projects that move networking forward should be embraced. That being said, waiting on open source software to be the savior of the networking world is most likely going to end in disappointment. Networking is hard. Software is hard. Both take a long time to get right even when the motivators line up perfectly. We should embrace the vendors and products we already have while pushing them to provide better flexibility and extensibility in their offerings. Open source software development efforts will continue in the mean time, and just like server infrastructure, it is inevitable that we will transition from closed to open platforms. No one path to open networking is full proof so we should be approaching the problem from all possible angles.
About The Author
Jordan Martin is a Principal Consultant of datacenter technologies based out of eastern Pennsylvania. His blog can be found at http://www.JordanMartin.net/ and followed on Twitter as @BCJordo.
This post is part of the ONUG Fall 2016 Tech Talk Series. For more information, please see the rest of the series HERE. To register for the Fall 2016 ONUG meeting, please visit http://OpenNetworkingUserGroup.com. Use code “TFD30” to receive 30% off your registration!
