Author: CIMI

It’s pretty clear to me from comments I’ve gotten in my blog that there are a lot of questions out there on the topic of management or operations.  When we talk about things like SDN and NFV we can talk about management practices in a general way, but we can really only talk “operations” if we can integrate management practices with business practices.  So today let’s take a look at the topic and see if we can sort out a framework for evaluating the needs of new network technologies.

You can group services into two broad classes—assured and best-efforts.  Assured services are those that guarantee some level of service quality and availability and best-efforts are services that…well…just expect the operator to do their best to get something from point “A” to point “B”.

Best-efforts may not have a hard standard of quality or availability, but it’s not “no-effort”.  An ISP who had significant numbers of delivery failures could never survive in a competitive market, so independent of the service classes above there’s still a general need to manage network behavior so as to get most stuff to its destination.

Here we can also say there are two broad approaches, provisioned QoS and engineered QoS.  The former means that a service is assigned resources according to the service guarantees made, and sustaining those guarantees means validating whether the committed resources are meeting them.  The latter means that we play a statistical game.  We engineer the infrastructure to a given probability of packet loss or mean delay or failure rate/duration, and we understand that most of the time we’ll be OK.  Sometimes we won’t.  In all cases, though, what we’ve done is to calculate the service quality based on resource conditions.  We assure resources against the parameters that we define as “good-enough-effort” for a given service, not the services themselves.

Where we have provisioned QoS, we assure services specifically and we do resource substitution or adaptation based on service events.  Where we have engineered QoS, we build a network to operate within statistical boundaries, and we respond to conditions with what?  Generally, with policy management.  Policies play two broad roles—they insure that the resources are operating within their designed limits through traffic admission controls, and they respond to internal conditions by applying predefined broad remedies.

So can we apply this to SDN and NFV?  Let’s see.

In the case of SDN, the immediate problem we have is in the definition of SDN.  Does SDN mean “software defined” in the sense that network behavior is centrally software-managed without local device adaptation (the original notion) or do we mean it’s “software controlled” meaning that software can control network behavior more precisely?

If SDN is the former, then we have a bicameral model of service behavior.  We have real devices (whether they’re hosted/virtual or physical) that have to be running and working in order for traffic to be passed from place to place, and we have central route/forwarding control that has to be right or packets fly off to the wrong places or into the bit bucket.  The advent of central forwarding control means that we know the rules in one place, the routes in one place, but it doesn’t mean we’re less dependent than before on retrieving and delivering status information.  In fact, one of the biggest issues in centralized SDN is how you secure management connectivity at all times without adaptive behavior to provide default paths.  Without management connectivity you don’t know what’s going on, and can’t do anything about it.

In the software-controlled model, we presumably still have adaptive behavior and thus have default routing.  Arguably this model means, in management terms, that we are providing more service-centricity while sustaining essentially an adaptive, policy-managed resource set.  It’s my view that any software-controlled SDN models are really models that will ultimately rely on better (more granular in terms of services and service grades) policy control.  This model relies more on predictive analytics for one simple reason; if you can’t figure out exactly how a given service will impact resources and thus other services, you can’t reliably provide for software control at the service and application level (which is the only meaningful place to provide it).  So we do traffic engineering on service/application flows based on understanding network conditions and how they’ll change with the introduction of the new service/flow.

In the central-control model, we can still use predictive analytics but we also have to provide the baseline assembly of route status and traffic patterns that come from our two previously mentioned sources.  However, we’ll use this information not to manipulate routes or queues but rather in creating/connecting paths for specific services or flows.  We may also use policy management, but more in the form of automated service responses to resource events.  There are plenty of early SDN examples of predefining failure modes to create fast transitions from a normal state to a failure-response state when something goes wrong.

I think it’s clear from SDN that we do have a role for analytics and also a role for policy management in the models.  How about NFV?

NFV replaces boxes with software/hosting pairs, much as centralized SDN would replace switching/routing with OpenFlow switches and central software.  You would have to manage NFV elements just as much (though not necessarily in the same way) as we’d managed real devices in the same mission before NFV came along.  We can’t manage the resources on which we host virtual functions and assume that the software is perfect, any more than we could presume in SDN that just because all our OpenFlow switches were running fine, we had coherent forwarding rules to deliver traffic or operating software centrally or in the devices.  If the services are provisioned per-user, though, then service management in a virtual world doesn’t necessarily change much because a service event can trigger a resource-assignment-remediation response.

But NFV adds a problem dimension in that a virtual device may have properties that real ones didn’t.  Scalability and repositioning are examples of this.  So I have an additional dimension of things that might get done, and there’s arguably a policy-management and even analytics link to doing them.  Scale-in/out and redeployment on command are management functions that can be automated responses to events.  Is that policy management?

To me, this is the core of the whole story of SDN/NFV management.  We are really talking about service automation here, even today before we have either SDN or NFV much in the picture.  Today, most service automation is either applied at the OSS/BSS provisioning level or exercised through policy management (admission control, grade-of-service assignment).  In the mobile world we have those tools.  The place where we might be going wrong is in assuming that the mobile world gives us the only example of how we implement policy management.  I think the best thing to do here is to say that we’re heading for a future of service automation and that this future automation strategy will draw on traffic data, past and present, and device status (also past and present) in some measure to make machine decisions about how to handle conditions in real time.  If we apply service automation to the same kinds of services we provide today’s PCC-based policy management or path computation functions to, we could well have the same implementation.  But all future NFV and SDN management missions don’t map to this basic model, and that’s why we have to try to expand our conception of management when we expand into SDN and NFV.

Generally, the realities of online journalism will tend to exaggerate everything.  A development, to be press-worthy, has to be either the single-handed savior of Western Culture, or the last bastion of International Communism.  NFV has gone through this gamut, and it seems like a lot of the recent stories are skeptical if not negative.  My number one prediction for 2014 is that the hype on NFV will explode, and even more reality will be swept under the rug of generating buzz and URL clicks.  So let’s look at where we really are.

First, the ETSI ISG’s work won’t complete till January 2015 so we’re a year from being done.  However, the framework of the architecture is in place at this point and so we know what NFV will look like as an implementation.  Vendors (and even operators) who really don’t want to do NFV may use the incomplete ETSI ISG process as an excuse, but it’s lame.  Those who are taking itty bitty NFV steps are doing that because they want to.

Second, the ISG’s work, in a formal specification sense, will increasingly be linked to forma proof-of-concept work that aligns implementation reality with specifications.  I’ve said many times that a five-hundred-page spec won’t write code and can’t be deployed on anything.  At some point NFV has to become software—in fact two levels of it (I’ll get to that next).  I can’t overstate how critical it is for implementations of NFV to be played with now, so there’s time to adapt the specifications to reflect optimum implementation practices.  I said that before this process ever got started, back in October 2012 and it’s just as true today.  We need prototypes.

Third, there are really two parallel NFV issue sets.  “Network Functions Virtualization” equals “Network Functions” plus “Functions Virtualization”.  Network functions are the things that will be run, and functions virtualization is the process of deploying and managing them.  Both are software, and we need to understand that the requirements for the two are interdependent.

For example, there are literally tens of thousands of open-source packages out there that might be harnessed as network functions, but they were not written to be deployed through NFV.  If we can adapt how they work now to NFV principles we have a rich inventory of stuff to start NFV off right.  If we can’t, then not only do we have to write virtual functions, we have to agree on the specialized interfaces and programming practices we decide are necessary.

Fourth, NFV isn’t enough.  When all this started, operators were thinking that they could deploy custom appliances as virtual functions and save opex based on the difference in cost between a proprietary appliance and a hosted function.  Well, look at home gateways as an example.  You can pick up one for forty bucks in Office Depot.  Mine has worked for at least five years, so the amortized capital cost (less cost of money and accounting mumbojumbo) is eight dollars.  Do you think an operator could deploy and host something like that for seventy cents a month?

Operators I’ve talked with and surveyed now agree that the value of NFV will come from its ability to reduce opex and to accelerate service velocity.  But NFV in the original strict host-appliance-logic-in-VMs form doesn’t address enough of the total service infrastructure to have massive impacts on either one.  What’s important is that NFV illustrates the need for virtualization of all the service lifecycle processes in order to be cost-efficient, and the way that’s done could revolutionize service management overall, even extending beyond “functions virtualization” into legacy infrastructure.

The next point, related, is that NFV is about managing virtualization in all dimensions.  Virtual functions, hosted in the cloud, and morphed into virtual service experiences is a lot of virtualization to manage.  Several years ago, the TMF actually framed the technical dimensions of the solution with their integration model (GB942).  The core insight there was that a complete abstract model of the service (the “contract”) has to represent the component and resource relationships in deployment, operations, and management.  Virtualization is a combination of creating valuable abstractions that are generalized to be flexible and agile, and then instantiating them optimally when they’re needed.  That doesn’t mean that NFV is about specific modeling or graphing, it’s about creating a useful abstraction in abstract.  How we then describe it in machine terms is an implementation finesse.

My next point is that NFV is an ecosystem.  You hear every day about this company or that who has “demonstrated NFV” and 99% or more of this is exaggeration.  You don’t demonstrate a race car by showing somebody a nut and bolt.  Every component of NFV already exists somewhere in some form, so trotting one out doesn’t make you an NFV player.  The ISG has published end-to-end specifications in early form, and those identify the functional elements of “real” NFV.  That which can address all these elements is “NFV” and that which cannot is simply a collection of some of the stuff that is included in “real” NFV.  We don’t need some of it, we need all of it.

The final point is openness.  The original target of NFV was replacement of purpose-built, proprietary, boxes by open virtual functions.  Operators don’t want to go from an age where vendors held them up for high-margin middle-boxes to an age where the same vendors hold them up for high-margin virtual functions.  What makes something “open” is the ability to freely substitute components at key places without having to re-integrate or re-program everything.  The ISG can do a lot to assure openness within its scope, but if most of the value of NFV comes from operations efficiencies and service agility that spreads out to cover all of the service management process, then all of that has to be open for openness to matter.

NFV is making good progress.  Yes, there are critical issues to be faced but they’re not the ones being talked about.  Most critical is the proof-of-concept stuff; we will never get this to happen without running prototype implementations and that is the absolute truth.  So if you hear an NFV story from a vendor, ask if they’re supporting a PoC.  If you hear speculation about implementation issues or the value of NFV, ask if the person doing the speculating is working on a prototype to develop their points.  And pay no attention to people who aren’t really involved in this, because they don’t know what’s real.  That’s my advice for what’s going to be a hype-ridden 2014.

This is always the time of year when you’re supposed to look into the crystal ball and talk about the near-term future.  OK, one of the areas we need to be watching in 2014 is metro.  I’ve noted in prior blogs that metro-area networks are critical because the majority of profitable traffic both originates and terminates in the same metro area, and that percentage is on the rise rather than declining.  I also want to point out that if you believe in “carrier cloud” you have to believe in a radical increase in metro volumes, and that NFV is the crowning factor in the “metro-ization” of infrastructure planning.  To understand where networking is going in 2014, where metro is going, we need to look at these factors.

Most of the valuable content we see today comes not “over the Internet” in a topological sense but rather from a content delivery network cache point that’s actually inside the metro network of the viewer.  This is because the high-value content is highly reused, which means it makes sense to keep a copy in all the metro caches where it can be delivered quickly and with a lower drain in network resources.  That’s not going to change, and as Amazon Prime or Roku or Google or Apple TV take hold, we’re going to see even more local video delivery.  Video is the primary source of traffic growth.  That means that the majority of the capacity growth we should expect in the coming years will have to be growth in metro capacity—user to cache.

Then we have the cloud.  Some, perhaps, might propose that cloud-created services could originate in some giant data center in the center of the country or (as Amazon’s model defines) regional centers.  That’s true in the early low-penetration days of the cloud, but if the cloud is successful on a large scale then there’s no further economy of scale in centralizing the large data center demand.  You regionalize, then metro-ize it, for the same reason you cache video.  It makes no sense to haul traffic a thousand miles to get to a data center when you have the cloud opportunity in any respectable metro to justify a local data center.

And more than one, almost surely, in any populated metro.  The Erlang efficiency of a data center plateaus as it grows, to the point where you may as well subdivide it further to improve resiliency and also to improve transport utilization.  Again, I point out that we routinely “forward cache” popular content so there are multiple copies in any given metro area, at different points.  Thus, as cloud grows we would expect to see a growing number of data centers in each metro area, linked by their own “cloud intranet”.

Where NFV comes in is twofold.  First, NFV postulates the substitution of hosted virtual functions for physical middle-box appliances.  Some studies suggest that there are as many middle-boxes as access devices; my own model says that about 28% of network devices fit into the middle-box category, but that these represent 35% of network capex.  This would clearly increase the data center demand in the metro, and since middle-box services tend to be best offered near the point of user attachment (you want a firewall close to the user, for example) it makes sense to assume that NFV would encourage distribution of hosting closer to the edge.  This is why operators have told me they would be installing servers “everywhere we have real estate”.

Second, and in my view most importantly, NFV is the architecture to create OTT-like new services for operators.  It makes no sense for operators to adopt the OTT model of basic web-hosting for their services; they can differentiate themselves on integration of services and on quality of experience if they can automate their own operations practices to deliver this stuff at a good price.  And remember, even without an FCC-hinted reform of neutrality rules, the operator cloud would be immune from neutrality rules.

What, you say?  Yes, even in the original neutrality order, things like cloud and content services are exempt from neutrality within their infrastructure boundaries.  You have to deliver content using neutral principles, but inside the CDN you can prioritize or do whatever you like.  That means that as we push “the cloud” close to the edge for cloud service and NFV reasons, we create a model of service where neutrality is an inch deep.  You have to obey it from the user’s home/business to the edge of the cloud, but no further.  You can move all kinds of stuff around inside the cloud, any way you like, as non-neutral as pleases your business model.

That’s the key metro point, I think.  Even if operators can’t immediately benefit from metro-izing their planning for profit reasons, they are experts at planning for regulatory optimality.  Build a metro cloud, dear carrier, and you have nothing further to worry about with neutrality.  And how many OTTs will build metro clouds?  The ultimate differentiator is within their grasp, and they’re driven to it by reduced costs (optimal use of data centers and transport), improved revenues (new services build on cloud and NFV), and regulations (you don’t share with anyone and you can charge for QoS inside the cloud).

This is the risk that infrastructure evolution poses for vendors.  It’s not SDN sucking the adaptive heart out of Ethernet or IP, but metro sucking all the dollars into a part of the network where “transport” means nothing more than connecting data centers with superfat (likely fiber) pipes.  If all the traffic is staying so close you can climb a tall tree and see its destination, how much core routing do you need?  In fact, it becomes easy for SDN principles to take hold in a metro-dominated world because the fact is that you have a very simple connection mission to manage—everyone goes to the nearest cloud edge and is subducted into the magma of NFV.

This isn’t going to happen in 2014, obviously.  It’s going to start in 2014, though, and we’ll probably see who gets it and who doesn’t by the end of next year.  That will determine who we’ll see around, alive, and prospering beyond 2015.  Vendors, standards bodies, network operators, everybody.  The metro could be the real revolution, and revolutions are…well…Revolutionary.

There have been some LinkedIn discussions regarding my blog on Juniper’s Wandl buy, and some comments have opened the broader question of whether policy management and path computation might be a factor in the deal, even to the point where they might be incorporated into Juniper’s Contrail SDN controller as a result of the buy.  So the question is whether 1) there’s a link between traffic analytics and path, policy, or SDN control, 2) whether this might be behind the Juniper buy, and 3) if so, is it good enough reason.  To get to these answers we’ll have to excurse a bit into Cisco’s Cariden deal as well.

At a very high level, there are two views of how networking will evolve.  In one view, current adaptive network protocols and devices are enhanced to make networks more responsive to business and application needs.  Think of it as “adapting with boundaries”.  In the other, we step away from the notion of adaptive network behavior in favor of more explicit and centralized control.  You might have expected that we would argue this was the “legacy versus SDN” choice, but both sides call their approach “SDN” so we’re kind of deprived of that easy out.

There are also two views of what drives “evolution” of networks.  In one view, it’s driven by traffic.  The goal of networking, under this view, is to handle traffic efficiently so as to reduce the overall cost of both network equipment and network operations.  In another view, evolution is driven by services, meaning differentiable things that can be sold.  This particular dipole could be called the “Internet versus managed services” or “dumb versus smart”, but everyone salutes the Internet and nobody wants to be dumb so that characterization isn’t helpful either.

We can also say that there are two visions of where we care about any of the other visions.  One says that the “core” is the heart of the network and that big iron and bit-pushing are what it all comes down to.  The other says that the great majority of profit today, and credible future profit, would involve services with traffic topologies that span a single metro.  They say that revenue per bit in the core is the worst in the industry, so why invest there.  Their opponents say that’s why you have to invest there.  Users don’t care because they don’t understand how we build networks anyway.

What everyone sort of agrees on is that you have to optimize something, somewhere and that’s likely to demand that you understand what’s going on.  So we can presume that there would be a kind of marriage of data-gathering and analytics that would present a vision of operations, likely now and in the past, and would be able to support decisions of some sort based on that vision.  We could apply that knowledge in a number of ways, and in fact we could use it to support any of the poles of any of the visions we’ve cited here.

Traffic engineering in the core of an IP network is usually accomplished using MPLS, through a process of path computation.  That means that you can use traffic knowledge to drive PCE processes that would optimize handling in an IP core, and Wandl or Cariden can certainly be used that way.  You could also use the traffic knowledge to drive a wider scope of policy management processes in the network, even perhaps out to the edge, to increase the span of control.  So Wandl could be used for that too.

In a centralized SDN model where we replace traditional adaptive IP with something else, the presumption is that the central control process is what manages paths, so it’s that process that needs the knowledge of traffic.  Since Wandl (and of course Cariden and other Wandl-competitors) can provide traffic knowledge, it could be used to couple that knowledge to an SDN controller.  In fact, if we presumed that SDN devices, lacking adaptive behavior, might also lack some of the traffic knowledge that’s necessary to do adaptive routing, you could argue that SDN might need traffic knowledge more than legacy networks would.

What all of this adds up to is that you can in fact say that traffic analytics are useful whether you’re thinking SDN or legacy, core or metro.  So we answer our first question.

Could Juniper have thought this was a good reason to buy Wandl?  Here, of course, we’re getting into something very subjective and somewhat unknowable, which is how any vendor thinks about something.  Certainly it might be useful to have multi-vendor traffic/network analytics given that virtually every carrier network is multi-vendor.  And $60 million isn’t a lot of money these days; Apple bought social-media analytics company Topsy for five times that much.

My problem is that this is the kind of “so cheap I can’t refuse it” justification, which isn’t enough.  The best strategy for Juniper would seem to be to provide a data-gathering interface to any analytics platform out there rather than to seize on a single one and hope it’s adopted universally by operators.  They could do that with Wandl, with whom they already have a partnership.  So just “getting” the data doesn’t seem to be enough of a reason to buy them.

We could say that Juniper bought Wandl because Cisco bought Cariden, but while that’s possible in one sense it’s illogical in another.  Cisco needs to minimize the SDN revolution at all costs because they’re the networking establishment.  We’re in a market that thinks that analytics, even if you don’t do anything different with the results, is a revolution.  So add analytics to POIPN (Plain Old IP Neworking) and you have SDN?  As I’ve said before, you can affect software control without centralization, OpenFlow, or any of that stuff.  That’s been Cisco’s angle.

The problem is that it can’t be Juniper’s.  You can’t become a come-from-behind winner in traditional networking by aping every move of the market leader, unless you want to be a price leader.  Guess who’s the price leader?  Huawei.  Juniper needs to take SDN further, take networking further, if it wants to gain market share on Cisco.

We can’t say whether Juniper believes that Wandl will suddenly make it a market leader, but if they do they’re delusional.  More is needed, and so we’ve answered our last questions.  But that obviously raises another, which is what “more” might be.

To me, both SDN and NFV signal that operators believe that there’s a fundamental problem with the notion of uncontrollable, adaptive, networking.  That problem isn’t just “utilization” either because fiber improvements are making it possible to lower the cost of transport bit-pushing.  The problem is that this model of networking is associated with commodity connectivity and that’s never going to be profitable enough for deregulated operators to survive on.  I’ve heard all the presentations about how the price/cost line on bit-pushing is about to cross.  They’re right.  You can slow the process a little by fiddling with utilization or fiddling with capital costs, but in the long run even opex enhancements aren’t enough.  You have to sell more, which means you have to create networks that are subservient to services.  That starts at the top, where the services are, which is why the cloud and NFV are important.

I think Cisco knows this, and they’re just waiting for the right moment to jump off the old bits and onto the new.  Cariden is useful to them while they’re in titular denial.  The question is whether Juniper sees the future too, and Wandl doesn’t answer that question.

Oracle’s numbers came out, and they were good after a run of misses.  One of the obvious questions raised by Oracle’s success is whether it’s Oracle’s success or a sign of secular recovery in software or in tech.  Let’s look at some of the signals to find out.

This tends to be Oracle’s best quarter; they did well at this point last year as well.  Our surveys and model say that companies are tending to push tech spending to the second half to counter economic uncertainties, and also that they want to get any upgrades done before the holiday season.  Software sales were up 5%, new software licenses up 1%, and the company reported very strong growth in their cloud portfolio and in “engineered systems”, the appliance space.  Hardware, meaning servers, continued to be a disappointment.

One thing I think comes out of the Oracle call loud and clear is that systems/servers are a very tough business to be in.  If you think about the notion of network functions virtualization, which is to shift features from network appliances to commercial-off-the-shelf servers (COTS), you realize that the notion of COTS is what’s fundamental here.  COTS could as easily stand for “Commodity off-the-shelf”.  Software, particularly open-source Linux, has tended to commoditize server platforms because it limits differentiation in everything but price.  This puts companies like HP and IBM, who have large hardware exposure, in a tight position.  They need to have strong software stories, but the promotion of software could arguably be driving a nail in the hardware coffin.

One solution to this, the one Oracle is promoting, is the “engineered system” or appliance.  By sticking software and hardware into a single package you create something that’s feature-differentiable.  Clearly this is working for Oracle at this point, and I think that’s largely because the transition to virtualization at the hardware level (including the cloud) demands thinking of database as a service, which promotes the notion of an appliance as the source.  We’re only at the beginning of the cloud revolution (we’ve addressed less than 10% of the near-term market potential) so Oracle can ride this horse for some time yet.

In the longer run, though, you have to look at networking and NFV/SDN for inspiration.  If operators are trying to convert network appliances into combinations of software and COTS, then database or transaction appliances are just circling the drain a bit higher in the bowl.  Probably by 2018 it will be difficult to promote “cloud appliances” and that’s largely because network operators are creating the framework to couple software features to hardware in a more automated, elastic, and manageable way with NFV.  It’s not going to happen quickly (certainly not in the next year, probably not the next two) but it will happen.  When it does, it will gradually percolate out of operator infrastructure and into the cloud and the enterprise.

A second point from the Oracle call is the supremacy of “intrinsic margins”.  The market that you need to own is the one with the highest profits.  In the cloud, that’s the top of the service food chain—SaaS.  Oracle has always liked the SaaS space because SaaS displaces the most cost and because Oracle thought (correctly, I think) that they could gain market share on competitors like SAP who were reluctant to go all-in on a hosted-software model.  If you can offer your software as a service, buyers don’t care about the underlying platform and hardware at all, which means that you can use your own stuff there to augment your profits and that you tend to commoditize PaaS and IaaS offerings of others.

Oracle’s weakness in the cloud, potentially speaking, is that the real future of the cloud isn’t even SaaS as much as it is cloud-specific applications based on platform services.  Amazon has the right idea in cloud evolution from the IaaS model.  You augment basic cloud with all kinds of neat web-service additions that create in effect a cloud-resident virtual OS.  People write to that to get the special cloud features you’ve included, and the next thing you know we don’t write apps for hardware any more—but for the cloud.  If Amazon continues this push and Oracle doesn’t counter it, they risk having software developers rush to Amazon and create SaaS offerings there that transcend anything that Oracle or anyone else could create using traditional IT elements.

Oracle has a combined point of weakness in the network.  It’s a weakness in appliances because NFV is an anti-appliance move and Oracle’s not particularly an NFV player despite the hype that Tekelec and Acme make it one.  Having virtual functions is having software components; what makes NFV is the orchestration and management.  Networking is also a weakness because arch-rival Cisco is a network giant and a competitor to Oracle in the cloud, and both IBM and HP have either their own network products or OEM products there.  The cloud is as much networking as it is IT, so if Oracle wants a secure bastion there they have to create a position in the space, preferably one that denigrates competitive incumbencies.  Both SDN and NFV would do that, and so Oracle needs to do a lot in those spaces.

Insiders at Oracle tell me the company really seems clueless to exploit their Acme and Tekelec acquisitions.  Some say that they need to focus them on cloud UC.  Some say they need to get a broader NFV and SDN story, but that latter group (likely the ones who have the right answer) really has no easy strategic path forward because nobody in Oracle seems to be thinking much about either topic beyond slideware.

So here’s my net.  Oracle can’t be said to be signaling a general shift in IT.  We need more and broader data points and the others in the space did not provide them.  Oracle can be said to be signaling that a differentiable, margin-generating, story is better than one that presents commodity hardware and hopes for the best.  You can augment your sales effort (as Oracle has done) if you have something to say besides “we’re cheaper”.  But Oracle is still captive to broad commoditization trends, and it has to address them now while its margins will still support the investment.

AT&T has joined Verizon in spinning off some rural phone lines/customers that didn’t present a profit/revenue profile that matched their future requirements.  This trend, and others, is what has motivated the FCC to take up the issue of “transition”, and the outcome of the FCC’s review could have major impacts.  I noted the FCC’s intentions in a prior blog, and some of those intentions have now been made into concrete steps.  We just don’t know where those steps might be taking us.

The FCC had established a Technology Transitions Task Force to evaluate the impact of technology changes, obviously, but the fact is that it’s the business changes that demand attention.  Over the roughly twenty years since the Telecom Act of 1996 created our current framework of regulations, we’ve seen the price per bit of capacity drop by 50% per year.  That has made low-bandwidth services like voice something that could be offered over the Internet for literally nothing, and you can’t sell stuff in competition with things that are free.

The immediate result of the declining capacity cost has been to shift expensive calls off the bill, either by shifting them online or to unlimited-call plans.  Both these have capped and eventually pushed down ARPU on voice services.  At the same time the cost of providing baseline voice services has grown because of higher labor costs and because rural geographies are increasingly seeing growth of off-grid vacation homes and other low-density development that’s inherently more expensive to serve with wireline.

The TTTF report, issued December 12^th, recommended experiments on the way that consumers could be served by advanced technology options.  What this is really about is answering a single question—what can we do to transition TDM voice to something less expensive without creating any consumer risks along the way.  The option that operators would like is to transition it to mobile service because that could eliminate the whole issue of wireline voice, and move users to something that’s (at this point at least) still profitable.  Another option is to decide how you could provide VoIP to users who don’t have Internet access today because they don’t want it or can’t afford it.

Experiments will provide some comfort in saying that wireline voice and wireline voice carrier-of-last-resort obligations can be eliminated, and the fact is that they have to be.  We made a decision in 1996 to deregulate the industry, to eliminate the regulatory-monopoly model that was (some said) limiting innovation but (some said) was also protecting the investment in infrastructure.  Now we have a big chunk of telco budgets spent providing a service that almost everyone thinks is a dinosaur—POTS.

The larger question that the FCC has to answer is relating to the rest of the transitional issues, and I don’t mean the simple wireline/wireless or copper/fiber issues.  Those aren’t issues at all, they’re simply market shifts that are really out of policy-makers’ control.  The real issues relate to whether you can have an industry that’s half-regulated.  The Telecom Act didn’t repeal the Communications Act of 1934, it simply amended it.  There are still universal service obligations, E911 obligations, wholesale obligations, and other silly holdovers.  Most recently we initiated net neutrality regulations that go beyond guarantees of access to guarantee neutral network behavior under all kinds of conditions—guarantees that have kept QoS and settlement out of the Internet and limited the incentive to invest.  In the US and in Europe, operators are looking for other ways to make profits, and if they can’t do that in their home countries and core industries, they step outside one or both.  In Europe, many operators have their premier service experiments running in some other country, even continent.

But I think that the real issue for the FCC isn’t whether we can regulate an industry we deregulated at least in a titular sense.  We can’t and keep it healthy.  We need TTTFs not because technology changes are unusual and need special actions to deal with, but because we have created a rigid framework for an industry in one area and demanded it be flexible in another.  We have to regulate or deregulate.  I think that many in the FCC know this, and know that the experiments that are going to be run in 2014 are really aimed at defining the boundaries of “minimum regulation”, the level needed to protect consumers while letting the technology of the future drive the network of the future.

What is sad is that it’s taken us this long.  When we look back on FCC policies and FCC chairmen, I don’t think that the last Chairman we had will get high marks.  Genachowski was an activist at a time when networking needed a minimalist, and worse his activism was biased strongly against those who build the networks, not just build things that generate traffic like the OTTs do.  We need both business types to protect consumers, and we should never have taken regulatory positions that ended up favoring one type—particularly when without infrastructure there’s no services of any sort.

My fear is that this whole “experiment” thing will be another delay.  We already see the signs, in moves by players like AT&T and Verizon to spin off lines that aren’t going to be profitable, that the industry is developing serious structural problems.  Vendors like Cisco say that “macro” conditions are hurting their sales, but one of those conditions is that operators aren’t able to earn the same return on investment as OTTs do, and yet both operators and OTTs sell stock in the same markets and have the same shareholder concerns about growth.  We could have changed this industry three or four years ago by simply doing the right thing—either creating a true regulated monopoly again and regulating the outcomes we wanted, or letting the market do what comes naturally.  Markets divided against themselves can’t stand either, and we could fritter away the health of the industry taking baby steps now.

Juniper announced it was buying its long-time network monitoring and planning partner, Wandl.  Obviously this could indicate a strategic shift on Juniper’s part, particularly when you marry it with the departure of the “Microsoft camp” (CEO Kevin Johnson and software head Bob Muglia).  It could also mean nothing much, and it’s too soon to call this one definitively.

Wandl is a company that provides planning support for network operations by analyzing traffic data and network conditions.  Most people would put this in the “analytics” category rather than the “operations” category because the products don’t actively control network behavior in real time.  Operators in our survey put the company most often in the category of a capacity or network planning tool, which is an element of OSS/BSS but not the key element (service creation, order management, and service management in real time are the keys).

That doesn’t mean that Wandl couldn’t become part of a next-gen OSS (NGOSS) strategy, and this is where the Juniper decision to buy them gets interesting.  On the surface, Wandl as a partner contributes no less to Juniper’s portfolio than Wandl as a subsidiary element of Juniper.  There’s no reason why its sudden acquisition would generate a change in strategy, but it could be that the acquisition signals a change, or a competitive countermove.

If Juniper, hypothetically, were going to launch a major NGOSS-linked initiative that would make Wandl the centerpiece of a highly critical and profitable strategy, Juniper would likely immediately have two thoughts.  Thought One:  We are about to make these Wandl guys rich with the sweat off our backs marketing this NGOSS stuff, and why not buy them and keep all the money for ourselves?  Thought Two:  We are about to make these Wandl guys the center of a major Juniper strategy and Cisco just said they’re going to do software M&A!

All of this presupposes that Juniper is about to launch an aggressive NGOSS-linked strategy, and I don’t think that’s very likely.  OSS/BSS is an enormous undertaking, something that only a few giant players have gained any traction in marketing (Ericsson, Amdocs….)  Juniper has never had a horse in that race and has just been blowing kisses at the TMF whose stuff is the standards foundation for the space.  If  Juniper were going to do something with OSS/BSS on a large scale, I’d have thought they’d be advertising that in dialogs with operators, engagement in the standards processes, and so forth.  I don’t see any of that.  I also think that such a move would be nearly impossible to bring to fruition in the near term (fast enough to help their numbers in 2014) and it would be a giant project for a company that never got its software or even network management story straight in the past.

The other possibility is that Juniper has a reliance on Wandl for some of its capacity and network planning applications, and simply fears that another network vendor will grab them up.  Wandl is involved with equipment/networks from all the router/switch vendors and so it could very well be seen as an asset in a multi-vendor world.  But the problem with this story is that if Cisco was really seeing Wandl as critical they could certainly have outbid Juniper.

So where does this leave us?  One possibility is that Wandl is linked to some Juniper plan in the NFV arena.  NFV and SDN could (separately or together) create a kind of network/operations shim layer between classical OSS/BSS and the evolving network infrastructure.  For example, if you used this layer to make the whole network look like a single agile virtual device, you could express that device simply to current management systems and take up all of the special tasks associated with the next-gen network inside your virtual device—including management/operations (CloudNFV supports but doesn’t demand this model, for example).  This is kind of where I think Juniper must be headed with the Wandl deal, if there’s any strategic justification for it at all (a point I’ll return to in a minute).

It would be much easier for a network player like Juniper (or its rival Cisco, or even Alcatel-Lucent) to create an NGN shim layer than to become a true OSS/BSS player.  It’s not an impossible stretch to make a true NMS that’s SDN and virtualization-aware into such a layer, and it’s hard to imagine how you can stay in networking without a management model that can do something with SDN and function virtualization.  Otherwise you’re relying on a competitor to take the higher-level management role.

This would be a pretty interesting development if it were really behind the Wandl deal, but it’s hard to see where the genesis of this would have come from inside Juniper.  They’ve never had a strong operations story, their software story never gelled under Johnson/Muglia, and those two (particularly the latter) have made a rather quick departure.  Who takes over?  Logically it would be the Mad Scientist who was the founding father of this supposed Juniper shim-layer story, or somebody brought in.  Will some executive from Wandl be that somebody?  Their key people’s names aren’t even listed on their website nor are they provided by the major sources of executive and board information (the company is privately held).  I don’t know enough about who’s there to know who might be a candidate for a bigger role.  David Wang is the CEO, though, and if he suddenly takes a bigger role we’d know this was the angle for the deal.

The other possibility is that this is a small move.  Juniper, like other companies, sometimes buys partners just because they see it a sound financial step (the earnings are good) or because there’s a small risk that a competitor would make that small-step decision (Huawei is also a Wandl partner, for example).  Juniper has not made many (if any) successful strategic acquisitions, so it would be a stretch for them to make one now.

But if there was ever a time for it, this is the time.  The new CEO starts at Juniper in just a couple of weeks, and he’s going to have to hit the ground running.

I’m happy to report that the CloudNFV project’s Proof-of-Concept application to the ETSI NFV ISG has been approved.  We were the first group to make formal application, the first to be approved (as of today, we’re the only ones in either category, but I expect much more through the first quarter).  It’s a validation of CloudNFV, of course, and the work of our term.  It’s also a validation of the ETSI NFV work that launched our CloudNFV initiative back in the late fall of 2012.  Finally, it’s a validation of the work done by some service-modeling pioneers at the TMF, whose GB942 principles are the foundation not only of CloudNFV but of what I think is the only solution to managing virtualization—anywhere.

The ISG was born out of openness, the desire to open up services by replacing proprietary elements with hosted software, the desire to create the future by selecting among the best standards of the present, and most of all the desire to let the buyers of infrastructure define the playing field so the sellers (individually or collectively) could never dominate it again.  The ISG defined the issues, the use cases, the functional framework, for the future of networking.

CloudNFV from the first sought to build on the ISG work, to validate it within the broadest possible framework of service creation and operations, and to incorporate the other critical revolutions of our time—the cloud and SDN.  All this while not only sustaining but extending the open principles of the ISG.  We are not, nor have we ever intended to be, a “replacement” or “alternative” to the ISG’s approach.  We’re an implementation, an extension of their principles into adjacent domains where the ISG can’t realistically go because the scope is too large to hope to progress it in time.  Our extensions are based on the work of both the TMF (GB942 and GB922) and the IETF (i2aex).

We are a software architecture that has now become a software implementation.  We are running now; we have demonstrated that too many of the founding operators in the ISG.  Our goal is to develop a software framework that best meets the goals of operators, goals that include but are not limited to those of the ISG.  We are an open software architecture too; we’ve demonstrated that by launching a website, an integration program, a wealth of tutorial material.  We’ve also demonstrated it by the fact that our PoC includes not only the original 6 companies (my own CIMI Corp, 6WIND, Dell, EnterpriseWeb, Overture, and Qosmos) but two integration partners (Metaswitch and Mellanox) who have joined us through our open approach, and a TMF/OSS integration partner in Huawei, who has supported our operations evolution even without contributing technology to our platform.

The hard work of dozens of people in the ISG and the TMF are also foundations for what we’ve done even if their names aren’t on the PoC submission.  Two operators, Telefonica and Sprint, have agreed to sponsor our PoC, and the representatives of these operators are also key figures in the critical SWA and MANO groups within the ISG.  We don’t promise that we have or will conform completely to what any of these bodies develop, but we promise to present our approach, justify any differences, and work with all the bodies involved in good faith to come to the answer that’s best for the industry.

Our PoC is now posted on our website (see the link above) in keeping with our open approach.  It defines 16 scenarios to support its eight broad goals, so it’s no trivial NFV-washing.  These together define a framework in which we’ll prove out the initiatives of the NFV in an implementation that fully integrates with service creation, deployment, and management.  We’ll be starting PoC execution in mid-January, reporting on our results beginning in February, and contributing four major documents to the ISG’s process through the first half of 2014.  We’re already planning additional PoCs, some focusing on specific areas and developed by our members and some advancing the boundaries of NFV into the public and private cloud and into the world of pan-provider services and global telecommunications.

These advances will require insight and effort on the part of every one of the companies who have contributed to take us to this point.  It will also require further involvement from other companies, involvement we will secure through our commitment to an open approach.  We’ve defined an open and adaptable service orchestration process that works not only with NFV elements but also legacy devices and services.  We can manage what we deploy, no matter whether it’s built from software or from switches and routers.  We can even mix cloud applications like CRM or Unified Communications with network features to build services that are both of the cloud and of the network.  We want help with advancing and proving out all of these things, and our call for participation is still open.  It’s working too; we have two integration partners involved in this PoC and six others in some stage of development.  Even more would be great.

In the first quarter we’ll release open specifications for Service Model Handlers that can link any management system that can deploy software or connect network elements with our high-level deployment orchestration and management model.  This will create an open, agile, network and cloud connection and bind SDN and NFV with open interfaces.  It also supports the hardware of any vendor.  We have also proposed a TMF Catalyst to extend our integration potential upward into operations processes in a fully open way.  We hope that interested parties in both these spaces will engage with us to test our theories in future public processes like this PoC and the TMF Catalysts.

The foundation of NFV is the virtual function logic available for deployment, and there’s a real risk that this space will be as proprietary as network appliances.  We think it should be fully open to developers of all types.  To help that along, we’ll release a specification for an open Virtual Function hosting framework, something that can bring every piece of network code that can run in the cloud today and any application developed for a cloud platform, into the NFV world.  That includes specifically open-source software.  There’s no proprietary lock-in for network functionality in our architecture, which is how we think it should be.

Our commitment to open virtual functions is demonstrated by the fact that our PoC and Catalyst processes are based in part on Metaswitch’s Project Clearwater IMS project, a project that’s open-source.  We have onboarded it to NFV with no modifications required for Project Clearwater software, but we can also demonstrate how to build APIs that virtual network functions can exercise to improve operations and management, using familiar web-service interfaces that work for every software platform and programming language in use today.

There are people who don’t think that something like this can be done in an open way; that it’s too large an undertaking to be advanced except by some giant vendor with a proprietary goal that will deliver a big payday.  Hopefully the fact that an open project has received the first formal approval as an ETSI PoC says something about the power of open architectures.  We’re going to continue to prove the skeptics wrong, and we ask like-minded people to contact us and be a part of that proof.  This PoC approval is a critical step for CloudNFV, but it’s only the beginning.

I know I’ve blogged a lot this week about industry conditions, but there’ve been a lot of developments in that space and we’re all in this together, industry-wise, in any case.  Cisco’s analyst event offers more fodder for the discussion and also I think some clarity on the choices that face us.

At one level, Chambers repeated a theme he’s used so often that it could be set to music.  He talks of market transitions and macro conditions and all the other good stuff, and I still think that dodges the real conditions.  Look at the financial reports of Cisco’s customers.  Industries are reporting record profits in many cases, and few are saying they’re starved for cash or credit.  Yes, we’re in a period of economic uncertainty, but when in the last decade has that not been true to a degree?  The thesis that Cisco (and, to be fair, most of Cisco’s competitors) seem to strike is “If things were just a little bit better, buyers who can’t justify spending more on networking because it’s not building a business value proposition would surrender and spend anyway.”  I don’t think that’s realistic.

The Street has its own quirky views here, though.  They want to claim that Cisco faces problems created by SDN.  My surveys say that’s nonsense in a direct sense; there’s no indication that SDN adoption this year or next has any impact on equipment sales.  What is true is that SDN has become a proxy for the real problem, which is that nobody will invest in something if it presents a dwindling return.  If you ask, “Will SDN hurt Cisco?” the answer is “No!”  If you ask “Will the buyer fears of dwindling network ROI both spur interest in SDN and in simply holding back on spending?” the answer is “Yes!”  SDN isn’t the cause of Cisco’s malady; it’s just a symptom.

Chambers did address technology, even technology change.  He talks about how Cisco is facilitating the cloud, partnering with others to help integrated solutions.  But if you have a market that’s starved for ROI, you have to boost the “R” if you want the “I” to improve.  Cisco like most other vendors in the network and IT spaces are offering guidance on how to do something with tech when buyers want to know how to do something different, something better.

The challenge Cisco has in the “betterness” dimension is twofold.  First, their new market areas like servers may offer additional revenue opportunity, but they also offer (as UBS Research pointed out recently with respect to Cisco’s UCS) lower margins.  The Street will beat Cisco up just as fast because margins are dropping as they will if sales are challenged.  Second, even if Cisco knows what the buyer really wants and needs (which I think they do, and so do all their competitors, at least deep in their psyche) that doesn’t mean that it’s easy to offer it.  Cisco is like all vendors forced to kiss Wall Street ass every quarter, and any sign of weakness tumbles the stock.  That’s why I’ve been saying that we have a financial market that rewards tactical behavior.  Well, anything to improve the fundamental buyer economics of network deployment is hardly likely to be “tactical”.

The most substantive thing Chambers said, the most positive thing, was that Cisco would be making a lot of acquisitions in the software space, not for “material” meaning P&L reasons.  That implies they’re making them for strategic reasons.  That’s critical because if we’re building the network of the future from SDN principles or NFV principles or cloud principles, how the heck did we overlook software?  Cisco, to be a real IT company or even a real network company with a future, needs to be a software company and so do their competitors.

And the software isn’t a software replacement for switching and routing.  OVS won’t change the game much, and “defining” the network is really about defining the network’s missions and services.  Cisco is right in believing that it’s more important to get current network technology to slave itself to a software mission than to support legacy network missions with software instead of hardware.  But they’re wrong in thinking that building ONEpk to allow for software control is enough.  Without those higher-level service functions, without novelty and innovation in what networks can do for us, application control of the ONEpk sort are a bridge to nowhere.

That’s what we should be looking for in pronouncements by Alcatel-Lucent or Juniper too.  I pointed out that Juniper, under its current CEO, was supposed to be turning itself toward software.  It didn’t happen.  Now that CEO and his senior software protégé are out and a new team is coming in.  This could drive Juniper down the right road.  Alcatel-Lucent is also promising a new focus, but their CEO isn’t promising that focus will be on software either.  And unless you have a software vision in networking these days, you’re decoupled from all the trends you say you’re supporting.  Live by the box, die by the box.

Citi has just initiated research coverage of the networking space, and I think it’s useful to look at what they say and compare it with what my own surveys and modeling suggest.  Wall Street, after all, makes money for people by guessing right on stock trends.  The big “however” here is that sometimes it makes money when the company isn’t; stocks aren’t a perfect indicator of fundamentals.  Let’s see what Citi says, then, and make some assessments on fundamentals.

With coverage initiated on 16 network companies, Citi puts eight in the “neutral” category (Ciena, Corning, Ericsson, Garmin, Infoblox, Juniper, MSI and Polycom), assigns three “Sell” ratings (Blackberry, Brocade, and Cisco), and five “buy” ratings (Alcatel-Lucent, F5 Networks, Nokia, Qualcomm and Riverbed).  Let’s look at what seems to be the overall thesis, then at some of the ratings that might seem a bit of a surprise.

According to Citi (we interpret) the macro conditions in the networking industry for the next couple of years will be unfavorable.  Both enterprises and service providers are likely to spend to save and not spend to advance, which will keep revenue growth limited.  Opportunities that develop will focus on narrow segments of the market, so people with a narrow footprint will tend to either hit (and be rated well) or miss (and be rated poorly) those good places.

Radical technology changes are not going to contribute as much opportunity as buyer-side initiatives that are most likely to perpetuate the status quo.  If Citi believed that SDN or NFV would present a major opportunity, they’d cast somebody likely to capitalize on these technologies as winners, which they do not.

How does this thesis compare with my own predictions?  Generally, pretty well.  I think that buyers are interested in a new model for networking but they’re not seeing a complete solution to their problems or a complete addressing of their own opportunities.  They will kick tires in 2014 and frankly be happy to do more, but they don’t think vendors will present them with the product mix they need for a radical change.  They’ll buy influenced by things like SDN and NFV (they’ll demand a “strategy” or “architecture” and an evolution path) but they won’t buy a lot of either.

Among the buy/sell calls that I think reinforces my view is the “Neutral” rating they give Juniper and the “Sell” they give Brocade.  Brocade has actually gained traction on SDN and NFV in 2013, as I’ve noted in the past.  If you assume that traction could be linked to sales on a broad scale, there’d be no reason to put Brocade in the “Sell” column.  With Juniper, the problem is that while the analysts think it has an opportunity, the new CEO is a wild card they say.  Which says that the current Juniper strategy was a loser and they don’t know whether the new guy will do any better.  That implies that SDN and NFV aren’t market trends that will shoot up like the old hockey stick, but rather are things that will require a lot of vendor prep.

How about the most “controversial” calls; Cisco as a “Sell” and Alcatel-Lucent as a “Buy”?  If you polled people in the industry (and maybe even on the Street) you’d likely get a lot of pressure to switch those labels.  But is Citi right?

Cisco’s challenge is that they’ve built up their sales over time in no small part by increasing total addressable market (TAM).  Offer more and you can sell more.  However, this is clearly a diminishing-returns thing because you necessarily go further afield from both your comfort zone/skill set and the magnitude of the opportunity as you keep picking those low apples.  I think Citi believes that 1) Cisco can hardly gain much market share in its core markets and 2) it’s running out of attractive alternative places to be.  I’m not sure they have this one right.

My surveys, as I noted yesterday, show that Cisco has by far the best influence trajectory in the cloud space, and has ridden those gains to match IBM in overall IT influence—a significant accomplishment.  IBM built its success—the best long-term success in all of tech—out of account control and buyer influence so you have to give it a chance to work for Cisco in my view.  I also think that Cisco has an appropriate strategy for SDN and NFV for the dominant player—make it into an evolution of strategy because the buyer is unlikely to be presented enough benefits for revolutionary change by any competitor.  This is why Juniper is the potential Cisco-killer in the mix; it’s pretty likely they’re the only player who could create a revolutionary paradigm and make it stick (the management changes Citi cites do create uncertainty, but the old management would IMHO have certainly failed here).  Net?  I’d have given Cisco a Neutral.

Then there’s Alcatel-Lucent, who has a toe in so many ponds that they’re starting to look like moss.  I think that broad exposure should have scared Citi under their thesis of specialized opportunity, but instead they like them.  Why?  It comes down to the fact that the new CEO has “brought focus” to key areas.  In short, they seem to be saying that we like Alcatel-Lucent because they’re going to toss off all the sectors of networking that clearly aren’t going to be sterling opportunities and focus on the only ones that likely have a shot.  I’m on the fence here too.

On the positive side, I do think that focusing on areas like wireless/LTE are important.  However, Citi doesn’t capture what I think my surveys show is the key point.  You can’t win in networking unless you can stretch out to win in the data center.  You can’t win in the data center if you don’t win in the cloud.  While Alcatel-Lucent has a cloud story (CloudBand) that I like, it’s not positioned as effectively as it would have to be in order for it to create the kind of influence trajectory Cisco has.  You’d have to give Alcatel-Lucent a “Buy” on pure technical reasons—they suffered more in stock price than they deserve.  The problem is that Alcatel-Lucent is way up YTD and Cisco is virtually unchanged.  If you believe that Alcatel-Lucent could be the SDN and NFV disruptor that Juniper could (possible, not easy, for them as much as for Juniper) then you can justify a speculative “Buy”.  On valuation I’d give them a “Sell” so that nets to neutral for me.

I think the important thing about the Citi coverage is that it’s showing an industry starved for innovation and unlikely to generate enough from any player to move the ball.  Given all the opportunities to innovate that I believe are out there, that’s sad.