This week's interview takes a deep diving into networking, with Paul Congdon, HP ProCurve's chief technology officer. Congdon not only opines on managing network sprawl, but he's playing a big part in the solution. As the vice chairman of the IEEE 802.1 working group, Congdon is hard at work on the data center bridging standard, which seeks to make Ethernet the single converged fabric in the data center.
In our talk, Congdon explains why better management tools are needed to deal with the thousands of server instances--physical and virtual--now on many networks. He also sheds light on his advocacy for a distributed approach to networking architectures, which pushes more of the intelligent management and aggregation decision-making out to the edge. This stands in contrast to Cisco's more centralized philosophy.
Finally, we talk about how many enterprise data centers are likely to morph into internal cloud providers, or possibly even something akin to public hot-spot providers to their employees.
Our chat was longer than many other discussions I've conducted; this enabled us to dive deeply into the dense--and timely--subject matter. Accordingly, I've abandoned my usual practice of cutting the raw interview way down. Instead, I've left it nearly at full length; I think Paul's deep knowledge and passion come through better this way. I hope you'll stick with it.
InformationWeek: What's the key issue in networking today?
Paul Congdon: How we're going to manage the sprawl that's taking place--the fact that we have thousands and thousands of servers, whether they're physical or virtual, and how we manage this new environment where the network and the server are intimately related.
You're very well aware of the challenges behind VMotion [live migration of virtual machines] and mobility within the data center. That's a huge value to customers -- being able to move workloads around and being able to optimize performance and power efficiency. Live migration is a really valuable tool, but it puts some challenges on network design and topology.
The big thing that we're all trying to solve is, how to scale Layer 2 networks [i.e., the data link layer, where addresses are flat] out, to be really large and flat, so that we can better manage this mobility. I don't know if this is the initial knee-jerk reaction to solve the problem, or if this is going to be the long-term answer, but having large Layer2 networks is going to make things simple, because that's how administrators are used to dealing with their virtual networks, their switches; they're deploying their applications right now.
Getting Layer 2 to scale out is not necessarily as easy as it sounds, especially the numbers we're talking about -- hundreds of thousands of servers. And if you have VMs running, you're talking millions of servers.
InformationWeek: Isn't part of the difficulty the fact that people don't have good visibility into their networks now, and things are getting vastly more complex?
Congdon: Right. We're definitely pushing the envelope with the toolsets we have today. Visibility into what's going on is really difficult to obtain. That's one of the drivers behind this virtual-edge bridging that we've been working on, which is to enable better visibility into what's going on in the servers. For example, by using sFlow to give you that visibility, or embedded it into the switches themselves.
Then there's the scale of these tools. We're literally talking about millions of servers. The desire would be to put this all on one big VLAN, and then everything could move where it wants.
Another driver for why we want these big, flat Layer 2 networks is the convergence of Ethernet, taking over some of these protocols that were classically built on networks that were "Layer 2-ish," if you will; that is, non-routable, such as Fibre Channel over Ethernet (FCoE) and Infiniband.