Welcome to CIMI Corporation's Public Blog

There’s some good news on NFV, which I’m happy to be able to report since good news (other than hype) is hard to come by these days.  I reported early this year that operators’ CFOs had told me in the spring of 2014 that they were so far unable to make a conclusive business case for NFV.  They also said that they were not of the view that current PoCs would enable them to do so.  Over the last three weeks those same operators have told me that they are in fact seeing more clarity on the business case.

Where we stand today is that about half the operators I’d talked with in 2014 now believed that they could make a business case for NFV deployment based on the evolution of their current tests and trials.  The difference between then and now is that operators say they’re getting a lot more involved with operations integration in their testing, and that operations was the weak link in their business cases up to now.

An even more heartening piece of news is that l two thirds of operators now say that their CIO is getting engaged in the NFV trial process, representing the OSS/BSS side of things.  While many network vendors are squeamish about CIO involvement because they don’t deal with that side of the house much, the fact is that without strong support from operations there was never much of a chance of making NFV work.

Most of this progress has come along since late November when operators completed their annual technology preview to their 2015 budget processes.  A couple operators told me that this process is what brought what one called “clarity” to their trial planning and was instrumental in getting the CIOs involved.  The general view was that this fall’s tech planning will likely focus on broader deployment, which means 2016 could be a good year for NFV types.

I got a couple of other interesting comments from operators while talking about the trials, and so I want to summarize them here.  I can’t say too much in detail without violating confidences.

First, it seems clear that trials are dividing into those that are starting to get broader CxO buy-in and those that are still science projects.  About a third of all PoCs seem to fall into the latter category and I’d guess that as many as two-thirds of these won’t advance beyond the lab this year.  All I can say is that the ones that have made the most progress are those that involve one of the key vendors I’ve talked about.

Second, even where CIO involvement has solidified and operations progress made, there is still an indication that the scope of the projects is pretty limited.  While the operators themselves may not see it this way it’s my own view that most of the cases where the business case for NFV can likely be made will still not prove the NFV case broadly.  Early applications “covered” by the tests probably won’t involve more than about 10% of capex maximum, which means NFV has to be pushed further into other areas to make a big impact.  As far as I can see that big impact can be proved in only five or six trials.  Everyone else may have to dance some more before they get a broader sign-off.

Third, we are starting to see a polarization in NFV announcements just like we have already noted for trials.  Some vendors are involved enough with the “real” activity, the stuff with a business case behind it, to be able to frame products or product changes in the light of real opportunity.  The rest are still just singing in the direction of the nearest reporter/editor.

Fourth, we’re starting to see some pressure and desperation among vendors, even sadly a few who are actually doing good things.  Operators have long sales cycles and a lot of backers/VCs and even internal company sponsors are just not able to stay the course much longer.  We will almost surely see some casualties in the space late this year or early in 2016.

Fifth, I’m starting to see some winners.  Some companies—a very few—are stepping up and doing the right thing in trials and in customer engagements.  My favorite vendor has generated a lot of good stuff now, documents so thorough and relevant that it is amazing that so little is known about it.  Perhaps those who really have the right stuff aren’t interested in letting it all out yet, or perhaps companies are still groping for way to make something as technical as NFV into a marketing story that’s not going to take rocket scientists (or at least computer scientists) to understand.

So are we ready for field trials?  Even the more optimistic operators aren’t betting on trials before perhaps September, though a few say that if things were to go just soooo…well, perhaps mid-summer.  Personally I think that as many as three operators could go to full field trials by mid-July if they and their vendors did the right thing, but there’s a lot of work still to be done, particularly on the integration front.

That’s my key take-way, in fact.  Yes, we are finally making progress but a full solution to agile, efficient, operations is still elusive.  A few players could get there for sure, a few more could get close enough to be able to do a convincing trial and complete their work in the fall.

There are still a few troubling signs, even among operators who are making progress.  The question “Where do I start with NFV?” still rates among the top three in the most-advanced group of operators.  What they’re asking is for help identifying the places where NFV can make an early difference at the business level, and that shows that planning for NFV is still more technically driven.  The fact that they’re asking vendors the question is troubling given that there is no simple answer, no strategy that works for even a majority of operators.  You have to understand your own business to understand how to improve it.

And yet…I’m more hopeful.  It’s better to be wondering about NFV business cases than worrying over details of standards and specifications in a vacuum.  NFV has absolutely no merit if it doesn’t have business value, and we’re further along in deciding where that value can be found and how prevalent those situations are in various markets and operators.  That’s good progress.

In recent blogs I’ve been arguing that we’re focusing too much on the technology of new services and not about the actual opportunity.  There are scads of technological suggestions on where new revenue can be located, but where do you find opportunity?  That’s a question that’s always being asked by anyone who sells anything, including network and cloud providers and vendors.  The only sure way to find out whether someone is a prospect is to present them with an optimum value proposition and see if it resonates, but that’s obviously not a scalable scenario.  There are better approaches, and that’s the topic for today.

I’ve studied buyer behavior since 1982 in a survey sense, and in 1989 I built a decision model that uses survey data to forecast stuff.  The model was designed to incorporate what I learned about how decisions are made, and a high-level view of that process is essential as the opening round of any opportunity targeting approach.

The process of turning random humans or companies floating in space into committed customers is what I call trajectory management.  All these things are jumping around in Brownian Movement, with no structure or organization, no cohesion, no way to target with sales efforts efficiently.  What you have to do is to get them in sync, or at least get a useful community of them in sync.  You want them moving toward your marketing/sales funnel in an orderly way, so they intersect it, are guided into a common mindset, and turned over to the sales process.

In modern times, trajectory management is based on a progression:  editorial mentions sell website visits, website visits sell sales calls, sales calls sell products.  Buyers become “suspects” when they see your name in the media, they become prospects when you engage them on your website and with “anonymous collateral”, and they become customers through a personal contact.  You can’t jump over steps in this progression, so you have to be very wary of presenting too much information in the early part of the progression.  You will never sell a product because it’s mentioned in Light Reading or Network World, and trying to get enough into a story for that to happen will cause the story and your effort to fail.  Get the story, get the website visit, get the sales call.

Where does “targeting” come in, then?  Everywhere, largely for a combination of collateralization and prioritization.  You need to understand the messages that resonate most and most quickly, and you need to understand who will likely pull the trigger on a deal fastest given a particular value proposition.  All of this is like jury selection; it’s not an exact science but people still pay a lot of money to find stuff that could help.

Most countries have economic resources available online, and that’s true of the US of course.  The combination of tools that works the best is economic information by industry, particularly on employees and capital spending, and distribution of industries geographically.  With this combination you can do a lot to improve your chances of making the right statements, building the right products, targeting the right prospects with the right message.  You can also learn a lot about business behavior.

A logical question to ask when you’re talking about the opportunity for a product or service is the size of the market the new thing fits in, preferably by industry and geography.  Government data offers this in those two phases I mentioned, but running through a complete example would take too much time, so let me look only at the first phase in detail and describe the second in general.

If you think that cloud computing is the transfer of current data center apps to public cloud services, you could presume the biggest spenders on centralized IT would be the best targets.  The US market data says that North American Industry Classification System (NAICS, the new version of Standard Industrial Classification or SIC) 552, which is credit intermediation and related activities, has the highest central IT spending of all sectors.  Wholesale trade, renting/leasing, and retail trade follow (excluding the IT industry itself).  Many of these wouldn’t be considered cloud prospects, so an analysis like this could open up some new possibilities.

Suppose you think that the real opportunity factor is prospects for SaaS?  Obviously the government isn’t going to survey on that topic, but what they do survey on is the spending on integration services.  If you’re a company who relies on integrators you may well be unable to acquire and sustain an IT organization of your own, so you’re a great prospect for a cloud service that gives you the applications you want in an as-a-service package.  Top industry there is retail trade, which is interesting because they’re also high on the ranking in terms of central spending.

For doubters, let me point out that the retail industry has been a big consumer of architected services for electronic data interchange—EDI, the stuff that transfers purchase orders and payments and so forth.  Data on current SaaS spending is hard to break out from company sources, but my surveys have shown retail firms to be early adopters of SaaS as well.

How about opportunities for network services and NFV-based services?  These are likely tied pretty closely to what companies are spending on network equipment.  The industries leading that category are (again omitting IT and networking companies themselves) our old friend credit intermediation followed by miscellaneous scientific and technical services.  This last category also ranks high in use of integration services, which would suggest it’s a good target for network-as-a-service.

Or perhaps you see network and cloud opportunities arising where companies have a very large investment in personal computers and distributed elements?  Two old friends here, retail trade and miscellaneous scientific and technical services.  So the same top industries show up using this metric as well.

This total-spending measurement is a good opportunity gauge, but it may not reflect the level of acceptance.  We can also look at firms by how much of their IT budget is spend on centralized IT, distributed IT, networking, and integration.  In terms of percent spent on central IT the banks and credit firms top the list and retail is down in the standings quite a bit.  The industries with the largest percentage of budget spent on distributed IT are petroleum and coal products and printing and related activities.  Networking as a percent of total spending is highest for machinery firms, food-beverage-tobacco, and our miscellaneous scientific and technical services.  Integration spending is highest as a percentage in construction, ambulatory health care, and apparel.

Whatever measure you use to rank industries, the next step is to get a density map of that particular NAICS across your prospecting geography.  If you know you want to target our favorite “miscellaneous scientific and technical services” you look for metro areas or other points where that NAICS is found most often.  If you have access to more refined data (typically from commercial rather than government sources) you may be able to get the density plot for headquarters locations only, which is better since in most cases technology buying is done from the company HQ.

With knowledge of NAICS and some further insight on things like how much the NAICS outsources and how its budgets are spent overall, it’s possible to determine what messages would likely resonate.  My surveys show that companies with very centralized IT have strong CIO organizations and are less likely to favor things like SaaS, where companies with more distributed IT are the opposite.  That helps not only in generating collateral for sales use, but also in deciding the kind of reference accounts that would be considered most valuable.

The point of this is that NFV and SDN and the cloud are all selling into a world where IT is the rule and not the exception, and by understanding how IT dollars are currently spent, you can optimize getting some of those dollars for your early SDN or NFV services.

Cisco came out with their numbers, and while I could talk about them by themselves, I think it might be more helpful to consider them in light of some other news, which is VMware’s decision to get serious about NFV and even Facebook’s tossing in a new data-center switch.  I’ll mention some Cisco-numbers commentary where appropriate, but I want to open with some quotes from John Chambers:  “Let’s start with a basic question, like why Cisco?”, and end with “We are well positioned for a positive turn in either service provider or emerging markets. But we are not modeling those turns for several quarters despite the better results we saw in this last quarter….”

VMware and Cisco have a lot of competing dynamics and a lot of common factors.  Most recently, NFV as a technology to support has joined both groups, a response to the market conditions on the provider side.  The reason is obvious; my model has been showing that NFV is likely to be the largest single source of new data center deployments for the next decade, and also likely the largest single source of new server deployments.  It will consume the most platform software and the most new management tools, and frame cloud computing’s future.  That’s a heady mix; too much upside to ignore.

The challenge for everyone in the space is that Facebook proves that if you build data centers for net-centric use, you may find it easier to design your own stuff, or at least pick from commodity white-box options (Cyan and Pica8 had some new developments in these areas earlier this week too).  The obvious solution is to rely on symbiosis to get a piece of the new action.  If you can support the NFV revolution that’s driving change you might stave off the wolves.

For VMware, there may be another dimension.  Nothing feels better than to rub a rival’s nose in a dirty dog dish, and that’s less risky when the rival is chained.  Cisco has demonstrated that because of its hardware dependency, software-defined anything is considered a risk to be managed not an opportunity to be seized, which attitude somewhat limits Cisco’s aggressive options.  VMware has no incumbency in network equipment and so can dance wild and free into the virtual age.

Let’s get to John’s early question, “Why Cisco?”  This has two faces, one of which is why Cisco is doing what it always does, which is be a fast follower.  Cisco’s need to sustain its near-term hardware revenue stream creates for the company is significant.  Most of what Cisco announces these days boils down to 1) assertions that the “Internet of xxx” where “xxx” is anything exciting and different (Chambers did his Internet of Everything routine on the call), generates a boatload of new traffic operators have a Divine Mandate to carry or 2) enhancements to switching/routing protocols to create SDN-like features without having to adopt white-box SDN.  The second face is “Why Cisco?” in the sense of why buy from them, and for network operators it’s clear the answer has to be “because they’re supporting where we need to go”.  That’s clearly at odds with the first interpretation of that same question.  They’d like Cisco to lead in NFV.  They are not, which is probably a factor that VMware has noticed.

However, VMware has its own issues.  Their stock has been in general decline over the last six months as financial rags tout views like “Virtualization in Decline!”  Under pressure from open-source software in the cloud, they can hardly afford to ignore an opportunity like NFV, but their traction opportunities are a bit slim.  Cisco is a server vendor, which means they have a big financial upside from all those servers and data centers.  VMware can hope for a platform software upside on a hosting deal, but servers cost more than platform software, particularly when so much operator focus is on open-source versions of what VMware would like to license to them.

If you look at NFV objectively it’s hard to see why Cisco would find it such a threat.  Because NFV could at least admit standard boxes under the NFV tent through generalization of the Virtual Infrastructure Manager (which HP and Oracle among others have already proposed) it could build a layer above both legacy boxes and evolved network device notions like SDN.  That might reduce operators’ interests in changing out gear by making it unnecessary to switch switching (so to speak) just to talk to it from NFV.

Part of the explanation may be Cisco’s beating the revenue line, which came about because it increased revenue 7% y/y after a bad similar quarter last year.  It’s hard not to see this as a possible indication of a rebound in carrier capex, especially if that’s what you devoutly hope it is.  Stay the course a few quarters longer and 1) Chambers can retire on an up or 2) he won’t have to retire at all.  Take your pick, Chambers-watchers.  But even Chambers has to admit that nothing is turning around for the next couple quarters and their forward growth guidance of about 4% reflects that.

VMware is probably salivating over Cisco’s business challenges, but it has its own issues.  The cloud has jumped more on OpenStack than VMware hoped because public cloud has been much more valuable than private cloud, which VMware could have supported easily (and did, belatedly IMHO) as an evolution of virtualization.  Cisco took the OpenStack approach but while aggressive action there might have at the least handed VMware its head by advancing OpenStack more visibly, Cisco has been more interested in differentiating UCS than promoting standards.

UCS growth was strong in Cisco’s quarter, up by 40% compared to switching’s 11% and routing’s 2%.  But UCS was a bit under $850 million when routing was about $1.8 billion and switching double that.  You can see that Cisco needs more UCS but doesn’t need it to indirectly (via SDN and NFV) cannibalize switching and routing revenue.  And above all it doesn’t need any weakening of account control.

Now we have an NFV war, which pits a new (and thus totally hazy) VMware offering against a Cisco offering that’s always seemed more like and NFV billboard than a product.  Cisco doesn’t sing a bad NFV song (it sounds in fact a lot like Oracle’s story on the surface including the TMF-ish CFS/RFS angle) but they aren’t singing it out loud and strong as another song goes.  VMware has a chance to take a lead in positioning…if…

…they can figure out something to say.  Obviously parroting Cisco’s story with more verve and flair would be better than nothing (or even than Cisco) but probably not enough given that others in the space are demonstrating substance.  VMware needs to join my club of players who actually can do something to drive NFV, not the club of NFV hype artists (a much larger group).

So does Cisco, not only to compete with VMware, but also to compete with Oracle and Alcatel-Lucent and HP and even Overture.  There are big companies with big stakes in the ground leaping on the NFV bandwagon daily, and it’s hard to imagine none of them have taken the decision seriously.  I suspect that Cisco did too, and took the tactical short-term approach.

The stakes are rising now and it’s time to get to the last quote from the call that I opened with.  Chambers admits that the service provider market isn’t going to turn around in a few quarters.  Earth to John: It’s never going to “turn around” in the sense of returning to investment patterns of the past.  You just gave yourself a couple of quarters to face facts, as so many of your competitors are obviously doing.  I’d get moving if I were you.

They could, too.  Cisco’s NFV story may be a billboard but I think I know the company well enough to know that what’s missing is intentions and not capabilities.  They almost certainly have as much as Oracle or Alcatel-Lucent, at the least, and they have a lot of inventive people.  And their desire to preserve the present could align pretty well with operator goals not to sink themselves in accelerated write-downs.  If Cisco could get the orchestration/operations story right they could come out of this quickly.  Faster than VMware for sure, unless they bought their position.

That’s my advice for VMware.  Unless you already have a product sitting somewhere waiting for an organization to spring up, you’re going to need to start spending like a sailor on M&A and hope that John waits just a little bit longer.  Hope, but don’t bet on it.

NFV as a technology has captivated a lot of people.  For it to be a “revolutionary technology” it has to do something revolutionary to the way we create network services and purchase network infrastructure.  That obviously has to start with some set of NFV products, created by credible sources and delivered with a compelling vision that wins over risk-adverse decision-makers.  Such a source has to find a benefit for themselves too, and this kind of win-win has been hard for vendors to frame so far.

Especially for software vendors.  There are three companies in the market that we would say are decisively on the software side of the vendor picture—IBM, Microsoft, and Oracle.  None of these guys have been powerhouses in NFV positioning; in fact all have been non sequiturs, at least until now.  Oracle is now stepping up in NFV with an announcement it made yesterday, and the fact that underneath the covers Oracle is a major cloud provider, a major application provider, and even a provider of highly credible carrier-level servers and operating systems software makes it even more interesting.

Oracle laid out its basic NFV approach last fall, and since all NFV approaches map to a degree to the ETSI E2E architecture it wasn’t revolutionary.  What they are now announcing is the details on their Network Service Orchestrator.  To put that term into perspective (meaning ETSI perspective) it’s kind of a super-MANO NFVO, but that’s probably not the way to look at it.  The best part of Oracle’s talk is that they’ve put both NFV overall and their own stuff on a kind of vertical stack from OSS/BSS down to infrastructure, so let me use that reference as a starting point to talk about Oracle’s strategy.

In the Oracle vision, OSS/BSS and the TMF world guide a series of service lifecycle processes that focus on what gets sold and paid for.  They also coordinate craft activity, so things about service ordering that involve real humans doing stuff like installing CPE are up in this top layer.  In the TMF world, this layer builds toward the Customer-Facing Service, a term I’ve used a lot.  The TMF has recently seemed to be working around or away from the CFS concept, but it may be making a comeback with the TMF’s ZOOM modernization process.

Below CFS in Oracle’s stack is the Resource-Facing Service (RFS), which is also a TMF term.  According to Oracle’s model, ETSI is a means of realizing RFSs, so the ETSI processes start below the RFS.  In a diagrammatic sense, Oracle is saying that their OSS/BSS offerings cover the top of the service-to-resource stack, and that their new Network Service Orchestrator will cover the bottom, with a critical overlap point at RFS.  If you’ve followed my blogs and my work in ExperiaSphere you know that I believe in CFS/RFS and believe that service-to-resource boundary is critical, so I’m in favor of this positioning.

Using this structure and this service-resource stack as their foundation, Oracle then applies service lifecycle management examples to explain what they’re up to, which again is something I do myself so I can hardly criticize it.  The end result is a strong presentation, positioning that is clear at the high level, and one that is anchored firmly in both the ETSI stuff and the TMF stuff.  Oracle is the only NFV player to offer a highly OSS/BSS-centric vision and to build a story from top to bottom that’s fairly clear.

Oracle also passes a couple of my litmus tests for sanity in VNF positioning.  They don’t say that OpenStack is NFV orchestration.  They have a generic VNF Manager (VNFM) and not VNF-specific ones.  The have analytics and policies.  There’s enough here to prove that Oracle isn’t just blowing smoke at the world.  The bad news is that I can’t validate a lot of the detail from their material, and there are questions that in my mind demand validation.  There’s not enough detail to prove it works.

Let’s start with NSO.  When Oracle introduced ETSI MANO as a concept they cited the notion that there were three layers of orchestration within it—MANO, VNFM, and VIM.  I don’t disagree that there are three “orchestrable elements” represented, but it’s not clear to me why we have three independent orchestrations going on there.  It’s not clear to me how these three orchestrations are coordinated with the Oracle approach.  My own vision is to model everything at all three levels using a common modeling language.  Since I don’t have any details on Oracle’s modeling approach can’t offer a firm answer to what they do, though their material suggests to me that there may actually be three different models and orchestrations here.

If you count the OSS/BSS service-level stuff there could even be four.  Oracle cites an example of a deployment that might involve a piece of CPE in some cases or a deployment of a virtual element in others.  Obviously if CPE has to be deployed in a truck roll, you’d have to manage the craft activity via OSS/BSS, but suppose there’s CPE there already, or that the service choice between a physical and virtual function is inside the network, a matter of whether a given user is in a zone where NFV is available or not?  Then operations really doesn’t have to know—it’s a deployment choice to parameterize or to host a VNF.  And all of these decisions have to be modeled, orchestrated, if you’re going to choose between rolling a truck and pushing functionality out to virtual CPE.  Is this orchestration option four, with yet another modeling and orchestration toolkit?  It would make more sense to collect orchestras here, I think.  If event-driven OSS/BSS is a goal then why not fold it you’re your functional-MANO stuff?  Maybe they do, but I can’t tell from the material.

The third point is that service/resource boundary and the overlap point for OSS/BSS and NSO.  There are a lot of powerful reasons why the service and resource domains have to be separated and a lot of benefits that could accrue once you’ve done that.  Some of these are truly compelling, significant enough to deserve mention and collateralization.  In fact, these benefits are the real glue that binds that lifecycle process set Oracle uses.  They are not mentioned much less collateralized.

But there is a lot of promise here.  Oracle’s cloud strategy is based in no small part on SaaS delivery, which means it has to face at the cloud level many of the same deployment and operationalization issues that operators face with NFV.  Solaris is a premier operating system for the cloud, with strong support for containers and big data built right in.  Oracle has database appliances that could be used to manage the collection, analysis, and distribution of operations information.  They even have servers, though their positioning suggests they’re not going to get hidebound on the question of using Oracle iron with Oracle NFV.  The point is that these guys could really do a lot…if all this stuff is as good in detail as it is in general.  So I’m not carping as much about their concepts as I am about their collateral.

Oracle has done the best job so far of positioning its NFV plans for public consumption.  Their slides are clear, they cover the right high-level points, and they demonstrate a grasp of the problem overall.  In that regard they’ve beat out all the other players, including those whom I’ve given the nod as the top contenders in NFV.  However, NFV has to be more than just a pretty face.  My own standard for rating NFV implementations is that I have to have documentation on a point to fully validate it.  Oracle did offer me a deeper dive briefing but as I told them, I can’t accept words alone and no further details in document form were provided.

I can’t give Oracle an NFV rating equal to HP or Overture, both of whom have given me enough collateral to be confident of their position.  I can’t even give them as much as I’d give IBM, whose SmartCloud Orchestrator is the only example of TOSCA modeling, which I think is the best approach for NFV.  They fit in my view of the NFV space where Alcatel-Lucent fits, a company who I believe has the stuff to go the distance but who’s not been able to collateralize their offering enough for me to say that for sure.

Of course, they don’t have to sell me, they have to sell the network operators.  I know they have decent engagement in some NFV PoCs, Oracle is going to make a push for their NFV strategy at Mobile World Congress and again at the TMF meeting in Nice in June.  These events will probably generate more material, and I’ve asked Oracle to provide me with everything they can to explain the details.  If I get more on them from any of these sources, I’ll fill you all in on what I see.  In the meantime, it will be interesting to see if Oracle’s entry causes some of the other NFV players to step up their own game.  Singing a pretty song doesn’t make you a pretty bird in the tree, but absent the song nobody will know you’re there at all.

OK, I have to admit it.  There is nothing on the face of technology today that fills me with the mixture of hope and admiration and disgust and dismay like the Internet of Things.  Even the name often annoys me.  It brings to mind the notion of my thermostat setting itself up a social network account.  The hype on this topic is so extreme, the exaggerated impacts so profound, that I’d despair and call it all a sham were it not for the fact that there is real value here.  We’re just so entrapped in crap that we’re not seeing it, and we’ll never prepare for the real parts if we can’t get past the exaggerations.

Home control is a big part of the IoT, right?  Suppose that we were to make every light, every outlet, every appliance, every motion sensor or infrared beam in every home a sensor.  How much traffic would this add to the Internet.  Zero.  None.  Suppose we were to place similar controls in every business.   How much traffic?  None.  Even if we were to add sensors to every intersection, add traffic cameras, add surveillance video to every storefront we’d add little or nothing.  We already have a lot of this stuff and it generates no direct Internet impact at all.

Control applications aren’t about broadcasting everything to everybody, they’re about letting you turn your lights on or off without getting up, or perhaps even turning them on automatically.  You need to have sensors to do that, you need control modules too, and controllers, but you don’t need to spread your home’s status out across the Internet for all the world to see.  Sensors on sensor networks don’t do much of anything, and most controllers don’t do anything to traffic either.

How about the fact that “home control” can sometimes be exercised from outside the home.  There are times when you might want to turn your home lights on from your car as you drive onto your street.  There are times when you might want your home to call you (to tell you your basement is wet) or call the police or fire department.  The thing is, we do all of this already, and it’s not like your home is going to call you every minute even if it could.  The fact is that in a traffic sense the IoT is kind of a bust.  Similarly, it’s not going to add to the list of things that need IP addresses; most sensors and controllers work on non-network protocols and those that don’t use private IP addresses that aren’t visible on the Internet anyway.  If you call your home from your cell to turn your lights on, you’re likely only consuming a port on an IP address you already have.

Besides being an obviously great yarn to spin, does the IoT actually offer anything then?  I think it does, and I’ve blogged about a part of what it might offer in the past.  We could expect to see control domains (sensors and their controller) abstracted as big-data applications available through APIs for the qualified to query.  We could expect to see some of the real-time process control stuff, which is what self-drive vehicles are conceptually related to, generate “local” traffic that might even get outside our control network and touch online.  But traffic isn’t going to be where IoT impacts things, nor will addresses or any of the stuff you always hear about.

The biggest impact of IoT on networking is in availability.  If I want to turn on my home lights as I drive up, I don’t need a lot of bandwidth but I darn sure need a connection.  If I were to find that most of the time my lights-on process failed, I’d be looking for another Internet provider.  If I’m expecting my car to turn left when it’s supposed to and it runs forward into the rear of a semi because it lost Internet connectivity, I’m going to be…well…upset.

The Internet is pretty reliable today, but most home alarm systems don’t use it, they call out either wireline or wireless on what’s a standard voice connection because that’s more likely to work.  Unless we want the Internet of Things to be phoning home (or out from home) in our future (how pedestrian is that?) we have to first be sure it can do the kind of stuff that’s already bypassing it for availability reasons.  But would we pay enough for that availability improvement?

A second big impact is latency.  My car is moving down the street and the sensors around on the corner and lamp-posts tell the Great Something that another vehicle is approaching on the side street.  If it takes two or three seconds for the message to get to the controller, be digested, get back to my car, and be actioned, and I’m moving along at 60 mph then I’m a couple hundred feet along before recommended action can be taken.  Even a hundred milliseconds is nine feet at my hypothetical speed.  I can hit somebody in that distance.

Related to this is the third impact, which is jitter.  Whatever the character of a control loop, the worst thing is a lack of stability in its performance.  You can design around something or avoid using it if it stays where it is, but if it jitters all over the place you find yourself stopping at the stop sign one minute and hitting the semi the next.  That sort of uncertainty wears you down and surely reduces the sale of self-drives.

Home controllers offer what I think is the logical offshoot of all these issues.  Why do we have them?  You have to shorten control loops where real-time responses are important.  Rather than try to create a sub-millisecond Internet everywhere, the smart way is to host the intelligence or the controller closer to the sensors and control elements.  So what we need to be thinking about with IoT isn’t traffic on the Internet or addressing or even Internet latency and jitter, it’s process placement.

Network standards won’t matter to IoT.  What matters is inter-controller communication, big-data abstraction APIs for raw information access, and the like.  My car controller has to talk to its own sensors, to local street sensors, to route processors, traffic analyzers, weather predictors, and so forth.  None of this is going to create as much traffic as a typical teen watching YouTube but it will create a need to define exchanges, or we’ll have cars running into areas where they can’t talk to the local control/sensor processes and whose drivers are probably watching YouTube too.

Making stuff smarter doesn’t necessarily mean it has to communicate, or communicate on a grand global scale.  What is different about “smart” versus “dumb” in a technology sense isn’t “networked” versus “non-networked”.  Being connected isn’t the same as being on the Internet.  The key to smartness is processes and the key to extending real-time systems over less than local space is process hierarchies.  Processes will be talking to processes, not “things to things” or “machines to machines”.  This is about software, like so much else in networking is.  It’s about the cloud, and it’s process hierarchies and cloud design that we need to be thinking about here.  The rest of the news is just chaff.

Our thermostats don’t need to talk to each other, but if yours has something to say about this feel free to have it call mine, and good luck to the both of you getting through.

If kids put teeth under their pillow and hope for quarters, or dig in their yards hoping to find pirate treasure, so financial planners in operators are looking for NFV and SDN to generate revenue.  Cost savings are fine as a means of delaying the marginalization of the network and bridging out of a difficult capex bind, but only new revenue can really save everyone’s bacon.  The question is whether the financial planners’ aspirations are any more realistic than those of our hypothetical quarter-and-treasure-seeking youth.

It’s really hard to say with confidence what services will be purchased in the future, even five years out.  Survey information on this sort of thing is totally unreliable; I know that from over 30 years’ experience.  I’ve made my own high-level guess in prior blogs—we have to presume that business IT spending growth will come from improvements to productivity gained by harnessing mobility.  Rather than tell you that again, I propose we forget for a moment the specifics and look instead at a very important general question.  Not “what” but how?

“Service agility” is the ability to present service offerings that match market requirements.  If we knew what those requirements were we wouldn’t need to be agile; we’d just prepare for the future in a canny way.  The fact is that even if we knew the next big thing, we’d have to worry about the thing after it.  Service consumers are more tactical than traditional service infrastructure.  What we need to know now is what the characteristics of the string of next-big-things-to-come are, so we can build SDN and NFV correctly (and optimally) to support them.

Sometimes it’s really helpful to engage in “exclusionary thinking” for something like this.  So, we’ll start with what they are not.  We are not going to get new revenue from selling the same stuff.  We are not going to get new revenue from selling new stuff whose only value is to allow customers to spend less.  We are not going to get new revenue from sources that could have given us new revenue all along had we but asked for it.  New revenue may not come from my guess on mobile empowerment but it’s going to come from something that is new.

If we follow this thread we can look with somewhat of a critical eye at the current NFV activities at least insofar as supporting new revenue is concerned.  Virtual CPE is not new revenue.  Hosted IMS is not new revenue.   In the SDN world, using virtual routers instead of real ones or OpenFlow instead of adaptive routing isn’t new revenue either.  All of these things are worthy projects in lowering costs and raising profits, but cost management (and those who depend on it) vanish to a point.  We have to see these as bridges to the future, but we have to be sure we can support the future as it gets closer.

“Old revenue” is based on two things—sale of connectivity and sale of connection-related features.  New revenue delivers stuff, provides information and decisions.  Thus, it’s much more likely to resemble cloud features than service elements.  Services will be integrated with it, and in particular we’ll build ad hoc network relationships among process elements that are cohabiting in a user’s information dreams, but we’re still mostly about the content rather than about the conduit.

If we look at SDN in these terms we realize that SDN isn’t likely to generate much new revenue directly. It’s important as a cloud enabler or as an NFV enabler, depending on what you see the relationship between these two things being.  NFV is definitely a support element too, but it’s supporting the dynamism of the features/components and their relationship with each other and with the user.  We’re using NFV to deploy VNFs, components, VNF-as-a-service, and so forth.  We’re using SDN to connect what we deploy.

What is that?  Not in terms of functionality but in terms of relationships?  There seem to be two broad categories of stuff, one that looks much like enterprise SaaS and the other that looks quite a bit like my hypothetical VNFaaS or what I’ve called “platform services”.  Amazon is building more and more value-added components in AWS to augment basic cloud IaaS, to the point where you could easily visualize a developer writing to these APIs as often as they’d write to common operating system or middleware APIs.  These combine to frame a model of service where composition of services is like application development.

This more dynamic model of service evolves over time, as companies evolve toward a more point-of-activity mission for IT.  Some near-term services will have fairy static relationships among elements, particularly those that support communities of cooperating workers or that provide “horizontal” worker services like UC/UCC.  Others will be almost extemporaneous, context- and event-driven to respond to conditions that change as fast as traffic for a self-drive car.

In general, faster associations will mean pre-provisioned assets, and as activities move from being totally per-worker-context-driven to a more planned/provisioned model we’ll move from assembling “services” from APIs and VNFaaS to assembling them in the more web-like sense by connecting hosted elements.  In between we’ll be deploying service components and instances on demand where needed and connecting them through a high-level connection-layer process that looks a lot like “overlay SDN”.

NFV’s MANO is about deployment instructions; it models the service’s functional relationships only indirectly.  As you move toward extemporaneous cloud-like services you are mapping functions and functional relationships themselves.  In many, likely even most, cases the “functions” don’t have to be deployed because they’re already there.  It’s a classic shift from service management to service logic, a boundary that’s been getting fuzzier for some time, though the shift has been gradual and largely unrecognized.

This is a new kind of orchestration, something that’s more akin to providing a user with a blueprint that defines their relationship with information and processing, and the relationship between those two things and all of the elements of context that define personalization because they define (at least in a logical/virtual sense) people.  Think of it as an application template that’s invoked by the user on demand, based on context and mission, and representing the user through a task or even entertainment or social interaction.  Identity plus context equals humanity?  Perhaps in a service sense that’s true.

Both NFV and SDN need to be expanded, generalized, to support this concept but I’d submit that we were as an industry, perhaps unwittingly, committed to that expansion anyway because of the cloud.  NFV is the ultimate evolution of DevOps.  SDN is the fulfillment of the ultimate generalization of OpenStack’s Neutron.

Yes, Neutron.  OpenStack is probably more important in the model I’m describing here than SDN Controllers because the latter will be abstracted by the former.  TOSCA is more important than Yang because the latter is about network connections and the former is about cloud abstractions.  We’re not heading to the network in the future, but to the cloud.

Don’t let this make you think that I believe NFV is superior to SDN.  As I indicated above, both are subordinate to that same force of personalization.  Whatever services you think are valuable in the future, and however you think they might be created, they’ll be aimed at people and not at companies or sites.  Both SDN and NFV have blinders on in this respect.  Both see the future of networking as being some enhanced model of site connection when mobility has already proved that sites are only old-fashioned places to collect people.  It’s the people, and what they want and what makes them productive that will frame the requirements for NFV and SDN in the future.

Alcatel-Lucent released its quarterly numbers before the bell this morning, and their results illustrate the complexity of the business of networking these days.  Do we look at things tactically, as current financial markets do?  If we say “No!” to that, then can we agree on what a strategic look would offer us?  Let’s see.

Tactically speaking, what Alcatel-Lucent’s numbers showed was a company whose IP business did well while other sectors largely languished.  IP routing was up 15% in constant currency, IP transport (meaning largely optics) was up by 3%.  Given that many of Alcatel-Lucent’s rivals were seeing negative growth in these same areas, they didn’t do badly here.

Elsewhere things weren’t as bright.  Revenues in IP Platforms, the service and operations layer, were off 15%.  Access was off by 11% overall, and that includes wireless.  Revenues were down overall, and while the quarter was judged as good by the Street it’s because cost-cutting helped profit more than lower revenue hurt it.

The overall picture here is that Alcatel-Lucent is in fact delivering on its transformation, and I believe that’s true.  It’s also marching to the future one quarter at a time, and so it’s fair to ask whether the transformation is taking them to a future where numbers can continue to be positive.  That’s a much harder question to answer because it demands we look at the model of networking not today but perhaps out in 2020.

It is very clear that we will need bits in the future, so it’s clear that IP transport is not going away.  In fact, Alcatel-Lucent and the whole sector are delivering more bits every year.  They’re just not delivering a lot more bucks.  Optical transport doesn’t connect directly to service revenues, feature differentiation is difficult to sustain, and competitive price pressure can only grow.  IP routing is a smaller business for Alcatel-Lucent today than IP transport, so in order for the revenue numbers to turn around, IP routing has to grow significantly over that five-year period or Alcatel-Lucent has to find another growth area.

Where have we heard network operators telling us that their plan is to build more network routing?  Every major initiative operators have undertaken in network modernization has been directed at doing more with optics and less with IP.  IP is the layer where content traffic growth, regulatory changes, and complexity increases have created the biggest threats to return on infrastructure.  Can Alcatel-Lucent deliver radical new revenues from that space?  Not without something to push things along a different path.

That path would have to be buried somewhere in what the company classifies as IP Platforms.  The challenge IP has is that Internet is not highly profitable today, is getting less profitable every year, and probably can’t reverse that trend any time soon.  And the Internet is where most IP equipment goes.  Operators, to invest more in IP rather than continue to try to invest less, would have to earn more on their investment, to turn around the converging revenue/cost-per-bit curves we’ve all seen.

I’ve said in earlier blogs that I believe the future of the network will be an agile opto-electric substrate at the bottom, the cloud at the top, and virtualized L2/L3 in the middle, tied to more agile optics below and hosted in the cloud above.  That model might well end up spending more on L2/L3, but not on routers as boxes.  It would spending more on virtual routers, virtual functions, and servers to host them on.  Alcatel-Lucent does not make servers, and that’s the company’s big strategic problem.  They have to face off in the new age of IP beyond 2020 with network competitors like Cisco who have servers and can win something through the transformation to hosted services.  They also have to face off against IT vendors who present hosting options and even virtual routers/functions and don’t even bother with network equipment.  That means that they have to do really, really, well in SDN and NFV and the cloud but do it without having the automatic gains that being able to sell the servers would generate.  I commented in my analysis of how various classes of vendors would do in NGN that the network equipment types would have a challenge because of the natural loss they face if money shifts from funding physical network devices to hosting virtual ones.  Alcatel-Lucent faces that risk.

Which is why I find their performance in IP platforms troubling.  This is where the company needed double-digit growth, massive evidence that they were gaining traction in the service-software part of infrastructure where new revenues could be created, and from which symbiotic tendrils could be extended to pull through equipment.  So far they don’t have the financial signals to validate they’re getting traction there.

CloudBand is Alcatel-Lucent’s biggest hope, operations is next.  That’s because first and foremost we’re building revenues from future services by hosting stuff in the cloud, and second because what we’re not hosting there for revenue’s sake we’re operating from there to manage costs.  SDN and NFV are important because they represent technology and standards trends that define these hosting-to-service relationships and also frame the operations challenges that all future services will have to meet.

In the cloud/CloudBand area, Alcatel-Lucent has what I believe to be a strong product set and good capabilities, but their ability to describe what they have is extraordinarily weak.  Of the three vendors who I rate as likely being able to drive NFV to deployment, they are the only one for whom I have to stress the word “likely” because I just can’t get the details needed to offer an unqualified response.  And hey, Alcatel-Lucent, if you don’t sell servers you have to be able to present the cloud in some kind of awe-inspiring software package or you have little chance of being a player.

On the operations side, Alcatel-Lucent doesn’t match rivals Ericsson or Huawei in terms of OSS/BSS tools and capabilities.  They may have plans and capabilities to link the cloud layer to operations in a good or even compelling way, but those plans and capabilities are among the things I don’t have details on.

Could it be that Alcatel-Lucent is pushing on IP Routing as a segment because it’s where they have growth today, and holding back in areas like SDN and virtual routing that could be seen as a threat to their IP routers?  If that’s the case then they are betting that routers will carry the company in the future, and I have no doubt that cannot happen.

From the time when Alcatel and Lucent became Alcatel-Lucent, I’ve groused over their insipid positioning and weak marketing.  I’m still grousing, and I think it’s past time when the company deals with that problem.  People facing a major transformation of revenue and technology, as operators are everywhere, want to follow what they perceive a leader.  For Alcatel-Lucent, the time to qualify themselves for that role is running short.  Routing can’t sustain them forever.

The FCC is converging on a net neutrality order, bringing “clarity” to the broadband regulation process.  In fact, the process has been murky since the Telecom Act, nothing in the current order (as we know of it from the FCC’s released “fact sheet”) un-murks much, and in any event this is something only the courts can hope to make final and clear.  Everyone will hate the new order, of course, and it doesn’t do what it might have done, but it’s not as bad as it might have been.

The high-level position the FCC is taking shouldn’t surprise anyone who knows what the FCC is and what it can and can’t do.  The question that’s been raised time and time again, most recently and decisively by the DC Court of Appeals on hearing the FCC’s previous neutrality order, is jurisdiction.  The position the Court took was that the FCC having previously declared that the Internet was not a common-carrier service, cannot now issue regulations on it that are permitted only for services of that type.  And that is that; the FCC has no jurisdiction under its own rule.  Fortunately for the FCC, it is not bound by its own precedents, so it can reverse a prior ruling in a stroke, which is what Wheeler is going to propose.  Broadband, wireline and wireless, would be reclassified as Title II.

What this does not mean (as TV commercials and some comments have suggested it does) is higher fees and taxes imposed on broadband providers and paid by consumers.  The FCC has said all along that if it made the Title II decision it would then apply Section 706 of the Act to “forbear” from applying many of the Title II rules to broadband.  This would include fees and taxes but also requirements for wholesaling.

The combination of these rules generates as harmless a result as anything is in this political age.  Yes, the FCC can change its mind.  Yes, the courts could rule this is invalid too (I doubt they will).  Doomsayers notwithstanding, the legal foundation of this order is as good as we can get without going back to Congress, a fate I’d be reluctant to wish on the industry.  The biggest real issue neutrality had was jurisdiction of the FCC to treat violations and the order fixes that without generating much unexpected disruption with operators.

So what is the FCC going to do with its authority?  In many cases that’s at least semi-harmless harmless.  It boils down to “no fast lanes” and “equal regulation for all broadband”.  The former bars paid prioritization of traffic.  The latter is the biggest change; the FCC is applying all its rules to wireline and wireless alike.  There will be gnashing of teeth on this, of course, but the truth is that everyone knew we were heading in that direction.  Deeper in the fact sheet the FCC released are some interesting points, though.  These could have significant consequences depending on just what the FCC does with the authority the order would give it.

At the top of my list is the fact that the FCC would hear complaints on ISP interconnect/peering.  This is consistent with the fact that the FCC has jurisdiction over common-carrier peering and tariffs, so at one level it’s not a surprise.  The question is how this new authority would be used, given that we’ve just had a flap between ISPs and content providers like Netflix, resulting in the latter paying a carriage charge to some access providers.

Video traffic is disruptive to network performance, because it demands fairly high capacity and at least stable if not low latency.  It swamps everything else and so if you let it run unfettered through the network it can congest things enough for other services to be impacted.  The FCC’s new order permits throttling traffic for management of stability and to prevent undue impact on other services.  If the FCC were to say that Netflix doesn’t have to pay for video carriage, operators could either suck it up and invest in capacity, further lowering their profit on broadband, or let things congest and try in some way to manage the consequences.

The FCC would, under the new order, have the power to impose settlement—rational settlement—on the Internet.  That could be the biggest advance in the Internet’s history but for one thing, that politically inspired and frankly stupid ban on paid prioritization.  With a combination of settlement and paid QoS, the Internet could become a limitless resource.  With paid prioritization off the table completely, we might see settlement but it won’t do much more than preserve the status quo, under which operators are already seeing critical revenue/price convergence.

I’m not sure whether the details of the order will shed light on this point.  In the past, the FCC has looked askance at provider-pays prioritization, but not at plans where the consumer pays.  The fact sheet doesn’t seem to make any distinction but the order might read differently.  We’ll have to see when it’s released.

The other interesting point in the fact sheet is that the FCC intends to insure that special IP non-Internet services (including VoIP and IPTV) don’t undermine the neutrality rules, presumably by having operators move services into the category to avoid regulation.  This sort of thing, if it went far enough, could create a kind of growing “Undernet” that would absorb applications and services by offering things like paid prioritization.

The devil again will be in the enforcement details.  There’s a fine line between IPTV and streaming services on the Undernet.  The FCC could lean too far toward regulation and make IPTV seem risky, or too far away and encourage bypass of the Internet.  Will the order make its bias clear, or will we have to wait until somebody is ordered to do, or not do, something?

Waiting is the name of the game, regulation-wise, of course.  This order will be appealed for sure.  Some in Congress will propose to preempt it, reverse it, toss it out.  We probably will have years of “uncertainty”, but the good news is that we’ll probably know shortly after the order comes out, whether there is a reasonable risk that any of the reversing/undoing will succeed.

I believe that the order as summarized in the fact sheet is better than we’d likely get if Congress intervened.  The original Republican stance of a very light touch has been amended of late to include support for “no fast lane”, and that creates the classical problem of a part-regulated market.  Light touches aren’t distinctively no touch or a push, and all the current Republican position really seems to do is to give the FCC authority to do its regulating on neutrality without (in fact, barring) Title II regulation applying to ISPs.  I think that the details of that would confound Congress, as it always has with telecom regulation.  The FCC was created to apply expert judgment to the details of regulating a technical industry, and we need to let them do that.

The thing that’s clear is that “no fast lanes” has become a flag-waving slogan for everyone, and fast lanes might have been the best thing ever for the Internet.  No matter what consumers think/want or regulators do, you can’t legislate or regulate an unprofitable operation for very long, and we’ve closed down the clearest avenue to profit for ISPs.  Not only that, we’ve closed down the only avenue that would have made generating bits a better business.  Cisco and others should be wearing black armbands on this one because it decisively shifts the focus of networking out of L2/L3 and either upward into the cloud or downward into optical transport on the cheap.

The administration should have stayed out of this; by making a statement on neutrality the President made it a political issue, and in today’s world that’s the same as saying we’ve foreclosed rational thought.  We can only hope the FCC will enforce its policies with less political bending and weaving than it’s exhibited in setting the policies in the first place.

The cloud and NFV have a lot in common.  Most NFV is expected to be hosted in the cloud, and many of the elements of NFV seem very “cloud-like”.  These obvious similarities have been explored extensively, so I’m not going to bother with them.  Are there any other cloud/NFV parallels, perhaps some very important one?  Could be.

NFV is all about services, and the cloud about “as-a-service”, but which one?  Cloud computing in IaaS form is hosted virtualization, and so despite the hype it’s hardly revolutionary.  What makes the cloud a revolution in a multi-dimensional way is SaaS, software-as-a-service.  SaaS displaces more costs than IaaS, requires less technical skill on the part of the adopter.  With IaaS alone, it will be hard to get the cloud to 9% of IT spending, while with SaaS and nothing more you could get to 24%.  With “platform services” that create developer frameworks for the cloud that are cloud-specific, you could go a lot higher.

NFV is a form of the cloud.  It’s fair to say that current conceptions of function hosting justified by capex reductions are the NFV equivalent of IaaS, perhaps doomed to the same low level of penetration of provider infrastructure spending.  It’s fair to ask whether there’s any role for SaaS-like behavior in NFV, perhaps Virtual-Network-Function-as-a-Service, or VNFaaS.

In traditional NFV terms we create services by a very IaaS-like process.  Certainly for some services that’s a reasonable approach.  Could we create services by assembling “web services” or SaaS APIs?  If a set of VNFs can be composed, why couldn’t we compose a web service that offered the same functionality?  We have content and web and email servers that support a bunch of independent users, so it’s logical to assume that we could create web services to support multiple VNF-like experiences too.

At the high level, it’s clear that VNFaaS elements would probably have to be multi-tenant, which means that the per-tenant traffic load would have to be limited.  A consumer-level firewall might be enough to tax the concept, so what we’d be talking about is representing services of a more transactional nature, the sort of thing we already deliver through RESTful APIs.  We’d have to be able to separate users through means other than virtualization, of course, but that’s true of web and mail servers today and it’s done successfully.  So we can say that for at least a range of functions, VNFaaS would be practical.

From a service model creation perspective, I’d argue that VNFaaS argues strongly for my often-touted notion of functional orchestration.  A VNFaaS firewall is a “Firewall”, and so is one based on a dedicated VNF or on a real box.  We decompose the functional abstraction differently for each of these implementation choices.  So service modeling requirements for VNFaaS aren’t really new or different; the concept just validates function/structure separation as a requirement (one that sadly isn’t often recognized).

Managing a VNFaaS element would be something like managing any web service, meaning that you’d either have to provide an “out-of-band” management interface that let you ask a system “What’s the status of VNFaaS-Firewall?” or send the web service for the element a management query as a transaction.  This, IMHO, argues in favor of another of my favorite concepts, “derived operations” where management views are synthesized by running a query against a big-data repository where VNFaaS elements and other stuff has their status stored.  That way the fact that a service component had to be managed in what would be in hardware-device terms a peculiar way wouldn’t matter.

What we can say here is that VNFaaS could work technically.  However, could it add value?  Remember, SaaS is a kind of populist concept; the masses rise up and do their own applications defying the tyranny of internal IT.  Don’t tread on me.  It’s hard to see how NFV composition becomes pap for the masses, even if we define “masses” to mean only enterprises with IT staffs.  The fact is that most network services are going to be made up of elements in the data plane, which means that web-service-and-multi-tenant-apps may not be ideal.  There are other applications, though, where the concept of VNFaaS could make sense.

A lot of things in network service are transactional in nature and not continuous flows.  DNS comes to mind.  IMS offers another example of a transactional service set, and it also demonstrates that it’s probably necessary to be able to model VNFaaS elements if only to allow something like IMS/HHS to be represented as an element in other “services”.  You can’t deploy DNSs or IMS every time somebody sets up a service or makes a call.  Content delivery is a mixture of flows and transactions.  And it’s these examples that just might demonstrate where VNFaaS could be heading.

“Services” today are data-path-centric because they’re persistent relationships between IT sites or users.  If we presumed that mobile users gradually moved us from being facilities-and-plans-centric to being context-and-event-centric, we could presume that a “service” would be less about data and more about answers, decisions.  A zillion exchanges make a data path, but one exchange might be a transaction.  That means that as we move toward mobile/behavioral services, contextual services, we may be moving toward VNFaaS, to multi-tenant elements represented by objects but deployed for long-term use.

Mobile services are less provisioned than event-orchestrated.  The focus of services shifts from the service model to a contextual model representing the user.  We coerce services by channeling events based on context, drawing from an inventory of stuff that looks a lot like VNFaaS.  We build “networks” not to support our exchanges but to support this transfer of context and events.

If this is true, and it’s hard for me to see how it couldn’t be, then we’re heading away from fixed data paths and service relationships and toward extemporaneous decision-support services.  That is a lot more dynamic than anything we have now, which would mean that the notion of service agility and the management of agile, dynamic, multi-tenant processes is going to be more important than the management of data paths.  VNFs deployed in single-tenant service relationships have a lot of connections because there are a lot of them.  VNFaaS links, multi-tenant service points, have to talk to other process centers but only edge/agent processes have to talk to humans, and I shrink the number of connections, in a “service” sense, considerably.  The network of the future is more hosting and less bits, not just because bits are less profitable but because we’re after decisions and contextual event exchanges—transactions.

This starts to look more and more like a convergence of “network services” and “cloud services”.  Could it be that VNFaaS and SaaS have a common role to play because NFV and the cloud are converging and making them two sides of the same coin?  I think that’s the really profound truth of our time, NFV-wise.  NFV is an accommodation of cloud computing to two things—flows of information and increasing levels of dynamism.  In our mobile future we may see both services and applications become transactional and dynamic, and we may see “flows” developing out of aggregated relationships among multi-tenant service/application components.  It may be inevitable that whatever NFV does for services, it does for the cloud as well.

I’ve noted before that the weak link in NFV is operations, or management if you prefer.  A big part of the problem, IMHO, is the need for the ISG to contain its efforts to meet its schedule for completing its Phase One work.  Another issue is the fact that the body didn’t approach NFV from the top down.  Management is a problem because so much of NFV’s near- and long-term value proposition depends on efficient operations.  Service agility means accelerating the service lifecycle—management.  Capex reductions are useful only if you don’t add on so much additional opex due to increased deployment complexity that you swamp the savings.

I’m not the only one who feels there’s a major issue here.  Last spring operators told me that they didn’t have confidence that they could make the business case for NFV and that management was the issue.  Some of their concerns are percolating into visibility in the industry now, and so I think we should do what the ISG didn’t and look at NFV management top-down.

To me, there two simple high-level principles in play.  First, NFV infrastructure must, at the minimum, fit into current network operations and management practices.  Otherwise it will not be possible to replace physical network functions with virtual functions without changing operations, and that will stall early attempts to prove out benefits.  Second, to the extent that NFV is expected to deliver either service agility or operations efficiency benefits, it must provide improved operations practices that deliver sufficient efficiency impact overall.

If we step down from the first of these, we can see that the immediate consequence of harmony with existing practices is management equivalence between VNFs and PNFs.  I think this requirement was accepted by operators and vendors alike, and their response was the notion of the VNF Manager.  If you could collect the management data from the VNFs you could present it to a management system in the same form a PNF would have presented it.  Thus, if you bind a VNFM element into a set of VNFs you can fill my first requirement.

Sadly, that’s not the case.  The problem here is that virtualization itself creates a set of challenges, foremost of which is the fact that a PNF is in a box with local, fixed, hardware assets.  The associated management elements of the PNF know their own hardware state because it’s locally available to be tested.  If we translate that functionality to VNF form, we run the functions in a connected set of virtual machines grabbed ad hoc from a resource pool.  How does the VNF learn what we grabbed, how to interpret the status of stuff like VMs and hypervisors and data path accelerators and oVSs that were never part of the native hardware?  The fact is that the biggest management problem for NFV isn’t how to present VNF status to management systems, it’s how to determine the state of the resources.

The problem with resource management linkage has created a response, of course.  When vendors talk about things like “policy management” for NFV what they are often saying is that their architecture decouples resources from services explicitly.  I won’t worry about how a slew of servers and VMs look to a management system that expects to manage a physical CPE gateway because I’ll manage the resources independent of the service and never report a fault.  Great, but think of what happens when a customer calls to report their service connection is down, and your CSRs say “Gee, on the average we have 99.999% uptime on our virtual devices so you must be mistaken.  Suck it up and send your payment, please!”

There are services like consumer broadband Internet that can be managed like this, because that’s how they’re managed already.  It is not how business services are managed, not how CPE is managed, not how elements of mobile infrastructure are managed.  For them, I contend that the current approach fails to meet the first requirement.

And guess what.  The first requirement only gets you in the game, preventing NFV from being more costly and less agile than what we have now.  We are asking for improved operations efficiency, and that raises two new realities.  First, you can’t make meaningful alterations to opex by diddling with one little piece of a service.  Just like you can’t alter the driving time from NYC to LA by changing one traffic light’s timing.  Second, you can’t make meaningful alterations to even a piece of opex if you don’t do anything different there.  We have decoupled operations and network processes today and if we want service automation we have to make operations event-driven.

Event-driven doesn’t mean that you simply componentize stuff so you can run it when an event occurs.  Event-driven processes need events, but they also need state, context.  A service ordered and not yet fulfilled is in (we could say) the “Unactivated” state.  Activate it and it transitions to “Activating” and then becomes “Ready”.  A fault in the “Activating” process has to be remedied but there’s no customer impact yet, so no operations processes like billing are impacted.  In the “Ready” state the same fault has to do something different—fail over, invoke escalation, offer a billing credit…you get the picture.

What is really needed for NFV is data-modeled operations where you define a service as a set of functional or structural objects, assign each object a set of states and define a set of outside events for each.  You then simply identify the processes that are to be run when you encounter a given event in a given state.  Those processes can be internal to NFV, they can be specialized for the VNF, they can be standard operations processes or management processes.

State/event is the only way that NFV management can work, and it makes zero sense to assume that every VNF vendor would invent their own state/event handling.  It makes no sense that every vendor would invent their own way of accessing the status of underlying resources on which their VNFs were hosted, or that operators would let VNF-specific processes control shared-tenancy elements like servers and switches directly.  We can, with a single management strategy, fulfill both the resource-status-and-service coupling needs of NFV (my first requirement) and the operations efficiency gains (my second).  But we can’t do it the way it’s being looked at today.

This shouldn’t be about whether we have a VNF-specific model of management or a general model.  We need a state-event model of management that lets us introduce both “common” management processes and VNF-specific processes as needed.  Without that it’s going to be darn hard to meet NFV’s operations objectives, gain any service agility, or even sustain capex reductions.  All of NFV hinges on management, and that is the simple truth.  It’s also true that we’re not doing management right in NFV yet, at least not in a standards-defined way, and that poses a big risk for NFV deployment and success.