The Impact of White Box on Cloud Networking

The adoption of cloud networking architectures by both the hyper-scale cloud companies and increasingly enterprise networks proves the need for open standards and modern networking software to gain the benefits of agility, programmability and resiliency. These architectures are all driven by the move to standardized topologies and container-scale deployment to achieve cloud economics.

The recent Facebook introduction of a reference design to align to the OCP (Open Compute Platform) server project with a network switch (“Wedge”) based on a Linux OS is a good benchmark for the use of open standards, control and merchant silicon. While many may view this as a threat to legacy proprietary networking, to me it’s a welcome validation of Arista’s approach to building modern software that is open and programmable as opposed to a proprietary, bloated and complex legacy OS. It is also a symbol of Arista’s co-development of APIs offering access for specific application control in Facebook’s network. This is a fitting example of how “white box” technology could be applied to a specific SDN use case. It is not trying to address broad data center use with multiple applications and mobile workloads.

Arista EOS for Universal Workloads and Workflows

Two factors are driving the rise of open universal topologies: workload mobility and workflow visibility. It is more economical and manageable to construct a uniform and universal network, one container at a time, rather than deploy ad hoc blocks of compute/network/storage. Within such cloud-scale environments, it becomes practical to control networks centrally using a software foundation such as Arista EOS, which utilizes open APIs to communicate between the network infrastructure and specific cloud applications. Arista’s decoupling of the network OS from applications allows the network to handle any application that might migrate to any part of the network now or in the future. To fully benefit from cloud networks versus legacy approaches, one must embrace cloud topologies, such as a tier of identical spine switches connecting to a large number of identical leaf switches in a full mesh leaf-spine two-tier topology or single tier “spline” topology.

Support for programmability and control at all levels of the switch software architecture (i.e., Management, Control and Data planes) is essential for flexibility and control of the network infrastructure. Arista EOS supports the granular programmability needed for this capability with an unmodified Linux kernel and a centralized System Database (Sysdb) which holds all system state. This level of programmability entails being able to apply a variety of forwarding actions, at line rate, on all ports simultaneously to the forwarding plane through the EOS System Database (Sysdb) while using a wide range of flow-matching techniques. This has required 1000+ man-years of engineering development and represents a decade of engineering investment from Arista.

Complementary Use Cases: Universal versus Solo Applications

A White Box OS model can work for a single, specific application in which one can narrow the use case to the specific topology of this single application, and can then develop for the narrow set of features required by this application. It has been reported that Google originally implemented this concept in 2004 (using several hundred internal engineers) to build a product. Facebook’s proposed design is another approach to open application control. These are both validations for open use cases in cloud networks.

Outside of these specific use cases, the need to be able to support
broader applications and mobile workloads and workflows using a Universal Cloud Network architecture has driven the need for a broad and rich set of features and capabilities. This includes the massive scaling of the MAC address table, layer-2 redundancy, in-service software upgrades at both the spine and the leaf, VXLAN and overlay network termination, integration with cloud orchestrators for virtualization and analytics, and improved network-wide manageability and visibility. White Boxes have limited support for these advanced capabilities.

In this new world of software driven cloud networking, the granular separation of control, management and data plane is needed. Each EOS function runs in its own restartable protected address space, in much the same way that daemons run in Linux. In fact, because we have preserved the Linux APIs, a wide variety of Linux tools (such as tftp or fping) can run directly on Arista switches, in addition to the functionality provided by EOS, to bring the best of both worlds.

White Box approaches and Arista Cloud Networks are indeed different segments that can co-exist for different applications as shown in the diagram below.

Summary

The cloud networking switch market is at an exciting junction and is segmenting into different use cases. Cloud networking designs can be specific to a single application or can be more flexible and multifunction. Some cloud providers may take a “lego” approach to their infrastructure by building internal teams capable of making the necessary investment in development engineering and support for products with narrow applications, while others will demand a more flexible and universal system solution for multiple big data, storage, compute and virtualized workloads. As always, I welcome your views on Software Driven Cloud Networking at: feedback@arista.com.

References:

• Arista Webinar with Nebula: Transforming the Enterprise Data Center to a Scaled Out Private Cloud
• SDCN White Paper
• Video: Arista Powers the Cloud with EOS
• Open Industry Consortium to Bring 25 and 50 Gigabit Ethernet to Cloud-Scale Networks