SS: Let's focus on NFV. It's supposed to be based on open standards. Why do you need an ecosystem?
BM: It's open, but it's not integrated. It's open, but it's not bomb tested. It's open, but it hasn't been collaboratively run through the gauntlet to make it work. And I think you need to have a set of standards, yes; but you also have to have people working with one another, to make sure that the software's optimized, the hardware's optimized, and to find the defects that only come up when you're at line speeds.
You also have a clash with the IT ecosystem and embedded ecosystem. The IT guys are from the three nines of reliability school, and they don't know what they don't know. And we're over here saying, "Well, we know, because we've actually done it." So having the ability to work really closely together to learn from each group is really key.
SS: There are about 35 organizations or more now, who claim to be creating standards and specifications for NFV. Feedback from service providers is that's too many [see The New IP Agency Is Born at BTE]. And I suspect that when this stuff gets onto networks -- production networks -- there will be interoperability issues as well. Is that another benefit of having this ecosystem approach, so you can ring fence things and say, "Hey, well, at least the 20 of us know that our stuff works together"?
BM: We adhere to the standards, but we're working at a kind of collaborative or interoperable methodology. And you're exactly right. We're caught up in two things: one is how things are open sourced, or the open standards piece. And people think that just because they throw open software to an open standards board, it's going to work. No. It just doesn't work.
The second issue is that in the IT space you have hundreds of thousands of designers that can go and take a piece of code and make it work pretty quickly. In NFV, the designers that understand hitless patching, understand low latency, understand six nines; there's a lot less of them. And what they know is also the secret sauce of some of the [equipment manufacturers], so will they really want to share it right away?
So there's a different methodology that has to happen to make sure that this stuff works; to harden it, to put it through some sort of a test so you can have the Good Housekeeping stamp of approval, so the service providers can feel confident it's going to work.
SS: I'm hearing the pragmatist coming through in your viewpoint here, and if I was a service provider that's exactly what I would want to hear. At the other extreme, everybody is claiming to support virtualization, so how do you stand out in a market where there is so much noise?
BM: You put your money where your mouth is. We hired the dream team of designers from equipment manufacturers and service providers; a group that really understands the problems. They worked with the service providers -- the ATTs, the Telefónicas, the Verizons of the world, right?
The other piece in understanding the business process. You go to executives at the service providers, and you say, "What do you really want," they say, "Hey, we want things that work. We really want you to come in here and prove to us that you've got performance, you've got reliability, and you can solve problems that we're looking at."
Last but not least, we actually go and do some real PoCs [proofs of concept] at line speed, and wow the pants off of them. We're in 15 proof of concepts around the world with service providers; won seven of them already.
SS: Nice. What's the most common application in those PoCs?
BM: A lot of C-RAN.
Next page: Cracking IoT