One of the fascinating things to me about the open networking movement is that it hasn’t happened sooner. The drivers have certainly been there for many years: vendor lock-in (at least in certain circumstances) as well as significant capex and opex commitments have led to a tedious predictability in network design. Networking innovation outside of bigger pipes and more of them was limited to corner cases — protocol bolt-ons to add a feature or assuage a particular difficulty a small number of folks might have had. Network architects and engineers could rest comfortable in the knowledge that the way they’d build a network a decade ago was likely to be the same way they would build it today.
However, my concerns are not only about networking technology and but also about the business of networking. You can make a connection between the two. Yes, networking technology innovation, until quite recently, has been a bit stale. But networking consumption has been equally stale. Most of us buy a monolithic stack from a single vendor to perform some function. Or, sure — we might mix and match components at different layers of the OSI model in the name of “best of breed.” We like vendor X for routing and switching, vendor Y for load balancing, and vendor Z for firewalls. But that mixing and matching of components was never all that well integrated. About all that could be counted on was IPv4 and Ethernet…and maybe OSPF or BGP. The connection is that if build networks the same way we’ve always built them, then we buy networks the same way we’ve always bought them, too.
Open networking is, at long last, a viable challenger to the old model of networking, taking on tradition in ways that address hardware and software consumption, technology innovation, and IT systems integration.
Changing the consumption model is network disaggregation, where a hardware switch is no longer sold tightly bound with a software operating system. Instead, network operators can choose a hardware switch, and then decide on an operating system that suits them. This is not unlike the x86 compute market, where a bare metal server can be paired with an operating system of choice, something we’ve taken for granted for decades now. Networking is a brand new market for this approach, though — not all the kinks have been sorted out. There are still issues like…
- Which network operating system will work with which whitebox hardware?
- What does the support model look like for a disaggregated network stack?
- How long should an organization hang on to network infrastructure in the disaggregated model?
These questions have a variety of answers, all interesting, but not all of which are right for every organization. What’s more, these answers continue to evolve as users and vendors work together to sort out a model that makes sense, not just for today, but for the broader market tomorrow.
On the front of innovation, open networking has certainly brought a number of big ideas to the community. OpenFlow has become a programming conduit for genuinely new networking features when coupled with novel applications. Open software defined networking controllers are also having a real impact, with significant portions of the industry rallying around the OpenDaylight and ONOS projects as ways to centrally manage the most complex network infrastructures in the world.
Moving to IT systems integration, open APIs abound in the open source community and the aforementioned controller projects. There is a freedom in this approach that allows developers to code applications publicly, such that they are able to be improved upon by community and extended or forked by whoever might need to. This behavior is no different than open source software has ever acted, but the notion is rather different for the world of networking. This new openness through APIs brings with it the opportunity to orchestrate network infrastructure through platforms such as OpenStack, bringing networking as a latecomer into the world of IT automation.
While disaggregation, open controllers, and open APIs are core features of open networking that are changing the way end users are consuming networks, we’re a long way from predictability in this approach. Open networking is still — not to put too fine a point on it — hard. There’s a lot of work required on the part of the end user to make an open network behave as they need it to. Incumbent vendors are struggling to adjust to this new environment thrust upon them by their significant customers. Users continue to work together to come up with open solutions that everyone can leverage.
Really, open networking is just getting started. Since we’re far from predictability, we’re far from broad market adoption. Of course, that assumes open networking will eventually supplant the entire industry with a new consumption model. And maybe it will…but most of us can still make a good case for the monolithic network stack, the way open networking stands today. The old way is perhaps still be better for many of our businesses, while we wait for open networking to settle into something stable.
On the front lines of open networking, you’ll find ONUG, the Open Networking User Group, held May 13-14, 2015 at Columbia University. I’m looking forward to finding out from vendors, open source projects, and end users exactly how open networking is being used in real life. I’m also keen to get both sides of the story — both the good and the bad. I’ll be there, keyboard in hand, live blogging as interesting ideas are presented. Keep a look out here and at ethancbanks.com for more detail.
- SD-WAN Fabrics Aren’t Interoperable. Should Organizations Care? - January 14, 2019
- The Complex Simplicity of SD-WAN - November 15, 2018
- Operationalizing Open Networking – It’s Going To Be Hard - May 20, 2015
- The Potential of Open Networking - April 8, 2015
- The Scaling Limitations of Etherchannel -Or- Why 1+1 Does Not Equal 2 - December 7, 2010
- Breaking The Network, One /24 At AÂ Time - November 3, 2010
- Coping Mechanisms For A Lying ARP Cache - October 14, 2010
- Traveling East-West Might Get A Little Easier: Highlights from the TRILLÂ RFC5556 - October 11, 2010
- Don’t Drop The Baby: Data Center Bridging Wants Storage To Trust Ethernet - October 8, 2010
- Assembly Required: A Basic Spanning-Tree Design for a Two-Tier Data Center - September 8, 2010