NFV PoCs: What Concepts Get Proved?

The NFV ISG released its first public documents in early October, but the most significant release was the details of its process for proof-of-concept demonstrations.  PoCs are one of the things that I’ve believed from the first would be essential in making NFV a reality.  Specifications don’t write software, and I think the IETF has actually proved that sometimes software should guide specifications and not the other way around.  Now, with a process in place, the ISG can start to look at elements of its approach in running form, not as an abstraction.  It could be a tremendous step forward for NFV, and also for SDN and the cloud.  The qualifier, as always, reflects the often-found gulf between possibilities and realization.

The most important concept to prove is the business case.  If you asked the service providers what they wanted from NFV a year ago, they’d have said “capex reduction”.  In fact they did say just that in their first Call for Action white paper.  The newest paper, just released, broadens that to more of a TCO quest by adding in a healthy desire to see operations efficiencies created.  There are also suggestions that improvements to the revenue side would be welcome, through the more agile response to service opportunities.

Where this intersects with the PoC process is that if the goals of the ISG are in fact moving toward TCO and service agility, then there is a specific need to address both these things in proofs of concept.  So I contend that ISG PoCs should address operational efficiencies and service agility.  Will they?  There are some barriers.

Barrier number one is that this sort of broad comprehensive stuff flies in the face of vendor opportunism.  First of all, vendors don’t want there to be any radical changes created by NFV or SDN or much of anything else if the word “saving” appears anywhere in the justification.  They reason that savings means spending less on their gear, which is likely true.  The second barrier is scope.  All of the benefits we’re talking about mandate comprehensive and systemic solutions, and the scope of the ISG has been drawn to insure that it doesn’t become the god-box of standards activities, responsible for everything in the world.  But if the problem is everything in the world (or a lot of it) how does NFV solve it?  And if they can’t, did they disconnect from their own benefit case?

So far, what we’ve been seeing in NFV demos and announcements has been focusing on a very small piece of this very large puzzle.  We can deploy VNFs—from a command line.  We can service chain, with static commands to connect things.  We can scale in and out, but not based on central operational/orchestration-based policies.  We can control networks, but not based on models of service that unify a deployment process and connect it with management.  Proving that 1) I have a ship, 2) I can sail it, and 3) I know what direction “west” is, doesn’t discover the New World.  We need something that links all the pieces into a voyage of discovery.

That’s what I think the PoCs have to do.  Yes we need to validate some of the specific points of the specifications, but more than that we need to understand how all of the variables that are being discussed will impact the business case for NFV.  We can’t do that if we don’t know how that business case is developed.  If the full service, from conception by an architect to management by a NOC expert or customer service rep, isn’t in the ISG scope then we still need to be sure not only that the way NFV works adds value to this overall process, but also just when and how that value is added.  Otherwise we’re building something that may not get us to where we need to be.  The PoCs, with no explicit limit in the range of things they can show, could provide the ISG with that critical business context.  They could prove the case for NFV no matter whether it’s capex, opex, revenue from more agile services, or a combination thereof.

Something constructive in the PoC sense might come out of a joint TMF/ISG meeting on management/operations that’s being held this week as the two bodies have meetings in the Bay Area.  The TMF also has PoC capability through its well-known and often-used Catalyst projects, and perhaps something that should happen in the joint discussions is the creation of policies that would advance systemic PoCs in one or both groups, and/or a dividing line to show where they belong.  It’s pretty hard to see how you can get reduced opex without some incremental “op”, but it’s also worthwhile to note that cloud-based, virtual services don’t work like the old services do.  Should we look at what the optimum operational framework for NFV and the cloud might be, then fit it to the TMF model, adapting the latter as needed?  That’s a viable approach, I think.

The TMF connection raises an interesting point, which is how the ISG will communicate its PoC findings to bodies like the TMF.  While a PoC could well move outside the ISG’s scope for what it does and shows, there appears to be some limitation on how results are fed back.  If you report against specific ISG specifications then you can’t report extra-ISG activities back, so they can’t pass through the liaison linkage to other bodies where those activities could be meaningful.  So do the ISG people then have to be members of all the other bodies?  I’m a TMF member but none of the other CloudNFV team are, for example, and I suspect a lot of the smaller companies in the ISG aren’t either.  I’d like to see the ISG encourage people to run PoCs that are outside the scope of the ISG where the extension works to cement the benefit case, and also then agree to provide liaison for these points.

The PoC process is critical to NFV, I think, perhaps even more critical than the specifications themselves.  Operators who need some of the NFV benefits now can build on PoC results for early trial activity because you can test an implementation in the lab or even a pilot service.  That means that those critical business cases and early tire-kicking can happen earlier, and that vendors can be forced by competitive pressure into doing more and doing it faster.  The PoCs could be the big win for the ISG, if they can get them going in the right direction and keep up the momentum.

Leave a Reply