HP Predicts Significant SDN Adoption By 2015
Andrew Conry Murray
October 02, 2013
HP announced its SDN developer kit and a forthcoming SDN app store earlier this week. I had a chance to sit down at Interop with Bethany Mayer, senior VP and general manager of HP's networking business unit, to talk more about HP's SDN strategy.
The company is officially launching its SDN controller at the end of the month. As the programming interface between the physical network and northbound applications, the controller represents key real estate for vendors as they grapple with SDN's potential disruption to the network hardware market. The controller is a linchpin to preserve (or grow) market share.
- Big Data Analytics: Are You Ready?
- Bring Salesforce.com Alive with Your Key Business Processes: Register Now
- Forrester Study: The Total Economic Impact of VMware View
- HP Newsletter with Gartner Research: Maximizing Your Infrastructure through Virtualization
"The control point in the network is strategic to us," says Mayer. "We'll continue to innovate around the control mechanisms, whether it's automation, provision or management. We believe the intelligence of the network is valuable."
[Experts weigh in on the impact of SDN in the slideshow "10 Ways Software-Defined Networking Will Change IT."]
I asked when she thought SDN would see significant uptake in the enterprise. "I would say within the next two years," she says. "Two years, no less. Other places in the infrastructure have been so much more innovative than the network. The network has been the same for as long as I've been doing networking." She adds that, given the pace of change we've seen in other areas of the data center, there's no reason the network couldn't match that pace going forward.
If SDN delivers on its promises, it's going to automate a lot of the configuration work that happens today. As you might expect, that can be worrying to the network administrators who do that work. (This topic will be explored at the Interop panel "Will SDN Make Me Homeless?.")
Mayer recognizes the concerns, but she also says there will be opportunities for network professionals. "I think automation is a good thing, regardless of whether folks are worried about their jobs or not. It provides them an opportunity to do things that are more value-added. You don't have to sit around writing PERL scripts for the CLI."
SDN is spurring debate about the role of network hardware, and whether moving more intelligence out of switches and into a controller means hardware costs should come down. Some proponents see the rise of network gear built on merchant silicon rather than custom ASICs. Mayer says HP builds switches with both merchant silicon and its own ASICs.
"It doesn't have to be just cheap bare metal," says Mayer. "There can be, in some cases should be, control mechanisms on the switch, that are valuable to be on the switch. And there are control mechanisms for software. As a result, you have in some cases a split control plane, and that's OK. The switch doesn't have to be completely dumb. There's value there in being intelligent."
HP is emphasizing openness as part of its SDN strategy. HP participates in OpenDaylight, an initiative being overseen by the Linux Foundation to create an open-source controller and a common set of northbound APIs. The company also points to its support for OpenFlow as evidence of its commitment to openness.
However, by shipping ASICs, the company would need to develop its own APIs outside of OpenFlow to enable a controller to leverage those ASICs. This is the approach Cisco is taking with its onePK initiative. When I asked Mayer if there might be efforts along these lines, she noted: "We have the potential to create APIs that can provide more programmability."
Mayer also weighed in on the underlay vs. overlay debate, which has come to the fore with the launch of VMware's NSX. While she acknowledges the value of overlays and notes HP's support for VXLAN, an encapsulation protocol, she also says, "The value of having an underlay from top to bottom really allows you to be certain of delivery of traffic. You need certainty of QoS from A to B, which can only be had if you understand the devices beneath a tunnel."