You used an interesting word -- completely. There's going to be some vestiges of control left back on the main device, but maybe for simplicity's sake let's say it's completely removed. We've shifted it from running on an embedded processor in individual switches -- and that embedded processor is usually two or three generations old; if you open up a brand new switch today it wouldn't surprise me if you found an 8-year-old Power PC processor -- to a server, which could be the latest generation, multicore processor, etc. So getting 10X performance improvements is easy and even more than that isn't hard.
I understand you built your own gear for this network?
We built our own networking gear because when we started the project two years ago there was no gear that could support OpenFlow.
Did you replace existing equipment as you rolled this out?
This was a new network that we were building, so we didn't remove any equipment, but certainly, over time, we're in a position to do that.
Will you continue to use your homegrown gear or make the shift as companies come out with OpenFlow tools?
Our position is that, once there are switches out there that deliver the functionality we need with a nice OpenFlow agent, we would be very open to them.
Is there a hell of a lot of difference between a switch and a server these days anyway, beside the interfaces, obviously?
Great question. I think that there is a fair amount of difference in terms of instruction set and flexibility, but there certainly is an increasing amount of similarity. One thing I think the switching world would benefit from is an increasing amount of programmability. Having more flexibility in being able to do different things with different bits in your packets would be useful. There are some startups looking in this direction.
I understand another key benefit of SDN/OpenFlow is being able to play with a lot of "what if" scenarios to enable you to fine-tune the network before going live.
Exactly. So one of the key benefits we have is a very nice emulation and simulation environment where the exact same control software that would be running on servers might be controlling a combination of real and emulated switching devices. And then we can inject a number of failure scenarios under controlled circumstances to really accelerate our test work.
Are you actually pumping in fake traffic?
Yes, there's some amount of fake traffic. Obviously, we're not necessarily able to reproduce the complete scale. The nice thing is, if you think in terms of the total amount of traffic we might have in a data center, it's going to be substantially larger than total WAN traffic, so while our WAN traffic is substantial, LAN traffic is substantially more.