ARN

ONUG gets closer to making SD-WANs talk to each other

The networking user group will share some details of an API for interoperability this week

A group of networking engineers and vendors is making progress toward an API that would help enterprises merge SD-WANs from different vendors.

The Open SD-WAN Exchange (OSE) initiative was launched last year by the Open Networking User Group (ONUG) to solve a shortcoming of software-defined wide-area networks: They often can't talk to each other. On Tuesday at the ONUG Spring 2017 conference in San Francisco, OSE will make public the work it's done so far.

SD-WANs control links to branch offices and remote sites with software, which ultimately should eliminate proprietary hardware and dedicated routing schemes. They also allow companies to use regular broadband connections instead of more expensive MPLS (Multiprotocol Label Switching) services.

But most SD-WANs built with different vendors' products can't communicate with each other, said Snehal Patel, a member of ONUG's board and a network architect at the retail company Gap.

That could be a problem after a merger or acquisition between two companies with separate SD-WANs. A lot of the agility and labor savings won through SD-WAN will be lost if the IT department has to go back to traditional networking to connect the two systems.

ONUG, a group of enterprise IT leaders advocating for technologies that better meet users' needs, has been working on this issue for several years and launched the initiative to solve it at the ONUG Spring 2016 conference. IT executives from companies such as Gap, Bank of America, BNY Mellon and FedEx are working with vendors including Cisco Systems and Huawei Technologies.

SD-WANs can interpret and carry out policies for things like when a branch-office connection should switch from the internet to a private link to maintain performance. They're based on industry standards, but vendors interpret those standards differently, so their network controllers can't communicate policies and commands, Patel said.

Those controllers may someday talk directly to each other. But for now, OSE wants vendors to build a policy orchestration layer that can talk to all of them.

Developing the API is one part of this effort. It will define things like whether there needs to be a persistent connection between the controllers and the orchestrator and what happens if a controller loses contact with the orchestrator.

The group has already finished most of its work, according to OSE Co-Chair Steve Wood, a principal engineer at Cisco. It's defined the requirements for the API, the architecture it will use, and other elements. OSE plans to publish the technical specifications during the summer for review by ONUG members, who include networking experts from hundreds of enterprises.

At last year's spring conference, ONUG also launched three other initiatives, which have had different trajectories.

The Open Traffic Management Format group pushed for a way to bring together management data from different physical and virtual network devices so it could be analyzed together. This could help determine the effects of system failures. Another project, the Open Network State Format, would be for data about the current state of network devices, so big-data techniques could be used for better real-time management. Those two efforts have been merged into a Monitoring and Analytics initiative.

The other project, for an Open Interoperable Control Plane, didn't fare so well. The OICP would work within data centers, connecting different parts of the infrastructure that are built on different architectures, such as OpenStack and VMware vCenter. Vendors and users met at workshops last year, but the effort is now on hold, according to Nick Lippis, co-founder and co-chairman of ONUG. He blamed stiff competition among vendors.

"On that one, we pushed the pause button, because the vendors don't want to play with each other," Lippis said.