The Four Pillars of Software-Defined Cloud Networking

Software-defined networking, an exciting buzz word these days really means different things to different folks. Often Openflow, ONS (Open Network Stack) and various controller approaches are touted as the promised land of software-defined networking. The term “Fabric” touted by many vendors, creates further confusion on proprietary ways on its benefits and significance.

At Arista we believe that good old fashioned Ethernet scaling from 10Gigabits to 40 Gigagbits to100Gbit and even Terabits with well-defined standards and protocols for L2/L3 is the optimal approach. This allows large cloud networks of 10000+ nodes to 100,000+ nodes in the future without re-inventing the internet or proprietary tags. At VMWorld 2011, VMware announced an exciting technology VXLAN (specification co-authored by Arista for IETF submission) that enables large scale cloud networking

Its important to recognize that building such massively scalable and dense cloud compute, storage and virtualization driven networks does create its own set of management challenges different than legacy enterprises. Arista has identified these challenges and been solving them methodically, step by step as the four pillars of software defined networking.

Pillar 1. Single Point of Management: Single point of management has been tackled in the past by various enterprise stackable technologies that have been platform specific and throughput limited. In theory it can be layered on top of the traditional control plane and data path of a cloud network. Simply put it is all about coordinating the configuration s across multiple otherwise-independent switches. No "fabric" technology required, and no need to turn every switch feature into a distributed systems physics problem. Arista’s CloudVision is a good standards-based example of this using XMPP messaging methods.

Pillar 2. Single-image L2/3 control plane: Some vendors are trying to recreate three decades of networking control plane architecture work to rebuild from a proprietary starting point. These are multi-year expensive undertakings with vendor lock-in that disregards the IETF and IEEE work done to-date on internet protocols. We find ourselves debugging box-by-box where the control protocols are poorly documented, misunderstood by the customer with insufficient and proprietary tools.

Instead standards based L2/L3 IETF control plane specifications plus OpenFlow options (without hype) can be a promising open augmentation for providing single image control planes in the future. OpenFlow 1.1 implementations in the next few years will be based on specific use cases and the instructions the controller could load into the switch.

Pillar 3. Multi-path Active-Active Data Path: Scaling Cloud networking across multiple chassis via MLAG (Multi-chassis Link Aggregation Groups) at L2 or ECMP(Equal Cost Multi Pathing) at L3 is a standards based and scalable approach for uncompromised cloud networking. Together they cover all of the important multi-path deployment scenarios in a practical manner not introducing any proprietary inventions.

Pillar 4. Network-wide Virtualization: By decoupling physical infrastructure from applications, network wide virtualization discourages islands that only optimize one segment of the network for one particular application. Instead, it makes sense to provision the entire network to seamlessly handle any application anywhere on the network so that the economics of virtualization can be properly leveraged using controllers from VMware and their new paradigm for VMWare’s VXLANS or Open Virtualization Switching (OVS) controllers in the future.

Arista EOS – the Foundation

What is clear is that cloud networking and the four pillars I just described needs an appropriate software foundation (such as Arista EOS) using well-defined and open controller APIs to communicate between the network and the controller for the control of cloud scale and explosion as shown in the diagram below.



Welcome to the new world of cloud networking scale. As always, I welcome your views at feedback@arista.com.

References:

• VXLAN specification to IETF (VMWare, Arista et all )
• VXLAN Overview - Technology Bulletin