Blueprint: NFV Needs to Get Back to (Virtual) Reality

by Pravin Mirchandani, CMO, OneAccess

Calls for ‘plausible NFV’ amid a world of short-sighted proof-of-concepts

NFV has been voraciously hyped and with good reason; there is much to get excited about. The potential benefits to operators and communication service providers (CSPs) of enabling a virtualized and service oriented network environment are vast: increased network flexibility, additional security, reductions in network OPEX/CAPEX, dynamic capacity adaptation according to network needs and, perhaps most crucial of all, reduced time to market for new, revenue generating network services that can combat declining ARPUs.  NFV really could be the silver bullet that operators and CSPs have been looking for.

Breaking Vendor Lock-in with NFV

But there’s a storm brewing for 2015. So excited has the networking industry become that its NFV gaze has focused almost universally on the end-game: an idealized world in which new services are ‘turned up’ as part of a complete virtualized service chain. Perilously little has been said about how operators will migrate to utopia from the battlegrounds of today.

To date, the central migration message coming from the big five networking vendors has been: ‘Trust us. We’ll get you there.’ Needless to say operators, whose collective future may be determined by their success with NFV, are far from comforted by such assurances. Many have endured vendor lock-in for decades and, as a result, are rightly viewing this first wave of proprietary NFV proof-of-concepts (POCs) with a healthy dose of skepticism. Given a viable and open alternative, NFV could be their chance to break free.

It’s not only vendor lock-in that operators should fear. In their haste to establish NFV dominance, many vendors have NFV-ized their existing lines of routers and switches by installing x86 cards and are now conducting operator POCs via this generic computing environment. This is sledgehammer NFV in action; it may prove that the theory behind NFV is possible, but it is seriously lacking in plausibility when any kind of scaled migration path is considered.

Cash-strapped operators are highly unlikely to stomach the significant price premium required to install x86 cards across their entire CPE infrastructure. Moreover, x86 does not always deliver the optimized performance needed for the volume packet handling and SLA requirements for today’s network services, and in the operators’ last-mile network, there are far too many access link combinations required to enable the physical hardware to be done away with any time soon. ADSL, VDSL, S.HDSL, among others, plus cellular for radio access (frequently used for backup), together with SFP ports to support different fiber speeds and optical standards, are not readily available in an x86 platform, and could only be made so at a prohibitive cost.

Operators Should Focus on Virtual Network Functions (VNFs)

Most importantly, however, is the need for operators to focus on the services, or virtual network functions (VNFs), that they wish to deliver. Today (over their legacy infrastructures) operators are just starting to introduce bundles of managed network services to enterprise customers and are generating much needed revenues as a result. In cash terms, the most valuable of these services (VPN encryption, application performance management and WAN optimization, are good examples) rely on intelligence being present at the edge of the network, as well as in the core. Locating ‘dual-headed’ functions such as these on the router itself makes by far the most sense, but will be a huge technical challenge to achieve via an x86 card.

Operators may go to sleep dreaming of a fully functioning virtualized infrastructure, but the tough truth is that they’re not going to wake up to one any time soon. Theirs is a world where every cent of network investment must be pegged against immediate performance gains. The slim budgets which do exist are focused on network imperatives, like tackling legacy infrastructure obsolescence and reducing TCO.

For operators to commit to NFV beyond today’s POCs, they will need a staged, scalable and flexible migration strategy, which neither increases costs nor diverts budgets away from more immediate priorities. They also need managed migration. This means the ability to ‘activate’ VNFs only when they are ready to do so, otherwise the money simply won’t be spent. It’s high time that the vendor community understood this and adjusted their management of these customers accordingly.

With this in mind, OneAccess has spent the last three years preparing its product portfolio to address precisely these issues. While the big five have vied for influence in NFV, scrapping over ‘who leads the market’, OneAccess has been doing the heavy lifting. It has successfully separated the hardware-dependent forwarding plane from the ripe-for-virtualization control plane in its CPE routers and integrated the tail-f management framework; something that no other CPE vendor has accomplished.

As a result, it can now enable both the virtualized management of each router and support the continued delivery of today’s legacy services as well as support dual-headed functions as VNFs.  And finally, because OneAccess is an operator service-enablement specialist, its router platforms are purpose designed for this environment which, in the context of NFV, means they are open. Not only does this guarantee interoperability with each operator’s existing infrastructure, it also hands them a skeleton key which they can use to force the bigger vendors to follow suit.

As we move into 2015, fever-pitch excitement over all things NFV will subside and the serious business of service migration will take center stage. For the sake of the operators, vendors in the networking industry can’t get back to (virtual) reality soon enough.

About the Author 

Pravin Mirchandani is chief marketing officer and NFV service evangelist at OneAccess, a service provider specialist in the design, development and deployment of cost-effective managed network services on pCPE.

Mirchandani leads product strategy and is responsible for product management and corporate communications at OneAccess. His particular strength is seeing around the corner and anticipating the unexpected, of particular relevance when considering the changes surrounding SDN and NFV.

Got an idea for a Blueprint column?  We welcome your ideas on next gen network architecture.
See our guidelines.

2015 Advertising Info is here

Read More

Docker Releases Three Orchestration Services for Multi-Container Distributed Apps

Docker released alpha implementations of three orchestration services for multi-container distributed applications. The goal is to help developers and sysadmins to create and manage a new generation of portable distributed applications that are rapidly composed of discrete interoperable Docker containers that can scale to run in concert anywhere from the developer’s laptop to hundreds of hosts in the cloud.

The three new orchestration services are:

• Docker Machine: This service further expands the portability capabilities of distributed applications by providing the user the flexibility to provision any host with the Docker Engine, whether a laptop, a data center VM, or a cloud node. This saves a developer a significant amount of time in manual setup and custom scripting, resulting in faster iterations and compressing the development-to-deployment cycle.
• Docker Swarm: Docker Swarm is a Docker-native clustering service that works with the Docker Engines, provisioned by the new Docker Machine service, and creates a resource pool of the hosts on which the distributed applications run. By automatically scheduling container workloads and allocating resources, Docker Swarm provides users with high-performance and availability while eliminating inefficient and error-prone manual resource management.
• Docker Compose: This service provides developers with the ability to assemble applications from discrete, interoperable Docker containers completely independent of any underlying infrastructure, enabling distributed application stacks to be deployed anywhere and moved at any time. Defining a distributed application stack and its dependencies through a simple YAML configuration file converts what was an incredibly complex process into a simple one that can be executed in just a few keystrokes.
• Open APIs and Open Design Create Opportunity for Broad Ecosystem

“As we evolve from applications created from a small number of Docker containers on a handful of hosts to large, multi-Docker container applications spread across clusters and diverse infrastructures, it is important that users don’t lose the qualities that have made Docker so successful,” said Solomon Hykes, CTO and founder of Docker and the Chief Maintainer of the Docker open source project. “This includes native and open interfaces, the ability to be portable across all environments, and through a common UI the power to leverage a broad ecosystem of 18,000 tools and 60,000 Dockerized apps.”

Docker said its orchestration services are being backed by a partner ecosystem that includes Cisco, Digital Ocean, HP, IBM, Mesosphere, Microsoft and VMware.

http://blog.docker.com/2014/12/docker-announces-orchestration-for-multi-container-distributed-apps/

Read More

Cisco Hits Arista with Multiple Patent Lawsuit

Cisco filed a patent infringement lawsuit against Arista Networks, claiming that a dozen key switching features covered by 14 different U.S. patents held by Cisco were copied.

In a blog post, Mark Chandler, General Counsel at Cisco, writes that none of these features are incorporated in industry standards andy were patented by individuals who worked for Cisco and are now at Arista, or who at Cisco worked with executives who are now at Arista. Specifically, Cisco's complaint cites the following technologies that are incorporated by Arista in their entirety into Arista’s products.

• System Database (“SysDB”) (Arista uses Cisco’s networking device implementation covered by Cisco Patent No. 7,162,537)
• Zero-Touch Provisioning (“ZTP”) (Arista uses Cisco’s implementation covered by Cisco Patent No. 7,290,164)
• On Board Failure Logging (“OBFL”) (Arista uses Cisco’s implementation covered by Cisco Patent No.7,340,597)
• Control Plane Policing (“CoPP”) (Arista uses Cisco’s implementation covered by Cisco Patent No. 7,224,668)
• Spanning Tree Loop Guard(Arista uses Cisco’s implementations covered by Cisco Patent Nos. 7,460,492 & 7,061,875 )
• In-Service System Upgrades (“ISSU”) (Arista uses Cisco’s implementation described by Cisco Patent No. 8,356,296)
• Virtual Port Channels (“vPC”) (Arista uses Cisco’s implementation covered by Cisco Patent No 8,051,211)
• Access Control ListsImprovements (“ACL”) (Arista uses Cisco’s implementation covered by Cisco Patent Nos. 7,023,853 & 6,377,577)
• Private Virtual Local Area Networks (“Private VLANs”) (Arista uses Cisco’s implementation covered by Cisco Patent Nos. 6,741,592 & 7,200,145)
• Generic Command Interface (Arista uses Cisco’s implementation covered by Cisco Patent No. 7,047,526)
• CLI Command Data Translation (Arista uses Cisco’s implementation covered by Cisco Patent No. 7,953,886)

Furthermore, Chandler argues that "Arista promotes the theft of Cisco’s intellectual property as a key differentiator for Arista versus other Cisco competitors."

Mark Chandler's blog post is here:
http://blogs.cisco.com/news/protecting-innovation

A copy of the complaint is posted here:
http://www.slideshare.net/Cisco/cisco-patent-complaint-against-arista

Arista has not yet officially responded to the complaint but Jayshree Ullal, Arista’s chief executive, was quoted in the press expressing her disappointment in her former employer.

Read More