It’s been a while since we caught up with Nick McKeown, chief scientist at Barefoot Networks.
Longtime SDxCentral readers know the resume. McKeown and U.C. Berkeley professor, Scott Shenker got software-defined networking (SDN) off the ground through research that led to the OpenFlow protocol. They founded Nicira Networks with Martin Casado.
Nicira is now part of VMware, which means McKeown is three for three in having startups get acquired.
Now, he’s on his fourth try. With Barefoot Networks disclosing its plans this week (it’s developing a programmable switch chip and promoting the new P4 programming language), SDxCentral made the quick trip to Palo Alto. Barefoot’s office building is tucked onto a residential street just a few blocks from Stanford, where they’ve hung a shingle and put a sign on the door saying, “Come in: We’re OPEN and awesome.”
Read on to find out McKeown’s startup routine, his plans for P4, and his take on the state of OpenFlow.
You must really like startups.
McKeown: You know, there’s a funny thing here. On every single one of these companies, we’ve started by either giving away or assuming the technology would be given away.
The pattern is pretty much as follows. We work on something that we think is a little over the horizon, that’s going to matter in a few years. It’s got to be intellectually interesting, and I’ve got to be able to see the path from the research into improving the practice. Then I want to get involved in trying to improve the practice, then we try and give it away.
But it always has to be something which is counterintuitive, or, put another way, that the industry doesn’t quite like yet. That was the OpenFlow/SDN story. People thought we were nuts, and that’s kind of nice. If you have the courage of your convictions, then that actually makes it more interesting, because it means probably other people aren’t working on it.
That was exactly the case here. The conventional wisdom is that you can’t build programmable switches — really, really programmable-by-the-user switches — that have the same performance as fixed-function.
I like it when you find these conventional wisdoms. Sometimes the conventional wisdom is right. Sometimes you think, “I smell a rat here.”
Or, in this case, I think it’s just that the technology has changed. Moore’s Law makes the logic get smaller and smaller and smaller. So the difference between programmable and fixed has been slowly disappearing over time. It’s approaching negligible. “Negligible” is in the eye of the beholder, but we don’t think there’s any really meaningful difference in terms of the power, programming, or area between programmable and fixed any more.
So, that leads us to Barefoot, which makes a chip that’s programmable in the new P4 language. P4 sounds versatile for programming the forwarding plane. It makes OpenFlow sound almost quaint.
McKeown: [Smiling.] You said that, I didn’t.
Sure, but — what is going to happen to OpenFlow? Is it dead?
McKeown: Actually, I don’t think so. There are many applications where you want something which is very simple, maybe Ethernet and IPv4 and not much else. And if it happens to fit within the rigid confines of a fixed-function ASIC — well, OpenFlow was designed with fixed-function ASICs in mind.
So that’s not going to go away any time soon. Probably OpenFlow adoption will grow. However, you can have P4 telling Tofino [Barefoot’s upcoming chip] or any programmable chip to implement OpenFlow1.3 or whatever, and that’s the behavior it’ll take on, and it will interoperate with other devices.
There’s also a P4 front-end — it isn’t commercially available, but — a P4 front-end to Open vSwitch. Ben Pfaff at VMware, the Open vSwitch guy, had started talking about this about a year ago, at the first P4 conference. He was trying to figure out how to do this, and that’s kind of taken on a life of its own. There’s quite a bit written about it right now, and there’s a compiler he helped work on with a Ph.D. student of Jen Rexford’s at Princeton. That’s called Pisces. It’s not mainline upstreamed into Open vSwitch yet, but I assume it would be.
The benefit here is that you can start with one P4 program, and you can potentially have, from that one P4 program, Tofino switches, hypervisor switches, and others, that actually have been compiled down from that common behavior. They’ll do the same thing at different performance. Interoperability is kind of immediate. If you need to change the behavior, you just change the program and you recompile.