Starting with the SDN craze 4-5 years ago, there has been increasing interest from Gartner clients about “Open Networking”. Most folks certainly prefer the notion of “open”, although it is challenging because there’s no official definition of “open networking” and openness is a spectrum of capabilities, not a binary condition.
Further complicating matters, nearly all network vendors market their products as “fully open”. In practice, this means dramatically different things, making it difficult to discern which solutions are truly open. Further, most vendors lead with closed and proprietary solutions. Similarly, many vendors claim to be open, but when you boil it down, the degree of open-ness is based on support for Ethernet, IP, BGP and/or a published API (i.e., lowest common denominator).
For example, in the data center, cross-vendor MCLAG implementations aren’t supported, and Ethernet Fabrics are not interoperable at the controller layer. But vendors will tout their open-ness because of APIs and hooks to orchestration systems. Similarly in the SDWAN space, there is no controller-level integration between vendors, but they’re open/agnostic because they can use “any transport” (so can any router).
The reality is that, in one form or another, proprietary network solutions will continue to exist in most enterprise networks for the foreseeable future, however not all proprietary approaches are the same. Some solutions provide more flexibility than others, giving access to a broader range of options for the future. To that end, my colleague, Danilo Ciscato just went Open-Networking #beastmode and published two pieces of research on Open Networking. You can read the full research reports online (paywall links below) but a couple of my favorite snippets from the research.
- If a vendor highlights a proprietary feature as the only way to address a requirement, the network is probably not properly designed, or you’re doing something very atypical that’s a cause for concern.
- Be Wary of Standards++: Does the vendor promote standard protocols, or instead implementations with “enhanced” versions that inhibit interoperability?
- Recommendation: Disregard unqualified network vendor claims of open networking, because they’re inconsistent
- It helps to ask prospective vendors specific questions to evaluate their openness, including (just a few) Can the product be managed via another vendor’s automation platform? Can you install third-party agents or software on the equipment? Can the equipment be controlled by another vendor’s controller? Do they expose a Linux shell, so that they can be managed by existing Linux-based tooling?
Here’s the detail on the research notes:
Summary: Open-networking solutions improve flexibility and reduce vendor lock-in. Although most vendors claim to be “open,” there’s no official definition, openness is not a binary attribute, and infrastructure and operations leaders need to discern vendors’ level of openness across a wide range of products.
Summary: Open-source networking already plays a bigger role in data centers than realized, but direct enterprise use is limited. I&O leaders should ensure their teams have no misconceptions and opportunistically employ available open-source networking alternatives to help lower costs and increase agility.
note: image via openclipart.org
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.