SDN and NFV Era
SDN and NFV Era
Facebook, Open/R, Juniper, and Open Networking
11.17.17

Facebook made waves earlier this week when they announced that they were open-sourcing their Open/R platform. In the latest push towards disaggregated networking components and open source software, Facebook outlined how they are working with Juniper Networks and others as they transform their backbone and data center networks.

 

About Open/R

In a Facebook post from 2016, Petr Lapukhov described Open/R as “a custom-built, extensible distributed network application platform…originally designed as a shortest-path routing system to power Terragraph, our multi-node wireless network.”

 

Essentially, Facebook has built a set of hardware-agnostic routing capabilities useful in supporting their wireless, backbone and data center networks. Leveraging a set of building blocks that feature ZeroMQ as a lightweight message bus and Thrift to handle message encoding, they have created a replicated state database not unlike what you would see with more typical routing protocol implementations.

 

They add a pair of agents (FibAdapter and FibAgent) that are responsible for publishing and receiving forwarding-table updates. By connecting these agents through to the routing and forwarding-tables in commercial routing and switching platforms, Facebook can modify the forwarding behavior using software that resides outside of the commercial network operating systems. 

 

More succinctly, using Open/R, Facebook is disaggregating the routing decisions from the underlying network software.

 

Start with a platform-first approach

For any of this to be possible, the underlying networking products have to be built explicitly with a platform-first mentality. So, what does it mean to build something as a platform?

 

There are two basic requirements for a platform-first approach: extensibility and longevity. 

 

Extensibility requires that the underlying hardware and software both feature well-defined interfaces. These interfaces need to create separation between the higher-level applications and the lower-level components. And, of course, the code around these interfaces must be maintained with fairly strict API discipline to avoid unnecessary coupling of components across boundaries. 

 

While these kinds of design criteria have gotten more press in recent years, Juniper has actually been committed to platform design since its founding. Junos was architected as a modular operating system with extensibility explicitly designed in. Whether it was our industry-leading NETCONF support or networking’s first full software-development kits (SDKs), Juniper has consistently pushed the boundaries of device programmability. In many ways, for Juniper, Open/R is simply a natural progression of a trend that has long been a differentiator.

 

Of course, extensibility is only half of the requirement. A platform that lacks longevity is not suitable as a foundation. In Junos, Juniper has developed a platform that has powered the most aggressive networking environments on the planet. From routers and switches to security devices, Junos has proven that it is purpose-built for evolution. As networking enters what could be the golden age of programmability, Junos is well-equipped to play a leading role. 

 

Disaggregation and Open/R

While Open/R might start with a platform approach, it is probably most directly associated with the broader industry trend around disaggregation. In a single sentence, disaggregation is simply the decoupling of components.

 

When people talk disaggregation, they typically envision the separation of hardware and software, like with white or brite box networking. Indeed, Junos supports the required building blocks to make this form of disaggregation possible—every QFX5100 ships with ONIE, for example.

 

But disaggregation is more than just hardware and software separation. As Facebook has demonstrated, there is value in decoupling individual components. By exposing programmatic APIs that allow control of systems and subsystems, Junos has allowed Facebook developers to write their own routing applications capable of programming the FIBs on the underlying line cards.

 

Facebook’s Open/R effort leverages gRPC-based APIs within the Juniper Extension Toolkit to program the FIB within Junos, as well as the ability to run third-party applications alongside Junos on Juniper devices. This means that Open/R can use Juniper’s industry-leading protocols to handle routing and forwarding for most traffic, while reserving the ability to program routes for specific traffic that requires special treatment.

 

This is remarkable because it provides control—not just over the forwarding behavior, but over Facebook's broader networking ambitions. For companies that want to push the envelope faster than the rest of the industry, being constrained by vendor development schedules and resourcing can be limiting. By opening up APIs and encouraging third-party development, Juniper has given Facebook, and the community (they hope), to spawn more access, and in doing so, more control.  

 

Open networking and leverage

If you read the Facebook posts carefully, you will see a theme: leverage. They use Thrift and ZeroMQ because they want to leverage components that are well-suited for their purpose. Similarly, they have built Open/R so it leverages the foundational elements of the industry’s leading network operating systems. 

 

If all the open networking movement does is replace high-value components with community-driven equivalents, the industry doesn’t move forward. Rather, the value in open networking is in extending the very best of what we have and adding new functionality at the speed of community. 

 

With that in mind, it should be clear why Juniper is thrilled to play a part in the effort. We’ve always been about advancing the interests of our customers. And in helping drive the platform and disaggregation movements within networking, we are clearly shaping how the network will evolve.

11.29.17
rsathyaraj

👍

Top Kudoed Authors
User Kudos Count
2