On to Sign 3 – Software Controls. Traditional box-by-box networking has often been mocked as “hardware-defined” or “hardware controlled.” Cloud Giants figured out a decade ago that software controls are critical to make the underlying hardware networking infrastructure logically centralized. According to the Google design principle: Logically centralize.. with a hierarchical control plane...
Traditional DC networking is mostly box-by-box, which is very complex and brittle (see diagram below). All workflows, Day0/Day1/Day2, are cumbersome and can take hours, days or even weeks. SW upgrades often take months, due to limited upgrade windows during nights and weekends. Occasionally DC operators leverage vendor’s own network management system which provides some provisioning help, but also has scaling challenges, even for medium size networks, features are missing, and are almost never up-to-date with latest releases.
Alternatively, software controls applied by Cloud Giants have yielded tremendous operational simplification and amazing speed of change management. They leverage combination of policy controller and network controller to implement a hierarchical control plane, as shown in the diagram below. Data plane of course always resides on the switch itself. As mainstream IT organizations started to require their networking vendors to support software controls, any capability invoked through software got clubbed into “software controls”, including traditional centralized management consoles. Broadly speaking, there are really two types of modern software controls – policy controls and network controls – as shown in the diagram below. Their functionalities do not overlap, while together they can truly make the network “invisible”, make it operate at the speed of VMs & containers. Note that policy and network controllers are architectural constructs and can be implemented as separate entities or as a unified entity.
What is a policy controller?
A policy (and mgmt) controller programs individual switches (on a box-by-box basis), leveraging NOS’ northbound APIs. It automates workflows such as switch insertion/removal, switch upgrades, network configuration. It does not however eliminate control plane complexity, in regards to forwarding protocols. In a 100-switch fabric, there are 100 BGP instances to deal with along with their associated complexities.
How is network controller defined?
An externalized network controller on the other hand eliminates control plane complexities, specifically related to forwarding protocols. While software defined networking (SDN) popularized the role of externalized network controller, it also insisted that the control plane be strictly centralized – an unrealistic requirement in networking where scale and resiliency are paramount. This led networking vendors to define SDN arbitrarily to fit their products, resulting in the creation of the term “SDN-washing.” Some analysts even started to guide customers on transformational use cases over SDN’s technical purity (e.g. Gartner: Never Mind SDN — Focus on Leveraging New Digital and Hybrid Cloud Opportunities).
If however the control plane is hierarchically implemented, in accordance with the computer science best practice – distribute what is must, centralize everything else – a true logical switch fabric (or logical switch chassis) can be implemented. By definition, complexity is bounded to that of 1 switch, even if the fabric itself contains 100 switches. There is only 1 BGP instance, on the network controller (like a chassis supervisor). Each switch in the fabric has a very lightweight network OS (like a chassis linecard).
Does Sign #3 pass the “Principles of Transformation” test?
How about network overlays and underlays?
SW controls can be applied to both virtual overlays and physical underlays. An overlay controller operates on virtual switches, whereas an underlay controller operates on physical switches. A best-in-class overlay/underlay solution would leverage software controls for overlay as well as underlay.
Are NOS APIs or a disaggregated NOS considered SW Controls?
Not really. APIs make a switch programmable, but it needs an external controller to truly control it. One can write a set of python scrips, Ansible manifests, etc. to externally control the network, but that’s simply a newer version of TCL and PowerShell scripts that IT teams wrote 15 years ago. Similarly, disaggregated NOS is an important element of network transformation (see Sign 1), but far from being qualified as “SW controlled.”
What is controller-less or distributed-controller system?
This is more of controller-washing, by vendors who are not offering controller-based fabrics. Controller-less means you basically have the traditional thick NOS based switch, operated on a box by box basis. It might have some multi-switch configuration workflows embedded in the thick NOS, but by no means will ever have the power of a controller-based fabric. Ditto with “distributed-controller” marketing – basically each switch has it’s own control plane, a la traditional complexity-rich paradigm.
How is Big Switch Implementing software controls?
Both of Big Switch’s open networking fabric solutions, Big Cloud Fabric (BCF) and Big Monitoring Fabric (Big Mon) are controller driven – keeping true to its Cloud-First architectural strategy of applying cloud principles as first principles. Each product implements a unified policy/mgmt + network controller as a unified controller entity. Moreover, the entire fabric of dozens of switches (140 leaf/spine switches in BCF) operates as a logical chassis, thus massively reducing operational and change-management complexity. Both BCF and BMF controllers integrate with private cloud orchestrators, such as VMware vSphere/NSX/vSAN, Nutanix Enterprise Cloud, Red Hat OpenShift and OpenStack, and Kubernetes, to enable network automation and visibility. Some examples of speed and simplicity are listed in the table below. Both BCF and BMF controllers also integrate with public clouds, such as AWS and Azure.
With SW controls, the network is truly out of the way, never a roadblock, operates at the speed of VM/container/cloud and is mostly invisible.
Ready to guess SIGN #4?
VP & Chief Product Officer
Prashant is responsible for Big Switch's Cloud-First Networking portfolio and strategy, including: product management, product marketing, technology partnerships/solutions and technical marketing. Prashant has been instrumental in the product strategy and development of Big Cloud Fabric and Big Monitoring Fabric products. Additionally, Prashant is responsible for Big Switch led open-source initiative, Open Network Linux (ONL), to accelerate adoption of open networking and HW vendor choice. You can connect with Prashant on LinkedIn.