Month: May 2014

We always hear about the progress of new technologies, largely because “news” means “novelty” and there’s therefore little interest in how people are doing the same tired stuff they did yesterday.  Unfortunately this tends to set up what I’ve called (yes, irreverently with respect to our friends in the Fourth Estate) a “Bulls**t bidding war” where the guy who lies in the most entertaining way wins.  In the SDN and NFV space, one impact of this has been to create the impression that both technologies are rushing toward universal deployment.  That’s not true.

Since the dawn of network investment, both operators and enterprises have looked at new technologies in a generally systematic way (operators, not surprisingly, do it better than enterprises, and big enterprises better than SMBs).  If you survey network buyers, as we’ve done for 25 years or more now, you find that the buyer will have three distinct “phases” of technology evolution.  The real progress a technology is making toward deployment is related to which phase it’s in.

When a technology is in the validation of operations practices phase, the last phase in our trio, the buyer is in the process of optimizing the way the technology will be used to both sustain expected network services and optimize the business case that’s driven things this far.  Most often this phase is marked by a field trial where the technology is used in a live network, with live services and users.  Field trials are expensive, risky, and aren’t undertaken until you’re pretty sure you have the right answer, so when something reaches this stage it’s pretty much a matter of dotting and crossing, as they say.

What precedes this phase is the validation of the business case phase.  Here the goal is to determine if a technology option can actually create the combination of costs and benefits needed to justify its deployment.  There was, at one time, a very solid link between this phase and the concept of a request for proposal (RFP) because one obvious step in building the business case is establishing the cost.  Lab trials may also be conducted here, aimed at cementing the properties of the technology and providing a better estimate of operations impacts.

The first phase in the evolution is the technology assessment phase.  This phase is where a technology is given a kind of preliminary sniff test.  Where could it be applied?  How much of current costs could be impacted?  What practices would have to be changed?  Requests for information (RFIs) are typically issued in this phase, and some buyers will conduct lab trials here.

If you ask buyers where they are with respect to technologies like SDN and NFV, most put themselves in the technology assessment or validation-of-business-case phases.  On that basis alone, we’d have to say that predictions about SDN and NFV sweeping the universe are a bit premature (the same is true for the cloud, as I’ve noted in earlier blogs).  But with SDN and NFV we have another wrinkle, which is that of scope.

Say I spend a half-billion per year on capex.  Say I have an SDN project that will enter the third and most important phase in 2014.  I’d then have a half-billion in spending on the line, right?  Nope.  My application of SDN or NFV or anything else is likely limited to a part of my network, a part of my capital budget.  In today’s world in particular, network buyers are unlikely to propose a network transformation project that fork-lifts everything, and they certainly won’t run a deployment that way.  Field trials end up growing to cover more “fields”, usually by targeting the places where the best benefit case can be made.  At some point (Verizon’s FiOS comes to mind) you reach a point where additional investment in the new (FTTH in this case) can’t be justified, so you quit.  The point is that in most cases, buyers know darn well that they aren’t going to shift entirely to a new technology.  Even getting our hypothetical project into deployment would likely impact only a fraction of our half-billion in capex.

How big a fraction?  It depends on who’s doing the project, but the average estimate of the portion of network budget likely to be impacted by SDN or NFV deployment between now and 2018 is just a titch under 20%.  And note that “impacted” doesn’t mean “new-SDN/NFV-kid-gets-20%-of-my-budget” either.  It just means that purchasing decisions impacted by the new technology tally to that level.

Suppose we say, “How do I get more, faster?” which is clearly the question vendors have to address.  The buyers themselves have the answer.  You need to do two things:  give me a clear business case for the “ultimate” deployment you propose and give me specific steps to manage risks and costs as I move toward that deployment.

What both enterprises and operators tell us is that vendors tend to believe that technology is self-justifying.  You need the next big thing, you need to carry more traffic, and so forth.  Because vendors don’t provide much assistance in building a business case, projects tend to hang up in the second phase because it’s not clear how to get them paid for.

We see this particularly with NFV.  Today, nearly all the network operators put themselves in the first of the three phases of the NFV project, and nearly all those who are beyond that (in the second phase) are running trials that have a very limited functional scope.  Service chaining to shift CPE to virtual CPE is the largest trial target, and operators tell us that this is because they think it’s an easy one to assess.  Most operators don’t believe the application would amount to even 20% of their capital budget (the current expectations average only 11%) and most who have expectations say they think they’re likely overestimating capital impact rather than underestimating it.

The big challenge with both SDN and NFV, if you explore the current phase of buyer activity, is that there is a significant disconnect between the scope of deployment needed to make the business case and the scope of the expected near-term deployment.  This has come about for both SDN and NFV because the simplistic idea that either technology would be justified by reductions in capex have not proved out in live projects.  You need other benefits, and in the case of NFV operators figured that out before the specs were even finalized.  Today everyone touts service agility/business agility and operations efficiency as their goals, but the solutions out there are point solutions that because of their narrow scope can’t create radical changes in the broader network practices.  That means no difference in either agility or operations efficiency, and no large-scale business case.

We’re focusing too much on the stairway and not enough on what’s at the top.  Fixing that is going to be a challenge for vendors, because they want instant gratification.  Those who get too focused on that are going to end up un-gratified.

Just after yesterday’s Overture Networks announcement on an NFV platform, we now hear from Light Reading that Edgewater Networks has launched a project to develop an SDN/NFV position.  Today, we also had a revised submission of the CloudNFV Proof-of-Concept to the ETSI NFV ISG.  Alcatel-Lucent has been promoting its SDN and NFV position on the anniversary of its Nuage acquisition, and I’m told by operators that they are getting (as one described it) a “new round of NFV promotion” from vendors.  NFV has been hype-hot for some time, but might it be getting hot for real now, and if so, why?

I’ve noted for some time that the great majority of “NFV” solutions we see these days are really simply pieces of a foundation on which NFV might run, or things that might run on it.  Having a server doesn’t make you a cloud provider, so I think it’s fair to say that what we have listened to for the most part has been exploiting NFV interest rather than developing NFV capability.  The major network vendors have not really promoted a full and open NFV approach, according to the operators I’ve surveyed (some now tell me that vendors are shifting a bit to be more open, though).  The point here is that operators need NFV to be something very specific because they need it to present specific benefits and play a specific role.  There’s a lot of open ground in real NFV implementation, which could become high ground in a tactical sense if NFV really takes off.

NFV infrastructure is where a lot of the NFV announcement focus has been, but at the basic level NFV infrastructure isn’t a big issue.  It’s mandatory that any complete NFV solution be able to deploy and operationalize virtual functions on any commercially available server/cloud platform, and also accommodate special platforms like edge devices.  The OpenStack model, which uses plugins for deployment of machine images on VMs and also for the control of network resources, could be adapted to accommodate much of the hardware out there.  If you add in some generic mechanism for handling legacy elements of the network, you have pretty much what you need.

The Virtual Network Functions (VNFs) themselves are a bigger issue.  The most logical source of a VNF is the pool of open-source network components out there, which some estimate to number in the thousands, perhaps as many as ten thousand.  To leverage everything available, you have to be able to on-board VNFs without modification, which means that management and orchestration features of NFV have to be applied to VNFs without special APIs.  Overture made a point of stating that as one of their fundamental goals (it was also a fundamental goal for CloudNFV) so there may now be some direct pressure on “NFV vendors” to address whether their approach is truly VNF-accommodating.

There’s a kind of an interesting blur-point here that we can now note.  If there is “VNF-accommodating” capability built into an NFV implementation, then it has to be accommodated from an architecture perspective.  Where is the stuff that manages the VNFs living, software-wise?  Keep the question in mind.

MANO, or management and orchestration, is the big black hole of NFV.  Everybody wants to talk “orchestration” but what most talk about when they mention their capabilities is one or both of two things we’ve had all along.  Thing One is OpenStack’s Nova and Neutron deployment and connection APIs.  These are great tools but they’re an example of structural orchestration because they are designed to provide for multi-vendor implementation of a set of cloud service models.  They don’t provide generalized network configuration control and they don’t integrate management.  Thing Two is “service chaining”, which for most means simple stitching of paths between VNFs using SDN or even a legacy technology.  Yes, you have to connect virtual functions into cooperative communities to use them, but that’s not NFV in and of itself because you can’t accommodate management nor generalize service creation by stitching.  What we need to make NFV into NFV is functional orchestration.

Functional orchestration lets us create services (retail services) by assembling predefined components, all of which are at their roots the structurally orchestrated service models created by the NFV Infrastructure.  Functional orchestration includes the ability to co-compose deployment topologies and management derivations so you can manage the functional assemblies (including “virtual devices” like a virtual branch access device) from the user or customer-service side, and then manage real assigned resources from the network operations side.

Overture’s announcement included a service modeling approach that allowed for the creation of functional assemblies, even though Overture doesn’t position themselves as the high-level orchestrator.  It would be fairly easy for them to integrate this with OSS/BSS, but clearly they see themselves as being more an enhanced structural orchestrator than a functional orchestrator.  That means that there’s an opening for functional orchestration that startups or incumbents could fill.  Thus, we can say that the boundary between “functional” and “structural” orchestration is somewhat elastic.  You could push the boundary higher and delegate more orchestration to “infrastructure managers” or you could push the boundary lower and let operations-linked tools dive downward right to the edge of the real network control and hosting APIs.  Or anything in between.  That’s the kind of open range that new market entrants love.

There’s also a question of whether NFV orchestration has its own set of APIs, making it something like a PaaS platform.  We can’t make it a requirement for VNFs to use these APIs without ruining our open-VNF mandate, but we could allow optimization, analytics, and other stuff to be openly linked to a basic ecosystemic NFV PaaS, and even expose (with great care) optional tools to facilitate integration with NMS/NOC and  OSS/BSS processes.  You could build a kind of substrate of NFV PaaS to facilitate VNF development too, and improve service agility at the functional level.

I’m kind of excited about what this might all mean.  Could we be finally moving to the NFV market phase were something actually useful emerges?  Could we be on the verge of exposing, and addressing, the real issues that should have been there all along?  If so, that would be great for us all.