White box is not a new phenomenon. The name by itself just means hardware with no brand names, so you lower your cost by not paying the luxury “branding tax”. The first wave of white box was on PCs and servers, and we already know that white box servers running Linux have won that battle in leading web services and cloud service providers such as Google, Facebook and Amazon, and also some communication service providers and enterprise sectors. Following the first wave of white box server movement, white box switches are taking the center stage, making salient headlines such as “Facebook’s shot at Cisco just got deadly” and relentless fightback from Cisco.
I was lucky enough to be in Light Reading’s “White Box Strategies for CSP” event in Santa Clara this week where some of the brightest minds in the industry gathered to discuss the new disaggregated way of switching. I experienced the enthusiasm people have towards white box but also feel that there are a lot of misunderstandings at the early stage of this technology trend. Can you tell the truth from myth in the following statements? Give it a try.
1. White Box = Weak Box
Myth. The key motivation behind white box is customization, or choice, or flexibility. If you recall the very beginning of the white box movement, advanced users often prefer white box computers constructed with higher quality components that they specify, as opposed to lower cost generic components often found in general purpose PCs. For these users, performance, longevity, and expansion capability take precedence over achieving the absolute lowest cost through the use of the cheapest possible components. White box really gives users more flexibility to customize their infrastructure according to their own spec so that the infrastructure runs optimally for their specific applications.
2. Hardware Does Not Matter in White Box
Myth. It is true that software brings faster innovation, but hardware gets you concrete performance gains and power savings that cannot easily be achieved through software alone. Google and Facebook are working with ODMs to build their own servers and switches, because they not only want to differentiate at the software level but also differentiate at the hardware level. So don’t miss out on the opportunity to differentiate at the switch silicon level, as with System on a Chip (SoC), the switch silicon is the main point of differentiation in a switch system. For example, Mellanox Spectrum silicon can deliver highest throughput, low and consistent latency, zero packet loss with all packet sizes, and lowest power consumption at 10, 25, 40, 50 and 100G speeds, making it a perfect switch for cloud, NFV, and data-intensive applications.
3. If I Want to Have a Switch Design Specifically for My Applications, I will not Achieve Economies of Scale and the White Box Model will Break
Myth. Customization is a MUST in the white box market, and it is really a key motivation for organizations to move to white box, beyond cost optimization. You can’t expect to get something that Facebook built for their data center and expect that to work optimally for mission-critical, real-time telecommunications applications.
Of course, customization at an expensive price will not fly, and we must find ways to do mass customization with contained cost. To that end, switches must be disaggregated into modular components, and each component interacts with others through open and well-defined interfaces. This is similar to the micro-services movement in software architecture design.
Open Network Install Environment (ONIE) and Switch Abstraction Interface (SAI), are two of such interfaces defined by OCP to drive switch disaggregation and modularity and facilitate white box switch development.
4. ONIE is All I Need to Achieve Software and Hardware Disaggregation for White Box Switches
Myth. ONIE enables different Network Operating Systems (NOS) to run on the same hardware device, but if there is no unified switch silicon SDK, the NOSs still need to be re-written to call different APIs when switch silicon from a different vendor is used. With only ONIE, you can still be locked in to one switch silicon vendor.
SAI solves that problem by providing another layer of abstraction between the NOS and the switch silicon, and as a result, switch software vendors don’t have to worry about tailoring their NOS code for each of the many different brands of networking silicon. Instead, they can now focus more on their customers’ unique needs, and innovate at the speed of software.
As you might expect, the biggest challenge of white box integration is not assembling the various hardware components, but rather, making sure third party NOS can control the core functionalities of a switch correctly and efficiently. These core functionalities include negotiating link speeds, controlling packet forwarding and prioritization, controlling routes, stopping loops, multicast replication, and implementing ACLs. As such, Mellanox has invested a great deal into supporting the SAI initiative so that you have a common interface between NOS and switch silicon, and the switch silicon behaves as what is defined by software.
5. White Box Must be Open
Truth in most cases. Open is an overloaded word and can mean many things. In the white box switching scenario, it can mean:
The networking industry has mastered open standards, as different boxes in the network must speak the same language, or protocols, such as OSPF, BGP, MPLS, etc.
Open API is crucial to white box because it is instrumental to enabling the disaggregation of switch software and hardware, functional abstraction and modularity. Open source communities such as OCP are defining open APIs such as SAI to achieve that purpose.
Ultimately, white box is about choice, customization and flexibility, empowering the customers to run any network operating system over any switch hardware platform with any switch silicon. That is achieved through well-defined open API, often the results of collaboration through a standard body or open source community. Beyond that, customers can choose each module based on their needs, and the module can be open sourced or proprietary, as long as it serves the best interest of that organization.
That being said, when customers do consider open source solutions, they need to be careful that not all open source initiatives are created equal. On the open source spectrum, we have completely proprietary on one end, and on the other end, truly open multi-vendor open source initiatives that have been created to enable competing organizations to collaborate and include ecosystem players across the value chain. Mellanox is a loyal supporter of multi-vendor, truly-open open source initiatives such as OCP.
Then we got into the grey area of the OINO (Open in the Name Only) initiatives. These are often large corporations with near monopolistic control of markets offering “open source” solutions and pretending that they are part of a multi-vendor eco-system. Broadcom Open-NSL is an example of such an OINO initiative that is designed to distract users from the fact that they are being sucked into a path of vendor lock-in. So watch out.