Today I had the chance to sit down with Don Clark, Director of Business Development for NEC, to discuss NEC’s launch of the first commercially available OpenFlow compliant products, @ Interop Las Vegas 2011

Art Fewell: So, if you wouldn’t mind just starting off telling the audience what NEC is announcing at Interop this year. I read your press release, but if you could tell me what you’re announcing and what you’re excited about.

Don Clark: OK. Today, we’re announcing a new network architecture that leverages the OpenFlow protocol to provide real network virtualization. So, we are introducing a software controller and the first generally available OpenFlow-enabled switch.

AF: And so, when do you actually plan to launch the products?

DC: The products are generally available as of today.

AF: GA as of today, OK. Great. Good to know. Now would you compare what you are doing with OpenFlow to what Aruba does for wireless networks in managing a large number of access points in a single controller?

DC: The goal really is to separate where the data goes on the data plane, from the control plane, so that we can have a very fast past for the data. And we can have the network logic residing in the application stack, so that networking is managed just like any other application.

AF: One of the big impacts on this from the operational expenditures standpoint is managing the network. Have you done any analyses? And, what do you expect to be able to tell enterprises about the differences in operational costs in managing an OpenFlow controller versus managing, let’s say, in your data center if you have 50 switches, managing each one of them individually.

DC: Yeah, so what we found is that the amount of configuration for a large-scale employment can be quite significant. And one customer’s example, Genesis Hosting Solutions, they found that they were able to save 100 hours a month in network configuration by deploying programmable flow.

AF: The networking industry has been, outside the service provider environments, it’s really been this hop by hop management paradigm, where network administrators typically console in or Telnet/SSH in and manage each node on an individual basis. And I’ve been wondering and waiting for the time when we’d move towards a GUI and move towards a more a more streamlined and consolidated management system. It seems like OpenFlow is going to create that inflection point, so hopefully it will take off.

DC: Yeah, so ease of management is one side of it. The other side of it is, by having a central controller that can see the entire network, we can make better decisions about how data is passed across the network. So for instance, we have multiple policies for deciding where a flow is placed within the network, so that we can use all the capacitors in the network.

AF: Now, tell me about intelligent multi-path forwarding. Traditionally, routers and switches haven’t made very intelligent decisions about forwarding data packets. They’re based on really static information and not dynamic information. How does the intelligent multi-pathing work? And, how does the OpenFlow controller change the way that packets are forwarded through the network?

DC: OK. So, OpenFlow gives us the ability to collect statistics on all the network gear that’ s in the OpenFlow network, so that we can get a complete view of what’s going on in the network, a complete snapshot at any given time. And then, based on that, we can make decisions to optimize where flows are placed across the network. So, maybe shortest Hop is going to have more flows around it, so we want to route around that. But we aren’t constrained by any topology in order to make that decision.

AF: In your initial release, how intelligent is that routing decision as far as … today, for example, if I were to create a bundle, an aggregated link group, you’re typically hashing based on MAC addresses or IP addresses. So, what can happen is conversations, If you have top talkers that are conversing, they may take a single path when there are multiple paths available. In your initial implementation, how much information will the controller be able to take in real time to be able to adjust those flows for things like lower utilized links and so on?

DC: So, there’s two models for deciding, determining when the flow, how the flow is placed. One is proactively. If we push down a set of flows into the network for things that we would think would continue on. An example of that would be DDOS attack. Where you would always want to protect against that. That would be a static flow. The other would be reactively. That is, when a packet comes in, we determine that this is a new flow and then make a decision about how that flow gets placed across the network. So, that can be real time and we can scale that up.

AF: The networking world’s been waiting for a data center bridging to ratify and for standards like Trill and Shortest Path Bridging. This is a approach, as the forwarding devices themselves wouldn’t have the intelligence. So, how do you see OpenFlow as a disruptor to Trill and 802.1aq initiatives?

DC: So, this is a, we think a simpler alternative that customers consider when building their data center networks. Because it’s a centralized control, you don’t have to run the Legacy protocols. You don’t have to run these overlapping protocols. And because it’s centralized, you also have a single API to get up to your other systems, so that you can begin to manage the network the way you’re managing all the other IT infrastructures.

AF: Now, one of the hot topics in networking is convergence and SAN convergence. Topics like Fibre channel over Ethernet. A lot of the reason why Fibre Channel over Ethernet has been slow to roll out is because of the way that the packets have to be forwarded. So, they have to be ordered. They have to have guaranteed delivery and so on. And, I think data center bridging is one mechanism of accomplishing that. Its seems like OpenFlow, with its intelligence in the forwarding, may be able to take a different approach at Fibre Channel over Ethernet. Is NEC implementing anything for Fiber Channel over Ethernet?

DC: So, there is in the OpenFlow standard QS capabilities. We’re not announcing anything during this release. But it’s something we’re very interested in and something we will be following on subsequently.

AF: So, in this OpenFlow controller, we talked about how it will centralize management, to centralize management consolidate and streamline, a little bit about how it increases intelligence and how packets are forwarded. What other features, in your initial release specifically, are different from your traditional networking paradigms?

DC: One of the significant features that we’ve added to the programmable flow controller is multi-tenancy. Customers can build complete virtual networks with separate layer two, layer three, and layer four policies by tenant. So, customers can build these multi-tenant networks all on a shared physical infrastructure.

AF: And the multi-tenant functionality is available within a single controller?

DC: Yes.

AF: Very good. And anything that you see real significant other than that feature-wise?

DC: Well, we think it’s the network. We think that to be able to have a topology-free network will allow customers greater flexibility on how they deploy network equipment. So today, placing a firewall alert balancer often is location-dependent. But with OpenFlow and programmable flow architecture, customers can bend the virtual wires and make those connections independent of where the physical boxes reside. And with multi-path, they get the performance they need on the east-west route. So, we think that this is a simpler way to manage the infrastructure that the customers have in place.

AF: So, Cisco’s dominated the networking industry. I’m mostly focused on enterprise, and Cisco’s been roughly around 80% market share in networking. I think OpenFlow’s going to create an inflection point and some significant transitions could happen. Do you see this as an inflection point that can help you to compete against Cisco specifically or other market leaders?

DC: Yeah, we’re very excited about the OpenFlow release. We think that this provides more choice for customers and we think that this is going to be something that all customers are going to want to look at for datacenters. So there are lots of choices, and the goal really is for NEC customers to have more choice and flexibility in how they deploy their datacenters.

AF: So, NEC has a robust networking portfolio and I think in North America there’s just not a lot of awareness of your networking portfolio. From what I understand, Europe and other parts of the world, it’s a very well-known set of products. Is there a change in your marketing efforts for North America? Are you going to have an increased focus on becoming a big network player in North America enterprise?

DC: We began working with Stanford on OpenFlow three years ago because we saw the potential really to change the way networking is done. The way it’s bought and built. Based on that, 18 months ago we began developing products. We’ve had a return of people working on building these products. So we are now moving in the global stage with this global product. I think it’s appreciated and really adds a lot of value.

AF: As far as your go-to market model in North America, are you going to be announcing any new partnerships? What’s your approach to tackling accounts in North America?

DC: We will. Because OpenFlow is really a multi-vendor approach, we will be working very diligently with other platform vendors in order to show inter-operability. And then on the application stack, because we have a centralized API, new applications are going to be on top of that. So we’re going to be very aggressively organizing partners.

AF: As I understand it, and I’m not the guru on OpenFlow yet … I’m still working on it. But OpenFlow’s 1.1 standard is really about standardizing the interface between the hardware and the controller. Now what about from the controller, or the network operating system, northbound? You mentioned there’s APIs into the network operating system. Is there a standard right now for that? Is it a standards based API, or is it still something that NEC’s defined?

DC: Yeah, so this is our own definition API. Really it’s going to be based on the services that customers want. So the individual APIs will really depend on the different services that the controller vendors provide.

AF: As I understand it, with the NOX controller they’re working on trying to standardize the northbound API from the network operating system or the controller. Are you participating in that and when do you see that happening?

DC: So there are a lot of talks right now, but nothing really formed in terms of API. We are very involved in the work being done and we’ll continue to support standardization of the northbound API so we can create a new ecosystem around software that’s built on top of these OpenFlow networks. In our view, there is a great deal of value to be added to building on top of the network infrastructure. Customers don’t want to build their network state to manage that and want to have the capabilities to expose the API so they can control that.

AF: I think it’s important and I really think standardization’s important. One of the challenges with this is, as the industry moves more towards these cloud-based paradigms, is that your typical enterprise, they’re running VMware or another hypervisor based solution. That’s taking the access layer of the network, where policy is typically applied, and from what I’ve seen in practice , most enterprises outside of the very largest are not applying network policy anymore because the overhead of traditional methods. Today, when an organization is deploying new applications, what does that mean for the network administrator? It means I’ve got to go learn the ip addresses of all the hosts. I’ve got to learn the port numbers. I need to learn all this static information then apply a static policy. And in a dynamic environment, that model doesn’t fit. In rapid provisioning it doesn’t fit. So I’m kind of thinking the way it’s going to go is an application could dynamically deliver its network parameters to a controller through an API. Is that how you see things?

DC: Yeah, we strongly believe that we need to have a virtualized network interface so that the mapping is done virtually and the ability to change things is done at the physical layer without making changes to the virtual logic.

AF: I think one of the big reasons OpenFlow has taken hold, is, there’s been a lot of initiatives to open and standardized for years that have failed, and because I think we’re at a point now in application development where the application developers, particularly with cloud and mobility, are starting to realize our applications need to be able to talk to the network to get information about location and presence. I think one of the big differences with OpenFlow is who’s behind it … Google, Facebook, Yahoo!, Amazon. They’re no longer leaving the destiny of the network to the networking companies and I think that’s something that’s going to lead into the standardizing of these interfaces. Now in paradigms like Hadoop, the controller takes individual jobs and tries to forward it to the nearest node and it uses some very basic network information to find nodes that are close. Do you have any insight into some future applications as this northbound interface standardizes from the network operating system, what application possibilities do you think are going to be enabled through OpenFlow?

DC: Yeah, so flow-based networking provides us a much better context to understand what’s going on on the network. Today we do sampling of the individual devices then try to piece that story together. It’s difficult and it’s patchwork. We don’t get a full picture of what’s going on. With a flow-based network, we know end-to-end what’s going on on the network and can make better decisions about how workloads are placed and about potential problems on the network.

AF: And there’s another age-old problem that I’m hoping OpenFlow over time will be able to address, in that when there’s a problem with an application you have the application administrator, you have the network administrator, and they’re both pointing fingers at each other, right? It’s the application’s fault. It’s the network’s fault. I see if the application can talk to the network controller it will enable a new level of diagnostics in that we should be able to understand if an application performance problem has to do with the network or not. How do you see this being addressed?

DC: It’s a great point. Yeah. So we’ve talked a lot about integrating into the other systems so there’s much better visibility into what’s going on into the much larger picture.

AF: Network administrators have been married to Command Line, have been married to IOS and I’ve seen for a long time that that operating model is going to need to change. You’re dealing with managing a large number of distributed systems and you need to be able to streamline it. Another thing I’ve found is that when you manage by GUI, I had a situation recently where someone asked me, Hey, how do you configure VRRP on this device? And I went to go look at the command line and, traditionally, how I would have done that is something like ‘here are the 22 commands that you need to do’, and I realized when I went to the GUI, it was just one page with every single possible variable so as long as you know what you were doing, you didn’t have to go and look up the 22 different commands. How do you see the management platform, other than just, Hey, it’s a controller, hey it’s centralized, hey look there’s a GUI. I mean, do you have wizards, do you have other things coming that are going to help to simplify network provisioning?

DC: Yeah, so in our first generation, we can visualize flows both in a physical path and in the logical path so we can understand all the interconnections between them and we can do cause analysis very quickly. We also can integrate third party devices so we can see, at the end, what’s going on and what’s going through the network.

AF: Now what about Road Map? ‘Do you have any exciting things on the Road Map for this product that youre excited about?

DC: Yeah, so today, we’re announcing the 48 one G plus four port 10 G multilayer switch. You can expect that we will be filling out the switching product line coming up in the near future.

AF: Very good. Now we talked about the controller. Give me the quick and dirty on the hardware. So what are the specs on the hardware?

DC: OK, so this is a standard Intel based software. We sell it as a software and we can also sell it on the NEC hardware as appliance. And it runs on SLES 11 as a software appliance and runs in a cluster configuration.

AF: So relatively easy to deploy. Will it be available as a virtual machine?

DC: No. With the networking, we want to keep the network latency as low as possible for now in them running it directly.

AF: That leads into … one of the big challenges that people anticipate with OpenFlow is scaling because it needs to see every flow. When I hear that, I mean, I think there’s a lot of proof points that show scalability is not going to be a huge problem, at least for most customer environments. How are you tackling the problems of scaling and the amount of flows per second that your controller can handle in very large data center environments?

DC: Yeah, so we’ve done several deployments so far of both enterprise and public clouds and, so far, scaling has not been an issue.

AF: So do you have customer references that you’re announcing?

DC: Yes, so today we announce Genesis Hosting Solutions.

AF: OK.

DC: As a reference customer. And in Japan, Nippon Transportation.

AF: Very good.

(NEC PR): And, also, from a scaling perspective, you might mention Helios compared to what we offer today. Three thousand vs. one hundred sixty thousand.

DC: Yeah, so at GENI, as you probably know, this work has been going on in the research community for a couple years now and, at the last GENI conference, we demonstrated a prototype controller showing, managing three million flows.

AF: Oh, very good. Three million, I’ve been hearing numbers more along the lines of ten thousand, but three million is quite scalable. Now I think that pretty much does it for the questions I had. Is there anything else youd like to add?

DC: We’re very excited to be launching programmable flow. We think OpenFlow is going to be well demonstrated here at Interop. There’s going to be lots of different demonstrations, not only NEC but from IBM and some of the other vendors, really showing the power of what open networking can do and, with NEC’s virtualization technology, we think that this is going to be a real game changer for customers managing data sets.

AF: Awesome. Well, great, thank you very much. I appreciate your time.