NSV Working Group Update with Credit Suisse’s Vesko Pehlivanov


Anyone who would like to reimagine their networks should listen to Vesko Pehlivanov. The service architect of security at Credit Suisse is the chairman of the Network Service Virtualization (NSV) working group here at ONUG. NSV describes how to virtualize firewalls, load balancers, and other network services. There are already approaches for OpenStack, Docker, VMware, and others, but no one solution that cuts cross all environments. How will that help your organization? We’ll let Vesko explain.

Vesko picture

Vesko Pehlivanov, Credit Suisse


Tell us about the working group. What are its goals, accomplishments and status?

The goal of the working group is to define a common set of functional solution requirements for network service virtualization. We wanted to provide a general guideline for enterprise IT to compare vendor solutions and develop a formal Request for Information (RFI) specifications, and for IT vendors to develop and align product requirements. We were hoping that by defining a common set of solution requirements we can drive the IT vendor community to deliver open and interoperable network services in order to provide IT end users maximum choice and flexibility. We’ve created a common architecture framework, covering the majority of enterprise deployment requirements for network service virtualization solutions.

What happened that made this initiative important to you and prompted you to get involved?

For me, the cost and complexity of managing and life-cycling a huge number of Layer 4-7 network appliances from different vendors with different management tools is a pain. There is also a lack of flexibility which inhibits our ability to meet requirements from developers, such as giving them programmatic control over their own load balancing instances or visibility into how their application is being handled.

As enterprises build fully automated private clouds to deploy infrastructure, they cannot expect developers to submit a request to an Ops team to make a change in the configuration of a load balancer that their app uses. Developers need to be able to do that programmatically in an agile manner and still be protected from bringing the whole load balancer down. Otherwise, the wait time impact their ability to deliver functionality rapidly.

What is the value to the user?

NSV Working Group seeks to leverage the flexibility and low costs of commodity servers to establish a scale out pooling of virtual and physical appliances, which can be put to use servicing applications. As each Layer 4-7 function is virtualized in software, it provides the following benefits:

  • Lower CAPEX costs (approximately 30 percent less);
  • Rapid service provisioning and ability to deploy Layer 4-7 services that follow specific virtualized sets of applications;
  • Reduced risk through service distribution;
  • Eased management and reduced operational costs through ability to be centrally managed by generalized IT operational teams;
  • Consistent policies across different Layer 4-7 services and across data center, campus and WAN networks;
  • Programmatic control and ability to offer network functions as a service to developers.

What output can we expect?

We’ve already created an architecture framework and a set of requirements. We’ve defined the Top 10 requirements most important to enterprise users and validated the ability of several vendor solutions to meet these requirements. As a next step we’re partnering with Open NFV (OPNFV) to leverage as an open source reference platform that aligns with the NSV architecture framework. We’re also discussing an interoperability demo where a common orchestration platform will chain together network services from several different vendors that will be able to co-exist within the same enterprise environment and be driven by the same set of policies provision by the orchestration platform.


Author's Bio

Guest Author