Another executive has switched out of Big Switch Networks, as Andrew Harding has joined VSS Monitoring as VP of product line management, SDxCentral has learned.

Harding's departure comes shortly after Howie Xu, former vice president of engineering, left Big Switch and joined Cisco.

Before becoming senior director of product marketing at Big Switch, Harding spent time at Aruba (where he helped to nearly double the company's market share and also oversaw the start of the 802.11n era) and Cisco. He was also director of security products at Juniper as a result of the fish-swallowing-fish act in which Neoteris got acquired by NetScreen, which got acquired by Juniper.

SDxCentral reached Harding by email to discuss his new job and how VSS Monitoring is relevant in the software-defined networking (SDN) world. Here's a portion of that conversation.

Why VSS Monitoring?

Harding: I met Martin Breslin [VSS' founder and president] and the team a few years ago, when VSS was a small startup. They continue to set the pace of innovation in the network packet broker (NPB) space with functionality and value that are not available anywhere else. Martin is a true entrepreneur and, while every startup’s story is unique, this team’s passion and focus on solving real problems reminded me very much of Neoteris/Netscreen and Aruba Networks. I remember those days fondly, of course.

What got you into the tap aggregation/monitoring market?

Harding: To be honest, I had not paid enough attention to this part of the network in the past. I encountered VSS in customer networks, and visibility tools have increased in importance as data-center and network operators continue to grow infrastructure at a fast pace.

Those who term this “tapping” or simply “aggregation” for monitoring systems underestimate what’s happening in these networks. We have moved beyond tapping and aggregation to a passive “shadow” or “reflection” of the production network that can be used to monitor performance and address the challenges of securing large-scale networks and ensuring service availability. Today, we are also operating on active traffic — that’s the next phase of this space: packet brokers that can work passively or actively — at wire speed — and without adding a small army of programmers to the network team to support the system. We’re raising the bar on the reliability, scalability, and performance goals that are achievable in large-scale networks while containing costs.

With VSS, network providers have a chance to rethink how network monitoring and network security are designed. Today, it’s possible to achieve pervasive visibility, monitoring traffic in every important segment and delivering that traffic to tools anywhere in the network. As a result, they can increase efficiency and contain operational costs, while simultaneously improving security and service levels. The opportunity to be part of driving this large-scale change was the catalyst in my thinking.

Where does VSS play in SDN?

Harding: Software-defined networking or application-defined networking is really about delivering flexibility and doing so cost-effectively. There is flexibility that comes with a programmable system, but a programmable system can introduce complexity and constraints if it requires a whole new architecture that doesn’t co-exist with existing infrastructure. VSS has focused on virtualizing network traffic and packet flows specifically for monitoring and security applications. And we introduced an XML API to enable programmability.

VSS supports wire-speed operation and fail-safe monitoring, where data can still be delivered even in the event of hardware failures within the system and where reliable, deterministic delivery of packets to security systems and tools can be ensured to meet rigorous service-level agreements. The combination of purpose-built performance and intelligence, including application-layer health checks on tools, dynamic triggers that can change the delivery policy based on events, and our XML API for external programmability amounts, in a very real sense, to a hardware-accelerated SDN for monitoring and security. But we’re really trying to stay away from the hype and just address some big challenges in monitoring and security.

Is OpenFlow part of the VSS plan? What's your take on OpenFlow?

Currently, VSS products do not have support for OpenFlow. We are looking at what use cases require OpenFlow, and I expect that as OpenFlow implementations mature and if OpenFlow is deployed broadly, then NPBs will ultimately support OpenFlow and related protocols as one method for instrumenting flows. Today’s products have been designed to support OpenFlow or other SDN control or management protocols; we’re really waiting on customer demand to set the priority.

Increasingly, I view OpenFlow as a tool for building systems. It’s an important tool for network infrastructure providers to consider and for network operators to investigate. If OpenFlow delivers centralization and automation in a multivendor environment, that’s a benefit for operators. I do worry about the scalability of current OpenFlow controllers and the implementation in the current generation of switches. Further developments in the chipsets, the OpenFlow firmware, and in the controllers are required before broad adoption is possible, except where large software and systems teams can support the engineering and deployment.

I expect success with OpenFlow to require large software and systems teams within customer environments to succeed for some time. The widely publicized deployments at Microsoft and Google support this position in my view. While there are use cases that are clearly a fit for OpenFlow in the WAN and on campus networks, large-scale data centers, today, might achieve their agility, scale, and cost-management goals another way, and without the costly downside of nascent OpenFlow architectures. If operators can achieve the automation, capex reduction, and opex reduction goals while maintaining service assurance and do so without adding their own systems builders or programming teams, that’s something to consider as well.

Where do SDN type solutions — like Big Tap — fit compared to where VSS plays?

Harding: If a network operator is looking for a first SDN application, then OpenFlow-based network monitoring is something to look at. If the application doesn’t operate on production traffic and if it operates in a relatively simple environment, OpenFlow software taps, using OEM switches or using white-box switches with the Indigo/Switch Light firmware from Big Switch, remain a good option for learning about SDN. I might start with the sources available from www.projectfloodlight.org or www.opendaylight.org. Or you might wait until either of these projects releases an image.

There is a range of OpenFlow switches from several providers, of course. And, for lab deployments or for the most aggressive customers, the Big Switch switch firmware and Floodlight controller provide a system that comes from a single vendor, so it’s one-stop shopping for free and open-source software. I continue to believe that network monitoring is a better choice than network virtualization for a first SDN application. But customers have to consider whether their critical needs in monitoring can be mixed in with SDN education. I’d recommend a hybrid approach or an approach that starts with SDN in lab deployments and proves it out over the next year or so.

If a network manager wants to take a risk, then in a hybrid network-monitoring deployment that includes OpenFlow systems and important services like packet slicing, filtering, time-stamping, and triggers can be supported in a VSS vBroker. VBroker will enable the network manager to try out SDN in some areas, while relying on packet brokers for areas of the network where fail-safe delivery and 10G or 40G performance are required. Conducting a comparison of hardware-accelerated NPBs and pervasive visibility systems with OpenFlow-based packet capture will provide a strong learning environment for SDN, and enable the customer to see what the most innovative NPBs are doing and make an informed choice about OpenFlow in production networks.