Matt Kolon, CTO for APAC, Brocade, gives insights into Brocade’s SDN journey, OpenFlow strategy and customer expectations in an interview.
Do you think organisations lack the maturity to handle the SDN environment, as it is not enterprise-ready?
From the network perspective, SDN is just the initiation of virtualisation. SDN is one part of the situation. Organisations and, to a lesser degree, service providers are wary of moving the network into that space. They are unclear about what it means to virtualise the network. Network virtualisation will probably happen with network services first. Often there is talk of NFV and SDN together. NFV is likely where organisations and service providers concentrate first, because it is easier to do. They already know how to virtualise servers; therefore, they may as well virtualise some of the servers that provide network services. Now, using network protocols and network capabilities to control the flow of information through those virtualised services, and even to control the physical infrastructure is SDN. Its quite a cutting exercise to be able to say that ‘everything is SDN inside my network right now’
Vendor support and patchwork state of OpenFlow APIs is not considered ready for enterprise- wide implementation, but only for private cloud environments. Would you agree with that?
The progress of OpenFlow is not the same as the progress of SDN. OpenFlow is the first-born child of the SDN, and will always have a special place in the SDN story. Organisations have to ask what are they trying to do with their SDN control before they worry about the protocol. There are other protocols that are possible to have. Depending on what organisation wants to do, they may choose a different version of OpenFlow like NETCONF. There are also some vendor proprietary ones.
Brocade’s SDN strategy is based on OpenFlow and is very different from that of Cisco’s Application Centric Infrastructure. Can you please elaborate on this?
For us OpenFlow is a significant part of things, and even Cisco will talk about their OpenFlow support.
At Brocade, we want to make sure that the services side of it is correct. Virtualisation of network services is a more important story right now. The Vyatta software has a role to play in the SDN controller, but right now it is more valuable to customers providing VPN, firewall, application delivery. We are waiting for customers to know what they want, rather than imposing an architecture on them. We fully support OpenFlow, but that is not our primary emphasis.
What direction do customers want to take in SDN?
Customers are really interested in knowing how can they use virtualisation to buy less hardware like router, firewall, VPN box. We provide SDN capabilities in terms of services for multi-tenanted customersthat the service provider, a different department or an organisation has. For example, if a service provider wants to slice up a data centre and give different pieces to different customers, we have the ability to do that for them, with a network that automatically configures itself based on services that customers are running, through signals that come from their services. That is SDN, but OpenFlow is not used to do that right now. We have a controller project under way and we are involved in the development of OpenDaylight and SDN control. And, being able to do that, one does not require to be using OpenDaylight based controller all the time, there are lot of ways to do that.
The networking industry is becoming increasingly competitive? What direction is Brocade taking here?
We are a data centre company and it is our primary emphasis. The world is collapsing into smaller sets of larger data centres, and that is where we are focusing on. We are focused on succeeding on the software side and it presents no conflict for us. SDN in a data centre should be able to do what it is supposed to, which is connecting any-to-any connectivity between two services in the same box, two VMs or two PCs. If the physical architecture of a data centre is not capable of making a good path, that communication will be sub-optimal from reliability, latency perspective.
