Marc Randall is a networking industry veteran. In the 1990s he ran Cisco Systems' core routing business, then he served as CEO of Force10 Networks from 2000 to 2008. In January he joined Avaya as senior vice president and general manager of the company's data networking business, taking on the battle of making Avaya a networking contender that enterprises can take seriously.
In this Q&A with SearchNetworking.com, Randall talks about why Avaya is a big believer in
Shortest Path Bridging as the basis for its next-generation network fabric, and he explains how that fits into the move toward software-defined networking.
Do you think Avaya has established a brand in the data-networking market? How will you build that up?
Marc Randall: There are two focus areas or dimensions of how we build relevance again in the data networking space. We talk a lot about a cross-company and cross-partner strategy, linking full Avaya solutions together as we go to market. That [will mean] linking unified communications, contact center, VOIP, as well as networking in a complete seamless solution set. And that motion would be heavily driven through our voice partners.
The second dimension of building relevance in the networking space is having a direct sales force that goes out and bids on networking infrastructure deals. We've set up the sales organization to have those two dimensions of focus. The direct sales team that we have been growing sells far more into data center, whether top-of-rack or fabric solution. They sell more into the core and aggregation of the enterprises space. The value-added resellers focus on the edges of the network. They focus on the access edge, the remote office, the branch and top-of-rack for aggregating servers running Avaya Aura.
Avaya has talked a lot about the Virtual Enterprise Network Architecture (VENA), which is based on Shortest Path Bridging, for use in the data center and now the campus LAN. How do you differentiate VENA from other architectures like Cisco's FabricPath and Brocade's VCS?
Randall: Customers have asked me the same question. There is a big difference between proprietary implementations versus standardized implementations. If you go with Qfabric as an example, you really tie yourself into a Juniper-specific architecture.
Or you could go to FabricPath, which is a Cisco proprietary architecture [based on Transparent Interconnections of Lots of Links (TRILL)]. Or you could go straight to TRILL. Even though we say it's a standards-based architecture, there are so many different variations of TRILL. If you look at VENA, with Shortest Path Bridging, it is a standard. It's [based on] MAC-in-MAC [IEEE 802.1ah-2008 Provider Backbone Bridges]. Its whole goal was to simplify the operation of the core. It really makes the core look like a fabric. FabricPath, TRILL and Qfabric still leave a lot of complexity in the core of the network. Shortest Path Bridging really makes the core high performance, very resilient and very static. With the VENA architecture and Shortest Path Bridging, you don't have to learn MAC addresses. The core doesn't have to have this tremendous amount of memory to store hundreds of thousands of MAC addresses and routing tables. It allows you to move ... your configuration and complexity to a small portion of the edge. Whereas in this other [TRILL] model, if you make any change to the edge -- add another router or switch or end user -- then you have to have a core that can understand the segment IDs, the Mac addresses, the IS-IS routing table. You add complexity, so you still have to manage edge and core.
With VENA and Shortest Path Bridging, you can add as many more devices as you want to the network edge and never touch the core fabric. Our customers say, 'Yes, I want to be able to put a core into the network and not touch it for years, and have it be connected and be resilient.' That's the demarcation between the proprietary Qfabric, FabricPath -- or any number of TRILL implementations versus Shortest Path Bridging. I think the market will eventually go to Shortest Path Bridging. The customers will push us there.
Is it the proprietary nature of Cisco and Brocade's implementation of TRILL technology that requires customers to touch the core every time you add something to the edge?
Randall: It's the nature of both TRILL itself and the basic implementations that various companies put out. I think it's become clear that the edge has become very complicated, whether it's the edge of the data center or the edge to a user. You want to put infrastructure in the core that you do not have to reconfigure and that has high resiliency. That's what Shortest Path Bridging and the VENA architecture gives you versus going to a Brocade, Cisco, Juniper, Arista or whatever solution.
Talk about the value VENA and Shortest Path Bridging offers in the campus and how you plan to expand VENA in your campus-networking portfolio.
Randall: When you think about VENA and a static fabric, your mind tends to think about a data-center solution. We're finding as we look at the technology and go to market that we see a similar and maybe even a larger benefit in the enterprise campus. It gives you the opportunity to do two things. It allows you to collapse that three-tiered architecture that has been in the campus for a long time -- access, aggregation and core. With VENA you can collapse the aggregation and the core together into one architecture.
More on Shortest Path Bridging and multipathing protocols
Will TRILL replace spanning tree in data-center networks?
Wading through the FCoE and data-center fabric hype
Data-center fabric overview: A vendor comparison
Second, you can use that same concept of top-of-rack switches connected into a data center, and you can [apply that] to a secure router or any number of stackable [switches] in a wiring closet that is physically connected up to a VENA-enabled core. That will give you the benefits of having virtualized domains in the enterprise as you would in data center, as well as easy deployment and configuration at the edge through policy management.
Over time you'll see in an enterprise or cloud where the fabric architecture of the data center will extend all way out to the edge of the enterprise. That fabric will be very static, but very high performance. The features, configuration and simplicity level will be a significant return on investment for IT departments.
Last year Avaya introduced a component of VENA, the Virtualization Provisioning Service (VPS), a virtual machine lifecycle management feature that was VMware-ready. How have your customers responded to VPS, and do you have plans to make this available on other hypervisors soon?
Randall: The reception from customers on the ability to interconnect with vCenter and be able to handle changes within compute state and have those propagate through the network has been extremely positive. The next generation of work that needs to be done in the data center is the visualization of the network. Our competitors have really been struggling with how much control they want to move outside of their control plane. We think in the opposite approach. If the network is subservient to the application, then it has to be subservient and in concert with the hypervisors, because they will be the ones moving the application to other resources. It's been well received. As far as plans to move to other hypervisors, that's in the works. I don’t want get into roadmaps right now. But we are looking at same concept of intercepting with other hypervisors.
VENA is one option for network virtualization, but there is increasing excitement around software-defined networking via OpenFlow and solutions introduced by vendors like NEC, Big Switch Networks and Nicira Networks. What is Avaya's view of this emerging technology, and how does VENA fit in?
Randall: VENA does not run counter to a software-defined network. As we move forward and you have multiple elements that are in a network and multiple applications, software-defined networking applications fit in very nicely to be able to manage the multiple elements of your data center as one virtual or multiple virtual architectures and networks. I'm not sure where OpenFlow is going. We're tracking that quite closely. But I believe there will be a move toward scaled-out control planes and those scaled-out control planes will be more open in nature to applications and more open in nature to device control planes.
That is definitely a direction we are very interested in, and we are watching it closely. We're doing things internally that align around a scaled-out control plane. Whether it's a Big Switch or Nicira, the jury is still out. It's still a very competitive market. But I do believe that in the networking space, getting tighter linkage from the control plane of your network to applications like Hadoop or applications like Avaya Aura is a direction that market is going in, and I think it brings value.
Let us know what you think about the story; email: Shamus McGillicuddy, News Director