Enterprise Connect Panel Discusses SD-WAN Best Practices
The idea of the software-defined WAN is trending, which means lots of hype and confusion to work through on the way to deployment.
Historically, the communications and networking industries have only had a loose association with each other. However, as more communications functions move to the cloud, the network, particularly the WAN, plays a more important role in how these applications perform.
This is one of the reasons why Vonage, one of the largest unified communications as a service (UCaaS) providers, has introduced a software-defined WAN (SD-WAN) service. The service, called SmartWAN, is intended to deliver enhanced quality of service to UCaaS customers.
However, as I pointed out in my Enterprise Connect SD-WAN session preview post, "Software-Defined WAN: Realit or Just More Hype," SD-WAN is a somewhat confusing topic. I tackled this topic on Tuesday, leading a discussion among panelists from Level 3 Communications, Talari Networks, VeloCloud, and Cisco with the aim of defining this nebulous topic and coming up with a few best practices for deployment.
Defining an SD-WAN isn't easy, but all panelists agreed on the following attributes:
- Abstraction - the control plane of the network is separated from the data plane and abstracted up into a software layer. This is the literal definition of "software defined" and is what enables centralized administration rather than box-by-box administration
- Zero-touch provisioning - all that should be required for an enterprise organization is to plug the device into a network connection and power. The network devices should be provisioned automatically without any further manual intervention. This auto-configure capability means a business should be able to ship a network device to a remote location and have anyone there plug it in and be done with setup
- True multitenancy - any service provider offering SD-WAN services should have complete isolation of networks among customers. This attribute is primarily for network operators, but could apply to very large enterprises as well
- Orchestration capabilities - you never change a network just for the sake of change. Rather, some kind of application change typically drives the need for a network change. Network modifications should be orchestrated as part of the behavior of the application. A simple example is that if a video call is being made across the WAN, the video application should direct the network to create a dedicated path between the two points for the duration of the call and then remove the path when the call ends
- Northbound APIs - the best way for network orchestration to occur is that the applications are able to communicate with the network through APIs. This also enables organizations to move to true policy-based networking and allow business policies to drive application and network changes
- Big data and analytics - networks generate a tremendous amount of data. SD-WANs should have the ability to capture all relevant data, analyze the information, and provide insights that an organization to tune or tweak the network to optimize application performance. Organizations can use good visibility and analytics to isolate problems and find security breaches. "Network nirvana" would be a network that is completely automated and self-healing
During the panel we also discussed why customers should deploy an SD-WAN and, not surprisingly, every vendor agreed that an SD-WAN offered a big savings over traditional networks, such as MPLS. However, in my research, I've found no guarantee of a savings, particularly in a hybrid mode with MPLS. But I don't think cost should be the driving force anyways. As I commented during the panel, if all a business wants to do is to save money, then it should renegotiate the network contract.
The value proposition should be around having an agile network. A digital business needs a flexible IT foundation. The infrastructure will only be as agile as the least agile component, and that today is the network. SD-WANs can make the network agile.
To wrap up the panel, I asked each panelist to come up with one piece of advice for any company that's considering moving to an SD-WAN. Here are the responses:
- Mike Wood, VP of Marketing, VeloCloud: Take an architectural approach to building the network. Think about the network needs today but also how it can scale when needed as the requirements change over the next three to five years
- Travis Ewert, SVP of network software development, Level 3: Start small with a hybrid deployment. Before touching the main backbone, consider a "fill in" strategy, where an SD-WAN is used to connect smaller locations or ones where the contract with the current operator has expired
- Kevin Gavin, CMO of Talari Networks: Meet with multiple vendors and ask for references and case studies. There are a wide variety of SD-WAN solution providers so the only way to find out which one is best is to talk to a number of vendors as well as their customers to ensure that it's the best fit
- Bill Hentschell, worldwide sales leader for enterprise routing, Cisco: Think about the branch holistically. There's no point in changing the connectivity to the branch if the connectivity inside the branch isn't business quality
In my previous post, I asked if SD-WANs are a reality or just more hype. Based on the feedback, it appears this technology is still largely hype but moving towards reality as the best practices get developed. Hopefully we'll address more of these topics at Enterprise Connect 2017.