What a Virtual Network Looks Like: PlanningWhat a Virtual Network Looks Like: Planning

Virtual networks make things easier for the user at the planning level... at least in theory.

Network services don't spring up unbidden from the earth but rather they're coerced out of infrastructure in response to business and consumer opportunities. Every operations and management paradigm ever proposed for networking includes an explicit planning dimension to get the service-to-infrastructure and service-to-user relationships right. On the surface, virtualization would seem to help planning by reducing inertia, but don't you then have to plan for virtualization? How the planning difficulties and improvements balance out has a lot to do with how rapidly we can expect virtualization to evolve.

What virtual networks do is disconnect "service" from "network" in at least some sense. They can do this by laying a new protocol layer on top of existing layers (the Nicira/VMware or software-defined WAN model), or by disconnecting traffic forwarding and network connectivity from legacy adaptive protocols (OpenFlow SDN and white-box switches). Thus released, virtual networks can evolve quickly to meet service needs even if infrastructure changes are slowed because operators need to write down their gear over a protracted period of time.

The general goal of virtual networks is to reduce network planning burdens on the buyer of network services. If provisioning a service or making a change takes four to six weeks, enterprises have to plan far ahead of their business needs. They also tend to try to fit their needs into long-term contracts, and some operators think this encourages them to skimp a bit. Operators obviously hope that by making services more extemporaneous, users would consume more of them.

About a third of enterprises I've talked with say their consumption of network services is at least partially constrained because they have to establish a steady-state service relationship that works for their traffic, whatever the periodic variations might be. They say, too, that they might well buy more service and spend more money if they could adapt more dynamically to their traffic needs. Another third says they could see themselves adding both capacity and service features on demand for specific peak applications. Nearly all say they'd love not to have to forecast needs through capacity planning as they do now. The biggest planning impact of virtual networking might thus be the fact that it reduces planning for buyers.

Arguably it does that by potentially increasing the planning burden on the service providers. Software-defined networks (SDN) and network functions virtualization (NFV) both focus on service agility and self-service provisioning and customer care. These features would allow buyers to quickly try out service levels and change them, for the long term or even on demand, if they needed more or less capacity. Even service features for things like security could be added as needed. Agility alone makes infrastructure planning harder for the provider, and changes in technology and even the services themselves make it worse.

The planning challenges for operators divide into market targeting, service feature planning, and service requirements planning. Who do you sell your service to? Do you know where these prospects are and what to say to them? Do you even have any in your sales territory? What features would make your service attractive to users and profitable to you as the provider? How do those features get created with your virtual technology? If operators can't address these questions, then the idea of generating new revenue from virtual services has no credibility.

Most of the "service agility/new services/new revenue" proponents ignore the question of just who the prospects for all this new stuff might be and how those prospects would be convinced to buy. Today's business services are sold largely to connect static sites like branch offices, and so you have to convince buyers to start thinking of services in a new way in the virtual world. Until they do, you can't easily convert prospects to customers.

The feature planning issue is critically related to the market targeting because different market segments would value different features, and every feature has its own deployment and management requirements. These set the cost as much as customer perceptions of value set revenue. Operators have to plan to optimize the net profit per user and also the number of users that would be engaged.

The biggest challenge, perhaps, is how virtual networks, now romping wild and free over the marketplace, can harmonize with the long-lived infrastructure. Virtualization doesn't eliminate the challenge of "speed matching" the service and infrastructure worlds, it just pushes it into a virtualization layer.

Only high-margin services can afford the cost of explicit resource management, even today. With virtual-network services it is worse, because you have to constantly figure out on what real resources the virtual services depend. The general view among operators is that you have to plan your infrastructure based on your service goals (capacity planning) and then manage to insure that you're not selling more than for what you planned. As long as you're not, then if your infrastructure conforms to your capacity plan everything should be OK.

Virtual networks make things easier for the user at the planning level, by making it possible to change services on demand, but they don't eliminate budgeting and they demand more from network operators in capacity planning and service order admission control. We don't know, at this early stage, how the new balance of effort and risk will play in the markets, but we're certainly going to find out.

Read related posts:

Follow Tom Nolle on Google+!
Tom Nolle on Google+