BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
SDN is a new technology with an array of offerings and possible use cases, so shopping for an SDN product suite is a challenging task.
Buyers must start by assessing what each SDN vendor offers -- and this can vary radically. Some SDN vendors offer a traditional approach to SDN that separates data and control planes from the physical network and uses a centralized controller to direct forwarding paths. Others offer software overlays with hypervisors or virtual switches that control the virtual network. Still, others are not proposing SDN at all, but are touting virtual appliances that could play a role in network programmability.
While all of these technologies can help move your network into the software-defined realm, it is key that the vendor describes its SDN vision in detail and that users understand how these strategies fit into their existing architectures, as well as whether they meet their organization's business needs.
Here are 14 questions to ask an SDN vendor before investing in their technology.
- Which vendors do you partner with? Creating a holistic SDN product suite that covers Layers 1 through 7 is a mammoth task. Many SDN vendors offer only one or two key elements of an SDN stack for this reason. To understand how the product offering will fit into your environment, you need to understand the partnerships the vendor has developed around its product. This is key when evaluating controller products.
- What SDN applications run on your platform? Some vendors are offering turnkey SDN products that include robust applications to enable you to integrate the network with your business processes or to tackle a specific problem. Others are offering toolsets that allow you to build whatever specific logic you might require. The two approaches are aimed at different customers. If you're looking for a vendor-supplied and -supported SDN application that solves a specific problem, make sure you understand exactly what applications run today, as well as what is on the vendor's roadmap. If you're looking for an arbiter that brings your network into your orchestration or DevOps world, make sure the vendor explains how it will work with you to develop your applications. It's not unreasonable to ask for face time with the vendor's product engineering team if you're in this situation.
- What are some use cases your product has been deployed for? SDN is not a "tried and true" mature networking technology. The space is saturated with startups, fresh ideas and emerging paradigms. To understand how the product you're evaluating fits your needs, you should ask the vendor to supply white papers and customer references that demonstrate how its technology addresses specific challenges. Unless you're the test case helping to develop the vendor's product, you don't want to be patient zero.
- If my network hardware is not programmable, how can your product help my organization? While programming the network centrally is one of SDN's big ideas, not all network hardware is OpenFlow-compatible or offers an application programming interface (API). Your vendor should be able to explain how its product can interface with your hardware in that case. This shouldn't be a big deal for most vendors, as remote configuration methods like SNMP and the ubiquitous command line interface (CLI) have been around for a long time, but make sure you get specifics, as much SDN technology presumes the use of OpenFlow.
- How will your product integrate into my existing network? Your vendor should have a reference architecture illustrating how to bring up its SDN product alongside the network you already own. Hybrid switching and "SDN islands" that pass through an SDN gateway acting as a bridge to and from your legacy infrastructure are common approaches.
- What is your licensing model? While SDN is all about the technology, the reality of a purchase is that vendors use a variety of techniques to price the product. Depending on your use case, how the vendor licenses its technology could impact your budget severely. Get intimately familiar with exactly how the vendor licenses its technology and what that means for the design you have in mind. Does it license by capability? Per device? By traffic or transaction volume? This is especially key to grasp when comparing Capex vs. Opex. A licensing model that doesn't seem too arduous during the acquisition phase could become quite costly as the years roll by.
- Do you recommend in-band or out-of-band (OOB) management between controller and network hardware? When building a software-defined network, southbound communications between network devices and the controller -- as well as northbound communications between applications and the controller -- is a crucial network function. Different vendors have different recommendations regarding in-band vs. out-of-band, along with logic to justify their positions. In-band is touted for the ability to detect a path failure in the network mesh between the device and the controller, revealing network link failures that might otherwise go undetected. OOB is touted as a means of guaranteeing control-plan communication latency and potentially improving network security.
- Which OpenFlow operations can your switch perform in hardware (silicon)? OpenFlow is the darling of the SDN movement, providing a vendor-agnostic means of describing how a network switch should treat a given traffic flow. Many vendors have announced OpenFlow compatibility on one or more of their hardware switch product lines. While you'd think OpenFlow would become a great switch equalizer in this role, the reality is that vendors are struggling to map OpenFlow operations into their existing silicon. Many switch vendors have designed custom application-specific integrated circuits (ASICs) for their switches, designed to do several kinds of forwarding, prioritization and encapsulation operations rapidly. This speed allows for network scale. ASICs have long development cycles; however, most were designed well before OpenFlow gained the notoriety it currently enjoys.
Therefore, if OpenFlow at scale is a critical part of your evaluation process, you need the vendor to state very specifically which OpenFlow operations it can do in hardware and at how many flows per second. Also plan to go through a critical evaluation to prove that the product will meet your needs.
- Are you publishing your APIs? Network devices have APIs. Controllers have APIs. Are the APIs public and documented? If not, will the vendor share them with you? If you are planning on developing your own applications built on the vendor's platform, this is an important discussion to have.
- What programming languages do your APIs support? Vendors have to choose what languages they will support. Java and Python are popular, others less so. The key is to understand what languages are supported and then map that capability back to your talent pool. Ideally, the product you're considering will not pose an undue burden on your development team.
- What skills will my operators need to learn to run your product? Traditional network engineers and operators have honed their networking skills, configuring individual devices at the Common Language Infrastructure. SDN eschews the Common Language Infrastructure, offering a programmatic means of network configuration. Your vendor needs to explain how its specific product will impact your existing operational policies. It's likely that your staff will need to learn new skills or update their processes to find success with incoming SDN.
- How will you support this product? SDN puts vendors in an awkward position when it comes to supporting their customers' networks. While customers have been accustomed to leveraging vendor support to work through bugs and problems, SDN gives the customer enough rope to proverbially hang themselves in ways the vendor has no control over. Customers need to understand exactly how a vendor will support them when it comes to the bits of code they have created themselves.
- How does your product avoid vendor lock-in? While some IT shops are comfortable with a single vendor based on the philosophy of "one throat to choke," most shops prefer to keep their choice of vendor options open. In networking this is especially true, and this corner of the industry has gone to great effort to develop and adhere to interoperable standards. This interoperability has allowed customers to keep their options open when it comes to equipment vendors, knowing they wouldn't necessarily be tied down if a chosen product fell from favor.
SDN is so new that it does not have a group of interoperable standards right now, and while vendors are often taking similar approaches with their respective products, many anticipate an integrated stack of equipment. In other words, a controller from vendor X is going to work best with switches from vendor X. It's incumbent on the buyer to understand the dependencies in what's being sold to keep vendor lock-in at bay.
- What is your roadmap for support of the Linux Foundation's OpenDaylight project? As OpenDaylight (ODL) develops, it could form a baseline of interoperability referenced by all SDN products in the industry. While ODL is in its infancy as of this writing, it is conceivable that vendors will look at ODL as the right foundation for their own SDN offerings. If this turns out to be the case, the ideal position to be in as a customer will be to own SDN products that are ODL-compliant. This would pave the way for third-party, innovative products that give a network options to enhance its SDN capabilities without relying exclusively on the primary controller or switch vendor as time goes on. That said, it's early to insist on such a feature, as "OpenDaylight-compliant" doesn't mean anything just yet. But it's something to keep an eye on.