For many in the networking space, disaggregation has become synonymous with white box switching. The concept of disaggregation, however, is actually broader and can have a profound effect on the industry at large.
At Juniper Networks, disaggregation is both the strategic thrust behind a lot of our efforts and an engineering principle that underscores virtually every architectural decision we make. It is at once an explicit part of our roadmap and an implicit directive to our engineering teams.
And, as a core part of what we build and how we build it, disaggregation plays a key role in our broader corporate strategies around cloud, multicloud, and distributed and edge cloud.
What is Disaggregation?
While the term is not specific to networking, most people equate disaggregation with the white box movement and the separation of hardware and software for data center switches. While this is an example of disaggregation, it is a narrow definition of a much broader movement and ignores the true value of disaggregation across other elements within networking.
At its most basic level, disaggregation is simply the decoupling of two normally integrated components, with the goal of creating choice and flexibility at a more granular level than the overall system affords. If users can mix and match components, then they can build a system that is a unique fit for their specific purpose.
More than Cost
In today’s dialogue, purpose typically maps to cost. The white box movement, for example, is driven primarily by a desire to lower the cost of data center switches. But that’s not the only objective of disaggregation.
Some might employ disaggregation to optimize for performance, especially to support applications that require low latency. The high-frequency trading space is notorious for trying to extract every last microsecond out of a transaction. Another aspect of performance is operational consistency with common management over a mix-and-match of hardware.
Others might optimize for control. For companies that provide as-a-service offerings, specialized control might provide a unique competitive advantage that cannot be replicated by others purchasing the same infrastructure. In this case, disaggregation allows programmability beyond the vendor system to fine-tune the solution in unique ways.
Still others might consider the purpose of disaggregation to be related to security. The use of private encryption algorithms, for instance, might be critical, especially in military and intelligence operations. Disaggregation provides a path to security that doesn’t necessarily rely on black box implementations that leverage code from third parties that are just beyond direct inspection.
While cost is certainly top of mind for most, disaggregation is really a path to achieving a much broader set of objectives in a fit-for-purpose deployment.
More than Hardware and Software
The reality is that any two things that are coupled can be disaggregated. The separation of control and forwarding, for instance, led to the emergence of forwarding paths that run on network-optimized silicon. This separation is more than just hardware and software, and the goal was more than just reducing cost.
In today’s network devices, there is a tight coupling between the software and hardware data planes. That is to say, the packet pipeline is typically married to the underlying silicon, which has led to a virtual monopoly in the merchant silicon space. With standards like P4 taking root, disaggregation could effectively lead to the separation of silicon and forwarding, driving more competition in the ASIC space and creating an economic lever in one of the leading cost drivers in switches and routers. This was a major driver behind the work that Juniper did with P4 alongside Google.
Another example of disaggregation is the separation of network control (read: routing decisions) from the rest of the network OS. Earlier this year, Juniper announced support for Facebook’s Open/R efforts. By allowing an external piece of software to program the routing tables, Juniper is effectively disaggregating subsystems that used to be tightly coupled within the network OS.
There are even non-traditional ways to think about disaggregation. In chassis systems, line cards are typically tied to the chassis. When Juniper introduced its universal chassis earlier this year, it disaggregated the line cards from the chassis. As a result, the chassis does not become an MX Series or PTX Series platform until the line cards are inserted. This allows operators to leverage a common chassis to service a range of needs, changing its identity by merely changing line cards.
Implications of Disaggregation
Disaggregation can also have a profound impact on system design.
When mixing and matching components to create a fit-for-purpose experience, two natural requirements typically emerge: interoperability and interchangeability.
First, within a disaggregated stack, components must be interoperable at their respective boundaries in order to work together. To disaggregate the software data path from the underlying silicon, the software and silicon must be interoperable. This leads to the emergence of APIs at the boundaries. P4 serves that role in this example; every other example of separation will require a similar interface that allows for interoperability.
Second, if the goal is to allow users to mix and match to optimize for purpose, then the components have to be interchangeable. That is to say, an operator must be able to replace Component A with Component B. In the white box switching use case, economic leverage only exists if there are multiple options for both the networking OS and the underlying hardware.
Interchangeability places an additional requirement on the interface boundaries: they must be open. If an API is closed (either proprietary or not accessible), no other components can be integrated across the boundary. This limits consumer choices, which effectively neutralizes the benefits of disaggregation.
Therefore, at every disaggregated boundary, there will be an open interface. Whether it’s NETCONF between management and control planes, reference architectures between switch hardware and software, or P4 between software and hardware data planes, networking will continue to depend on openness for progress.
What Comes Apart Must Come Back Together
Just like what goes up must come down, what comes apart must come back together.
IT does not deploy subsystems; they deploy components that must come together to form a usable solution. This means that disaggregation will naturally lead to an integration requirement. Integration will not always be a straightforward exercise of loading things and expecting them to work.
In the white box space, for example, there are wonderfully quirky things like BIOS. Two systems that use functionally equivalent components can behave in completely different ways. It simply isn’t reasonable to expect that—even with open interfaces—users can freely mix and match any-to-any and expect things to work without having to perform basic integration tasks like testing and qualification.
There are different ways to handle integration. Some might prefer to rely on partners to deliver integrated solutions, while others might take on the burden themselves. Regardless of division of labor, companies looking to take advantage of disaggregation must carefully consider how they will handle integration.
Finally, although disaggregation will transform the networking world in the era of multicloud, it is unlikely that there will be a vast array of choices for key functional components. Due to the subtle behavioral differences across even standard interfaces, it seems more likely that a small number of viable solutions will emerge, likely aimed at the various fit-for-purpose drivers that serve the market.
Good Engineering Design
Fundamentally, Juniper believes in disaggregation at every layer—it’s just good engineering. Designing modular systems with well-defined interfaces allows development to be distributed—not only across different teams within Juniper, but also across different innovation circles within the industry.
The Juniper product portfolio features a number of proof points:
- Control and forwarding in Junos OS
- Network control through programmable RPD
- Network management with NETCONF
- White box switching with OCP-compliant hardware
- Third-party software support on Juniper hardware with ONI
- Chassis and line card separation with the universal chassis
- Forwarding abstraction through AFT
- Subsystem-level control through JET APIs (Open/R, for example
- P4 support
- Sonic support
Clearly Juniper’s disaggregation ambitions run deep, and the production implementations are broad. Ultimately, Juniper believes in building disaggregated products from the start; as commercial demand increases, the accompanying business models will follow. This is why Juniper has led disaggregation efforts across its entire portfolio and will continue to embrace disaggregation as a cornerstone engineering principle required for the era of multicloud.
It will be interesting to see where disaggregation takes the industry. For more on disaggregation, listen to industry experts at Cumulus Networks, Caliber Home Loans and Juniper Networks talk about the current landscape, how they design for disaggregation and what big disruptors are on the horizon.
