Dan Pitt serves as Executive Director of the Open Networking Foundation (ONF), a user-driven organization dedicated to the promotion and adoption of Software-Defined Networking (SDN) through open standards development. SevOne had the opportunity to sit down with Mr. Pitt and discuss the state of SDN and Network Function Virtualization (NFV). Below is an excerpt from our conversation.
We’re now approaching the end of 2014. What are you seeing in terms of SDN and OpenFlow adoption at this point?
There are two broad categories of SDN adopters. The bleeding edge adopters who have gone whole-hog and built hardware-based SDN. Then there’s everybody else who’s still learning to trust the technology. In the mass market, we’re seeing mostly overlay solutions. That’s because there haven’t been as many hop-by-hop, hardware switch-based products on the market that use OpenFlow as a standard protocol. But they’re starting to appear now. Going forward, I think we’re going to see a lot more underlay networks. Overlays were a great place to start, but they may not meet your fundamental needs.
The interesting thing about OpenFlow – it’s the southbound protocol between a separated control plane and forwarding plane. It’s like the drive shaft of your car. You won’t move if the engine and real wheels aren’t connected. But the drive shaft is not the exciting part of the car. OpenFlow is really necessary, but the exciting part of SDN is how you map it to your organizational objectives.
We think the debate about the southbound interface is going to slip away. Today it’s more about how you enable your customers to benefit from NFV and SDN.
What is the greatest challenge SDN presents to the Enterprise and Service Provider organizations?
The challenge of moving to SDN is not so much technical as it is organizational. It’s a different way of doing things. Not just forwarding and routing, but doing network operations, network management, network monitoring, and application development. It will involve a change in the roles, responsibilities, and talents of staff.
With Software Defined Networking, we can automate configuration and management of the network in very fine detail. So we don’t need as many people sitting at keyboards doing command line interface configurations of switches and routers every time we want to move something. There will be more people working on software and orchestration and the tying of applications and network behavior to business priorities.
Changes in staff can be challenging to people who have been doing the same thing for ten to twenty years and have built a career around certain certifications. As they see less need for that, they’re going to wonder, “What happens to my job?” One thing we’re doing at the Open Networking Foundation is developing some skills certification criteria to help create a market in training and skills upgrades.
There will be a change in the span of control of network administrators, similar to what we’re seeing with server administrators. To understand the impact on staff, we should be looking at what’s happening with server administrators. Right now, the span of control is close to 100 to 1 compared to network administrators, and that’s not sustainable.
What’s the best advice you can offer someone who’s considering adopting an SDN model?
Educate yourself as much as you can. Understand the technology and how it can benefit your company. There are opportunities throughout the food chain and people who can understand SDN well and offer really good advice on how to harvest that value will find themselves in good standing.
There’s going to be a long period of migration for most network operators that people in the trenches can help with. Network folks have an end-to-end view the application folks don’t always have. If they can bring that view into play and figure out how to do the orchestration, how to do the mapping, figure out what the routing should be to meet the requirements of certain application traffic – they will find their influence growing. We’re not going to be able to convert all of these network engineers into programmers, but it’s certainly going to be possible for them to find value in helping their organization adopt SDN.
I’m advising network operators to start small, but start soon. Start in a green field, get some experience, and then move into converting your existing network. That way you avoid having a bad surprise.
Be sure to ask the hard questions of your vendors. “What do you produce for SDN and what is open versus proprietary?” Of course, at the ONF we’re advocates of the open standards approach to SDN, away from the proprietary approach that has kept a lot of people locked into single vendor solutions.
Then ask the hard questions of yourself: “How much am I committed to having software expertise in my company? How much am I willing to give up in terms of vendor flexibility in order to have someone deliver me a turnkey solution? What’s my appetite for risk?” When we talk about SDN, we typically focus on the “N,” but there’s a lot of “S” that needs to be written. That’s going to come from a variety of sources.
How do network and IT professionals separate vendor hype from reality?
This is not a new question. This has been going on for decades. With SDN, we’re hearing such a variety of things. Everyone is saluting the SDN flag. They’re slapping SDN labels on products that have been around for ten years. The only way to wade through that is to educate yourself.
At the ONF, we donate a large portion of our resources to market education – webinars, tutorials, workshops at major conferences, blog posts, conversations with the press and analysts – to try to help people understand what SDN is, the benefits, and how we get from here to there. We try to be the unbiased voice of the SDN movement.
What do you see as the role of performance monitoring in the SDN model?
Performance monitoring has the potential to play a large, unheralded role in the achievements of SDN. What we have is a tool for converting real-time network conditions into a feedback loop where we can continually tweak the behavior of the network to align with organizational objectives. To do that, the monitoring platform has to measure and then convey recommendations to the control software. In the OpenFlow protocol, we specify counters. But that doesn’t go far enough. So I’d like to see a larger role played by the performance monitoring platform with a goal in mind of making sure what we measure is used to improve how the network fulfils the objectives the organization has set for it.
SevOne agrees with Mr. Pitt’s take on the role of performance monitoring in SDN. The controller should subscribe to the performance monitoring platform to receive informed recommendations. To do so, the performance monitoring platform must be able to:
- Understand agile and rapidly changing topologies.
- Access models and performance metrics from the controller.
- Ingest massive volumes of performance metrics with speed at scale.
- Provide real-time analytics as part of a continuous feedback loop.
Today, organizations use performance monitoring to prove infrastructure performance and prevent business disruption. But performance monitoring will add further value in the SDN model. It will make recommendations on how to maximize resource utilization.
It’s not unreasonable to think that one day the performance monitoring platform may act as an internal auction site for allocating resources based on business priorities.