Editor's Note: We are fortunate to have Wesley George of Time Warner Cable join us for this fifth installment of our NFV interview series. Be sure to check out our previous interviews in the series with Shazia Hasnie of MegaPath, Chris Donley of CableLabs, Eric Carmès of 6WIND, Margaret Chiosi of AT&T, and Christos Kolias of Orange. And we have more coming!

Wesley George has been working in IP networking for approximately 14 years, across operations, engineering and capacity planning, architecture, and design in large wired and wireless service provider networks. He has been an active participant in the IETF for 5 years, including serving as former co-chair of the IPv6 Renumbering (6renum) working group and current co-chair of the sunset4 working group, and co-chaired one of the IETF's first birds-of-a-feather (BoF) meetings on SDN. He also participates in CableLabs’ SDN working group. He currently works in the Network Technology Development group for Time Warner Cable, which is among the largest providers of video, high-speed data and voice services in the United States.

Many of the discussions we’ve seen so far around network functions virtualization (NFV) have been led by non-cable service providers. What are your thoughts on the relevance of NFV to MSOs?

George: Many services and functions are common among different service providers, so I think we share a lot of the same needs to be able to get better information out of the network, make intelligent decisions about how to manage the network based on that information and our business needs, and to continue providing more and better services at a lower cost. Many of the use cases for NFV are common between MSOs and other types of SPs, because MSOs build their networks in much the same way except for the access network technology and the methods to provide services like video over the last mile. MSOs do have some additional places where it may be possible to abstract some of the access-specific implementations (e.g. Docsis) so that the software and control plane live on standard hardware and we reduce the amount of hardware that is specific to our access implementations. CableLabs is working with its member MSOs to ensure that those use cases are well documented.

What, in your opinion, is the main difference between your business and, say, a Sprint, Verizon, or AT&T as it relates to SDN and NFV?

George: I think other than the chosen access technology, there are more similarities than differences. The main difference may be in the split between proprietary/closed single-vendor solutions and more open, standards-based or multivendor solutions for different service offerings. MSO networks are often very regional in nature, and this sometimes lends itself to a multivendor network that is actually multiple parallel, non-interoperating, single-vendor deployments (one region exclusively uses vendor A, another exclusively uses vendor B, etc.). This means that as MSOs have started centralizing engineering and management of their networks, and as they have moved to consistent national product offerings, they are ripe for better integration and consolidation of those proprietary solutions. But that it is often difficult to do, because they are closed, legacy, single-source systems. I think SDN may be able to help with that in some cases.

What’s exciting about NFV and SDN for you? What new services do you see as being enabled by these initiatives?

George: I think what’s exciting is the idea of adding intelligence between the network and the applications that ride on it by better integrating the two. For a long time now, the network and the applications that use it have operated largely agnostic of one another – the network doesn’t care what the bits it carries are, as long as they’re properly formed bits and they work properly in the performance envelope the network is designed to support. Similarly, the application doesn’t care what the network does or how it moves bits around, as long as it delivers enough of that application’s bits on the other end to allow it to function properly. This has led to some inefficiency in the way the network is used and the way that applications operate, because both have to assume worst-case scenarios or least common denominators, and this often reduces the quality of the experience for the end user.

There are a lot of opportunities to make existing applications better by allowing them to communicate with the network, either so that they make more intelligent choices about the way that they use it to provide their services, or so that the network can better communicate its abilities and performance envelope to the application, or even adapt itself to the application’s needs. Think of it as the difference between a road car that has to be designed to work in the widest possible variety of conditions and applications, and a race-prepped version of the same car that can be optimized for one very specific set of conditions and then further tweaked and adjusted so that it performs at the absolute peak of efficiency for the specific track that it will be using.

I’m also encouraged by the idea that SDN might enable improved feature velocity by making it easier to rapidly link together different service elements in new ways and streamline things like provisioning and troubleshooting a service even if it spans multiple devices from multiple vendors in multiple locations. The complexity that comes with implementing a robust and innovative service that spans lots of different individual sub-components is a drag on deployment and can be resource-intensive to support once deployed. SDN doesn’t eliminate that complexity, but any opportunity to reduce the amount of integration work required to glue those things together by standardizing how systems talk to the different elements and how much information is shared across them is a good thing, both for provisioning and for providing better tools to troubleshoot when things break.

What’s the biggest challenge to deploying NFV and SDN at an MSO?

George: Well, in a lot of ways SDN isn’t a new idea — it’s essentially a framework for automation to control and provision a network. So as a result, a lot of the challenges in implementing truly useful, intelligent automation that’s flexible enough to evolve with the needs of the business are still present with SDN — how you translate business rules and raw data into actions, how you ensure deterministic behavior, how you avoid brittleness, how you scale it up, how you build trust in the system, and how you use the smart people who currently operate the network and applications to sanity-check what the system is doing.

There’s a reason why the early adopters of SDN happen to be companies with an existing focus on automation and/or a lot of very highly skilled programmers. A lot of the things that SDN can do must first be built from fairly rudimentary building blocks, using some of the same methods that have been used to develop previous automation, so companies with a foundation of existing automation to build on have a head start on putting the new tools SDN provides into use.

For those that have less experience developing and using automation, some of deploying SDN is going to be waiting for off-the-shelf implementations that can meet your needs without requiring such a high level of investment in development. The attractive thing about SDN compared to existing automation tools is that SDN makes that automation somewhat easier in a multivendor environment by providing common APIs and levels of abstraction to streamline the process of getting data out of the network and implementing new functions to control it. As an operator, I can focus more of my development dollars and engineering resources on the business logic and integration with my existing systems, rather than building, testing, and maintaining multiple different vendor-specific and device-specific conduits to drive all of my different gear.

With NFV, I think that there are two big challenges: First, failure domain. Many of the concepts of SDN and NFV rely on centralization of services that are today fairly distributed. There’s a balance that must be struck between the improved efficiency of centralized control and combining functions in common hardware, and the potential increase in the number of customers or portion of the network that can be affected in the event of a failure. Adding the necessary robustness to reduce the risk of large-scale outages increases the complexity of any system you might implement.

Second, and more specific to MSOs, is the risk of niche applications. Since there are some things that are more specific to MSOs, the pool of vendor options available for MSO-specific implementations may be somewhat smaller, and the number of organizations testing those features may be smaller, leading to fewer opportunities to find and fix bugs before deployment.

What kind of impact will we see on both opex and capex for MSOs?

George: NFV has some obvious lessons we can learn from the virtualization efforts that have happened in IT, most notably that virtualization isn’t necessarily the right solution for all applications.

I think that there is potential for a reduction in both opex and capex based on the idea that NFV and SDN might allow us to deploy fewer physical boxes but offer the same or more features by virtualizing multiple services on common hardware. However, the potential for that cost savings is heavily dependent on the efficiency of the current solution and how well it can be adapted to a commodity hardware implementation. If you’re looking for something that has the highest possible density, throughput, or scale, there may not be a substitute for purpose-built hardware, or at least not a solution that’s cheaper. However, if you have systems that tend to be underutilized, there can be significant benefit to combining them.

I think that there’s also potential to lower opex by designing systems that are integrated more tightly with one another. Any initiative that reduces the amount of work necessary to tie systems and services together has potential benefits in terms of the time and resources of the folks in charge of the care and feeding of those systems. The less operators have to swivel-chair between multiple systems or be experts in multiple vendors’ OSSs and EMSs simultaneously, the better it is from an opex perspective. The real key is to make sure that you’re actually using SDN to reduce complexity instead of just shifting it from one platform to another.

What are key SDN and NFV-enabled applications and services that you are experimenting with or deploying, if any? Can you share any information about what you’ve learned so far?

George: We’re initially looking at SDN to try to streamline our data-center management and how we roll out new applications and features in that space. But in a lot of other areas, we’re mostly watching as the market and offerings mature, and participating in discussions with both vendors and industry groups to make sure that the use cases that we think are interesting are properly documented. I see the things that we do in the data center as a good foundation for additional work that expands into other services and parts of the network — extend what we do there to eventually enable some of that same flexibility in the core and edge of the network and for other services.

When do you expect Time Warner and other MSOs will actually benefit from SDN and NFV?

George: As I said, I think that there are a lot of folks waiting for robust off-the-shelf solutions to mature for different business and use cases, so that they can focus on integrating those pre-built solutions instead of building things completely from scratch. I also think that people are waiting to see what comes of the multiple different ecosystems and the industry partnerships that have sprung up around SDN and NFV, since we’ve already seen some consolidation, and there is probably still some time before all of the competing/overlapping solutions coalesce around a common framework. I think we’re just starting to get to the point where some SDN applications in the data center space are mature enough to deploy in the next 12 to 18 months, but NFV is a little further back on that deployment curve, maybe closer to two or three years.

Is that an optimistic timeframe? Or do you believe it’s realistic?

George: I think that’s a little on the conservative side, as it’s quite possible to deploy things today, but you need a much stronger commitment of resources to develop, test, and refine the implementation the more of an early adopter you are, because there’s more to invent and less to reuse. I think that timeline is realistic for TWC.