Month: June 2014

One of the people who read my blog sent me an email last week, asking why network operators listed operations efficiency, service agility, and capex reduction as their drivers for SDN and NFV and not “new services”.  It’s a good question, insightful because in fact only about 10% of operators in my survey indicated they believed there were “new service” opportunities associated with SDN or NFV.  It’s also hard to answer.

One reason it’s a hard question is that it’s obvious that the operators themselves are uncomfortable abandoning their dependence on pushing bits, or even pushing them differently.  Over the last eight years, I’ve noticed a higher level of acceptance of new services as a cure for carrier revenue/profit stagnation, but even this has just made the operators interested in technical developments that would permit new services, not so much in driving those services themselves.

From the technology side, the easy starting point is to say that SDN and NFV are “infrastructure-side” technologies driven primarily by those in the operator community are responsible for infrastructure and operations planning.  The business development people are typically not involved; in our survey about that same 10% said that they had significant bus-dev involvement in either SDN or NFV.  The cloud, in fact, is the technology that is most likely to be associated with incremental service revenue.

That cloud/revenue link is also important in answering the question, because it’s also true that SDN is seen by all the operators as being primarily a cloud-support technology, though about a third give metro applications nearly equal weight.  It’s also true that NFV is seen as a way of improving cloud operations and agility by over three-quarters of operators.  That in combination frames both SDN and NFV as being subordinate in terms of new revenues.

This raises a couple of questions—first, is this lack of revenue linkage fair, and second is it an impediment to SDN/NFV deployment?  The answer to the first question is “Yes” in that we really have not created a direct revenue link for either SDN or NFV that would stand up to serious scrutiny.  The best we can do is postulate more revenue yield by shortening service turn-up times.  The answer to the second is also “Yes”, and I think the fact that operators are more willing to leap into the cloud than to augment familiar practices and services with SDN or NFV is proof of that.

The second question is whether we could provide a direct link to new service revenues from either SDN or NFV.  To answer that we have to remember that users pay for the service experience and not the service technology, so to empower either SDN or NFV with real revenue legs, we have to be able to build unique experiences with them.  Can that be done?  It’s obviously not being done well now, but could it be?

In the case of SDN, I think the answer is “Yes” if we step back and consider the impact of having atomic-level forwarding control on service behavior.  We could create services like “Forward except on Thursdays” or “Quench Route back to the Source”.  We could obviously do other services with more thought, services that are fundamentally different from the traditional connectionless or connection-oriented models of LINE, LAN, and TREE that dominate today.  All of these represent what I’ve called “service models”, which are links between an experience or behavior that’s visible outside the black box of the service with a recipe for creating it within that box.

I’m sure you can see how my example service models could be created using the classic OpenFlow SDN model.  The heavy lifting on the recipes would have to be done with those infamous “northbound APIs” where nobody seems to want to do anything today except replicate what we can do without SDN—Ethernet and IP.  But the big problem is socializing those experiences/behaviors in the service buyer community.  How do we make people want services they don’t now have and possibly can’t even get their heads around?  We have a lot of work to be done in creating a realization that this sort of thing is even possible, and we don’t have much of an appetite for that sort of thing today, given that public network vendors are constrained to kiss Wall Street babies every quarter and don’t want to spend more on R&D and marketing but less.

And NFV is even more complicated.  I’ve blogged here about the notion of contextual services and their value, and virtually everyone I’ve talked with agrees that this is likely the future of networking.  Contextual services require a new model of application/service workflow, one that composes services extemporaneously based on user requests.  Something dynamic and agile like NFV would be ideal for this, but it’s a service concept that’s recognized by its early examples (LBS, contextual search) but somehow not seen as a large iceberg under the current tip.  Can the NFV community drive a better vision?  Remember that it’s science and operations guys driving the bus.

I really think this is all due to a common, insidious, problem.  Because we want to be able to demonstrate immediate implementation and monetization, we start everything at the bottom.  We have built SDN from a protocol to control forwarding table entries, and Cisco is presenting a notion of policy-based networks that starts with a protocol that lets us push policies.  What policies, what value, what service model lies behind any of this?  If we were to say “I can build a service that is totally disconnected from today’s device and protocol limits” would we start by defining protocols and virtual devices?  I don’t think so.

My model says there’s nearly a trillion dollars in “new” service opportunities that could be accessed, a pie large enough to make any service provider or network/IT vendor happy and change a lot of lives by introducing the new experiences and capabilities that this new stuff consists of.  But we have to turn around a set of very entrenched practices, which isn’t easy without direction and drivers.

I’m convinced that contextual orchestration isn’t a long reach from the data-driven orchestration and management paradigms that seem to be emerging for the cloud, SDN, and NFV.  What’s needed is a shift from a pure management vision (set up something and it runs based on internal rules) to the notion of service logic modeling.  If the service logic is being assembled based on contextual needs, it’s the assembly part that’s new; once the “order” is completed then committing resources isn’t very different from provisioning except for the dynamism and duration of the commitment.  Those impact the efficiency needs more than the basic logic or architecture.

I’d like to see some body take this up, but it’s not clear which would be best.  The ONF, or NFV ISG or maybe OASIS or even the TMF?  Whoever does it needs to clear their heads of low-level preconceptions though.  We’ve had enough of those already.

Anyone who’s watching the networking market realizes by now that there’s a huge interest in open-source, especially among service providers.  Many attribute this to penny-pinching, but that’s not the case.  Operators know that moving from appliances to hosted elements is going to save less than 20% on their capital budget and have a so-far-unpredictable impact on opex.  Those who have looked closely at the latter issue have concluded, in fact, that there’s no incentive for things like SDN and NFV other than operations efficiency and service agility.  So why push for open source?

Operators tell me that they believe vendors are not responding to their need for transformative technology, and my surveys show that’s been true for almost a decade now.  They’ve issued RFIs and RFPs and tried to influence standards groups and even spun up a few of their own, but in the end none of this is resulting in a flood of new technology options to do what operators need.  They can’t join to develop something, either.  In many countries they can’t manufacture, and in more they can’t work together without getting slapped with an anti-trust suit.  So open-source is their only choice; they can work on an open project as easily as on open standards.

I’m a big fan of open source, as I’m sure those who read my stuff already know.  I’d love to see operators do more—do everything—with it.  That’s not going to happen, though, and in truth it doesn’t have to happen.  Most of the software elements of the network of the future are going to be commercial, for years to come if not forever.  But what I think is even more important is that many of the operators’ goals could be met in the near term by taking a different path, and that path could still embrace and even lead to open source down the line.  What is it?  The answer is “MANOaaS.”

All the disdain operators say their vendors have for transformation support should have generated a huge startup opportunity, even in our current age of VCs funding different ways of organizing social media and video.  Why hasn’t that happened?  The reason is that the central thing that operators need is a highly flexible management/orchestration framework.  Everyone who’s looked at this problem knows it gets harder the deeper you look, and the VC community has no interest in funding something that would generate a transformation that would empower server/platform stuff their startups don’t make but would require prodigious investment and time to complete.

Suppose we look at this another way?  In both the SDN and NFV worlds, we need to create services across technology domains and manage them, and associated legacy technology, end to end.  This means doing things like modeling and decomposing, optimizing and allocating, and transforming among a host of different management visions and needs.  Almost all of this stuff could be done in as-a-service form.

Let’s take the task of converting a service model (a description of the rules associated with making connections among network users) into a service by controlling forwarding tables.  You could easily envision a “StampOutMyVirtualStuff” service that takes, as input, a graph describing the topology of the physical environment and all of the attributes of the nodes and paths, plus a similar description of the desired connection behavior.  Flash, bam, alakazam (as the old song goes), you have a list of forwarding instructions to send to some controller.  Other nuclear tasks associated with SDN and NFV could also be made into services, and those who need them could dodge capital costs of MANO completely.  If the SaaS model is smart for enterprises, why not for providers?

Another virtue of MANOaaS is that it could force the industry to present functionality in atomic form, through RESTful interfaces that could facilitate open substitution of elements and thus promote competition.  Competition would be lower, and the opportunity to set de facto standards greater, for early players so we could start a competitive rush to get things out there and working.  That could jump-start the use of the new tools.

For the service provider, the MANOaaS model could provide relief from a terrible dilemma; do you roll out a universal strategy that will solve all your problems but perhaps take years to be cost-effective, or do you do little chunks here and there and hope you’ll not create technology silos worse than the service-specific networks of the past?

Even the software guys, the people who could, should, might do something in the MANO space might find this to be an attractive approach.  It’s pretty hard to make money on open-source unless you’re a company large enough to drive a credible professional services business.  A startup could host a couple pieces of MANOaaS on a public cloud provider and see their own costs scale reasonably.  Their per-orchestration or per-service fee might be something that the providers would balk at down the line when their MANOing becomes universal, but that pressure could be relieved by offering licenses to run the stuff on the providers’ own clouds.

Even open-source could be promoted here.  I’m convinced you could do a lot of MANO, as much as 85%, with open source, but even if I describe how to do that (which is what I plan) it doesn’t get it done.  Who drives the project forward?  Will the players who are now resisting offering transformative tools to operators suddenly change their minds?  We need different players involved here, as many as we can possibly induce to get involved, as fast as they can be made to commit.  The more profit models we can offer them the better the chance at least one of those models is right.

This may be a critical thing for the credibility of the cloud too.  Can we say that SaaS is the right model, that the cloud is universally applicable, when the very people we think will build that cloud don’t think they can use it to jump-start their own transformation?  What’s sauce for the goose is sauce for the gander.

There’s a report circulating that Cisco’s long-time, charismatic, and some-say too-long-standing CEO John Chambers may be stepping down this fall.  Financial sources seem generally pleased with the notion, given that Cisco’s stock seems to be “range-bound”, offering little opportunity for either regular “long” investors or short-sellers.  There’s little question that Cisco is mired in something, but is it something of Chambers’ making?  What could Cisco do?

It’s been clear for almost a decade that networking wasn’t the hockey-stick marvel it was in its heyday.  The Internet dealt traditional service provider business models a series of major blows.  The unlimited-usage model meant incremental traffic didn’t generate any revenue at all, but it did demand capacity expansion.  The OTT players were able to leverage their greater agility to jump quickly into new market opportunities, leaving the transport providers with their creaking declining revenue per bit.  Even mobile services was hit by Apple’s device-centric vision, and Apple made sure that the Internet model dominated mobile services too.

One could look at this, as I and others did a decade ago, and note that Cisco and other vendors really had only one choice.  That was to climb the food chain, to focus on transforming their customers’ businesses with improved service-level products.  The problem was that this view meant accepting the commoditization of network equipment, and there was little chance that service-layer gains would offset switch/routing commoditization.  In any event, the Street rewards you for the quarter not for the future.  It’s disingenuous for the Street to now say Chambers should have done something different, because they’d have punished Cisco’s stock had he tried.

He did try, sort of.  Chambers oversaw attempts by Cisco to enter consumer networking, consumer devices (Flip video) and most recently information technology.  All of this was at one level a realistic attempt to create additional “total available market” or TAM by expanding into symbiotic spaces.  But Chambers is a sales guy and not a strategist, and I personally think he’s always had a salesperson’s skepticism about strategy.  Cisco was sales-driven in what should have been strategic moves.  But, truth be told, I’m not sure what could have been done that wouldn’t have raised the howl of those Wall Street wolves.

So let’s forget the past, Cisco.  What now?  Whether Chambers stays or goes, the status quo is not a survivable choice and you probably realize that by now.  The UCS success is coming at a time when the giant of giants in IT, IBM, is getting out of the space you’re betting on.  There are hosts of players in the industry making formal progress toward open platform models that will only make servers a worse business.  But somehow Cisco, you have to make servers and IT work because networking is never going to work for you in the long run.  You’ll shrink too much.  Even at the expense of margins, you have to increase sales and servers and IT are the only place there’s a chance that will happen.

You also have to look to the IT giants for inspiration.  IBM is running from servers but not running to anything that’s obvious.  HP, on the other hand, seems to be taking the stance that the transformation of networking could be a benefit to server/IT players because servers are what get consumed by centralized SDN control or NFV hosting.  It’s hard not to see HP’s aggression in NFV as anything but an indicator that they think their own sales and margin risks could be at least partially covered by big wins in servers for the telco market.

And they could be right.  My model says that carrier server consumption created by cloud computing, SDN, and NFV could be the largest single source of server growth, building over a hundred thousand new data centers globally.  If you, Cisco, could get a big chunk of that you’d be settled in as an IT giant, perhaps even one bigger than IBM and HP.  You’ll not be the sales-and-margin shining star you once were, but nothing will ever bring that back.  Redefine success here, Cisco, or experience failure.

You can take inspiration from your own Visual Networking Index, not as “proof” that somehow everyone has to buy more routers because there’s more traffic, particularly stupid pet tricks traffic, but as proof of a demand revolution of another kind.  Mobility changes everything because it makes our information consumption contextual.  Instead of immersing ourselves in the desktop-search cocoon we drag our gadgets into the wide world and use them to support us at whatever we’re doing.  That means our gadgets have to know what we’re doing.  The traffic these gadgets create doesn’t matter, the nature of the experiences they support is the key.

We are trying to transform the industry with the longest capital cycle in all of technology—networking—into something that supports not enduring relationships or services but something that is completely extemporaneous.  We have no architecture to build the applications this network will support, no conception of services that will support the interchanges these applications will create, and no tools to efficiently deploy or manage these applications.  All three of these things are difficult problems, and the combination could seem insurmountable.  But, Cisco, if you want to be the “Number One IT company” then you’ll have to solve them.  Because, and trust me on this, somebody will.  Then they’ll be number one.

HP and Alcatel-Lucent are your big threats now.  Both of them realize that NFV and the carrier cloud are the critical low apples of the transformation to contextual services, critical because they can bridge the present to the future by justifying initial deployments as augmentations of current services and preparing the framework of the future at the same time.  Some of the real NFV visionaries, like Don Clarke who was the editor of the seminal material on NFV, have seen this larger role of NFV perhaps from the first.  HP and Alcatel-Lucent see it now, perhaps not clearly but clearly enough to be taking steps to own those critical first stepping-stones across the river.  You, Cisco, have to push them both off and pursue a carrier cloud/NFV framework that will inspire the market.  If you do that, you won’t need a super-salesman to run you.

Yesterday I talked about the “union” of implementations of the cloud, SDN, and NFV revolutions.  My key point was that this implementation would inevitably converge because there won’t be three future infrastructures, but only one.  A corollary to that point is that however vendors start their own path to this converged future, they’ll close ranks and converge themselves.  We have two announcements that demonstrate how complicated that is—one from Brocade and the other from Overture.

Brocade is a fusion of storage and networking technologies most recently augmented (perhaps even “defined”) by their acquisition of Vyatta and the notion of software routing and switching.  Last year, Brocade took an incredible leap forward in strategic influence because they framed an NFV position around virtual switching and routing—essentially saying that NFV starts with the functions you virtualize.  That was such a refreshingly logical view that Brocade was rewarded with greater influence on planning, but they didn’t follow up effectively and lost their edge.  Their announcement was aimed in part at delivering on a new model that does capitalize on their previous vision.  There are 3 elements to that.

First, Brocade has to understand that every network switching and transport device isn’t going to be replaced by soft switches and routers from Brocade, or anyone else.  The network is an ecosystem, there are different value propositions in each piece, and Brocade has to live with that.  Their response is to classically abstract the network into Connection Services, SDN Structural Services, and Functional Orchestration.  The highest level provides generic linkage between service models that applications create or consume and the means whereby those models are instantiated.  SDN Structural Services is aimed at driving those “means” more into an OpenDaylight direction, essentially harmonizing different devices and vendors on a common control mechanism.

Functional Orchestration is in some sense the ecosystem capstone, and also the place where Brocade virtually asserts it’s relying on third parties.  By including the layer, Brocade acknowledges that “services” will have to be coerced out of hardware and software through some DevOps-like but more advanced process set.  They’re not naming that process, committing to provide it, or (beyond the inevitable reference to OpenStack) naming what does provide it.

What Brocade has done is a solid evolution from a VNF-driven vision of NFV into a holistic vision of what software-centricity at the network would look like.  They’ve identified the pieces correctly, I think, and they’ve embraced the inevitability of multi-vendor networks and supported a credible model to converge all the pieces on an agile and operationally efficient service set.  The only thing they have not done is to cover that orchestration and management angle explicitly.  Keep that point in mind, please.

Then we have Overture.  Overture is a carrier Ethernet company who launched itself into the next-gen services world with a controller they call the Ensemble Service Orchestrator.  When you look at the details of what ESO can do (not what Overture says they’ll do with it), you see what I believe to be the most functionally complete management and orchestration framework that anybody has productized.

But remember, Overture sells carrier Ethernet switches.  Can they stand up and shine in a market area whose issues of management integration, cloud integration, orchestration, and OSS/BSS are hardly their strong suits?  It would be a long pull for sure, so Overture has announced a premises platform called the 65vSE, a “virtual service edge” that is designed to host an agile set of virtual network functions to augment services and improve in particular self-provisioning of service features by enterprises.

Anyone who reads my blog and follows industry news realizes that this isn’t the first service edge device or strategy that has been linked to NFV (nor will it be the last).  However, a hardware edge product is a credible evolution of NFV aspirations for a carrier Ethernet player, particularly given that the tactical focus of many operators for NFV will be business-service enhancement through service chaining.

Service chaining prospects pose a risk to operators, particularly up front.  If hosting stuff is the right answer, and if you expect there to be a resource pool on which to host, where is it?  When you start marketing you have no customers anywhere, so where’s the best place to start?  You can hardly launch an agile service and tell the first dozen or so customers they’ll have to wait while you build data centers.  Edge hosting, as I’ve said, is smart for service chaining because costs scale in a linear way—every customer hosts their stuff on-prem until you get compelling economies of scale to justify centralizing some stuff.

Edge hosting isn’t the only thing you need to address this, though, and while Overture didn’t play it up much in their announcement, what makes their service-edge strategy compelling isn’t the device but the backing that the Ensemble Orchestrator provides.  You’d have to get some plugins and cooperation from both Overture and other vendors to fill out the approach, but ESO could deploy VNFs across an arbitrary mixture of premises service-edge boxes and servers, wherever the latter happen to be sited.  It could also integrate the package with deployment and management systems and practices.  Overture has secret sauce in this space, perhaps in fact more “secret” than they should let it stay.  I said before that Overture underplayed their own superior orchestration position, and they still do.  Given that NFV success is the only way to drive success at the NFV edge, that seems risky to me.

I think by now you see a common thread.  Vendors are all coming at SDN and NFV from the same starting point and converging on the same finish line.  What’s different is that the starting point is defined by market/sales needs and the finish line by technology.  Brocade’s strengths are not Overture’s, and vice versa.  Naturally both will grab onto the next low apple based on their position in the orchard and not just the position of various apples.  Neither have articulated that final converging technology yet, perhaps because it’s too difficult to sell a story of that magnitude to either media channels or customers.

The question is whether a short-range step sells to customers either.  Can any cloud, SDN, or NFV position be sold even as a long-term goal without specific instructions on how that long-term goal creates a business case that drives evolution?  Maybe staying in bacterial form is good enough; that beach looks awfully dry and dangerous.  That’s the question that Brocade, Overture, and everyone else must address before they take their own route out of the primordial network ooze and into the future.

It’s interesting to me that we’re starting to see focus on the key issues of the cloud, SDN, and NFV but not necessarily the kind of focus you’d expect.  To me, and to the enterprises and operators I survey, there is a clear need for some unifying vision because there is simply no appetite for funding and driving three independent revolutions.  One would expect an advancing state of awareness would advance uniting our key concepts, but that doesn’t seem to be the case.

What is happening visibly is that comments and claims in all these spaces are getting a bit more strident and focusing a bit more on a perceived near-term opportunity.  The global economy is recovering, and that’s obviously raising hopes of vendors that long-curtailed capital programs may be finally completed.  For incumbents (like Cisco) we see this in the form of determination to drive current incumbencies forward, because it takes more time to change network strategies and embark on a new course than to simply re-invest in old ones.  Even today, too, buyers believe that they need to address SDN and NFV more in terms of investment protection than in terms of actual exploitation of benefits.  Even the cloud, senior partner of our three revolutions in terms of age, is still not viewed strategically by the majority of either enterprise or service provider buyers.

We started the cloud, SDN, and NFV all at the bottom.  We’ve spent time defining low-level structures and issues without having established the high-level framework in which the stuff is supposed to work.  How long have we heard about “northbound APIs” that one of my clients whimsically refers to as the “APIs to nowhere” because vendors never seem to know what’s up there.  Classic software architecture practices dictate a top-down approach, and while everyone agrees that the cloud, SDN, and NFV are all about software, we somehow forgot that top-down mandate.  That’s why maturation of views in each of the three areas isn’t yet leading to reconciliation of technology among them.  We’re still in the basement and don’t realize we’re building condos and not single-family homes.

One of the interesting developments of the last month just might change all of this.  HP’s “OpenNFV” represents the most complete articulation of a tech model that could converge SDN, NFV, and the cloud.  Stated in HP-centric marketing terms, OpenNFV is a combination of basic cloud platform tools, contributed special HP elements, and things from ecosystem partners.  That’s not a bad approach in my view, but it’s demonstrated it has a specific weakness in a tactical-hype-driven market.  That weakness is from “partners” eager to stamp on a logo but short on commitment to actually do something useful.  Some operators in my most recent survey indicated they believed that HP’s OpenNFV was actually losing momentum and focus; they were all quite happy in the fall of last year.

The recent announcements of SDN tools designed for multi-tenant cloud networking are to me an interesting example.  First-off, we already have multi-tenant clouds and so it’s hard to see how this sort of thing by itself would create a huge stir in the market.  Second, where multi-tenancy at the cloud level is actually critical is in NFV.  HP doesn’t really address the NFV application at all, even though it would be an ideal element in OpenNFV.  Some of the NFV-related things that HP has claimed would be supported by OpenNFV, including and especially open management integration, are still to be firmed up, are also very useful to cloud providers and even to enterprises but the connection isn’t there.

There seem to be three factors pushing us away from harmonizing our revolutions where they naturally meet—the top.  One is that old problem of vendors pushing tactical sales points because they’re afraid a mass strategic review will hold up spending that might now be recovering.  Another is that buyers tend to want to apply new technology in niches where the risk can be controlled and the business case can be made easily.  That discourages buyer-driven discourses on high-level revolution convergence.  Finally, the media wants to cover everything in a couple hundred words with a jazzy headline.  Explaining complicated stuff is simply beyond their ken.  In working on the first video tutorial (of, probably, six tutorials in total) to explain my ExperiaSphere open management and orchestration framework, I’m finding a high-level intro alone is likely to take a full hour and the total material is likely to be five times that length.  You can understand how reporters would have a hard time dealing with this.

HP’s OpenNFV seems to me to introduce a new factor, which is what I’ll call “ecosystemic hope”.  I know this stuff has to be done, and I support that fully.  I support it by adding some sockets at the top of my own products, facing in the direction of the user and applications, and hoping some partner will hook something useful to them.

The challenge for HP and others with ecosystemic hope is that when you dissect the pieces of the high-level convergence of our revolutions, you are left with things that could be highly disruptive but that can’t build a compelling benefit case by themselves.  It’s a lot of work to drag big rocks to a stream, uncomfortable to wade out and get the placed, and without some acknowledged benefit of what’s to be found on the opposite bank, it’s hard to build momentum for the task.  HP, and Alcatel-Lucent who is also thinking ecosystemically, are going to find it challenging to address the high-level issues of any of the revolutions through partners.  They need to bite the bullet and define an approach, then populate it with the critical elements.

HP may be doing that; they have at least admitted that OpenNFV has to include HP-supplied secret sauce.  They’re not hurrying though, as their positioning of their SDN stuff shows.  Alcatel-Lucent has announced a reference server architecture to fend off competition from vendors who offer servers on their own, but I’m still trying to get a high-level management and orchestration vision from them (I have another call later this week).  The only good news is that just as having five or so feeder roads converging on a main highway, the visible process of combining the feeders inevitably opens the question of what happens on that highway.  We can only hope that insights on our three revolutions, insights at the top of each, will raise realization that we really are heading for one road ahead.

Our first (high-level) tutorial on the open-source universal MANO architecture we’ve called ExperiaSphere(TM) will be published the end of June, and you can find out more about this on our ExperiaSphere blog.  We’re also moving our support for ExperiaSphere questions and answers from LinkedIn (where we’ve had group posting issues) to Google+, where we have established an ExperiaSphere Community.  Please join the Community if you want to keep up to date on our model.

Arista Networks had a very successful IPO last week, something that’s sure to raise the hopes of VCs and startups in the networking and SDN space.  Underneath, of course, are all of the usual questions—most significantly whether the strong showing in the stock can survive months of trading and the eventual release of restricted shares.  One less-than-usual question is whether Arista proves anything about the SDN opportunity because, according to many, it’s not really SDN at all.  One common remark is that the company is “more like Cisco than like Nicira”.

Arista’s own decode of the SDN acronym is telling; “software-driven-networking” rather than the traditional mapping of the “D” to “defined”.  It’s never easy to characterize technology that’s not fully described at the technical level, but I think it’s fair to say that what Arista is doing is indeed aimed at a somewhat-Cisco-like SDN approach.  It may not be fair to say that’s a pejorative statement, but clearly it drives us to look at the subtle differences and how they might be exploited.

What makes the whole SDN space complicated is the number of things that want to be called “SDN” these days.  If we look at the field from the perspective of what gets sold and installed, we have three dimensions of classification.  One dimension is the software/hardware dimension; to what extent does the product utilize custom hardware versus hosted software?   The other dimension is the source of forwarding rules; are they adaptively derived from traditional per-device topology and discovery exchanges or centrally set by policy?  The third dimension is the role that software can play in the process; do applications and services utilize connectivity or can they actually create services?  I think Arista’s position relative to Cisco and the rest of the SDN and switching world is easier to understand if you look at these three dimensions.

Classic purist OpenFlow SDN presumes that there are simple commodity switches whose forwarding is controlled centrally.  Either the controller establishes routes based on some master plan, then commands the switches to actually build them step by step, or traffic presented at the switches is used to invoke a central decision on how that traffic should be handled.  That decision would be made based on the same master plan.  This model works fine on a modest scale, but if you want to expand it to the whole of a major IP network you’d be treading new turf.  IMHO, classic SDN needs to be augmented with specific domain-and-federation approaches to separate networks into chunks small enough for central control to be credible.

“Nicira” SDN is really largely about hosted virtual switching/routing as an overlay on traditional network switching.  This basic overlay model has extended (via players like Vyatta, now part of Brocade) into what’s essentially a hosted switch/router product.  In this model the “network device” is a software instance of switch/router code, and so there is no specific need for network hardware at all.

Both these two models of SDN provide some mechanism for applications/software to influence forwarding and virtual network segmentation.  These come in the form of APIs that can be used to partition address spaces (virtualize) and set forwarding/connection policies.  The differences in what’s offered lie mostly in whether forwarding control is truly centralized, and I think it’s fair to say that most of the current “SDN” vendors are actually supporting some form of controlled adaptive behavior at least as a parallel option to full forwarding control from a central point.

Cisco as the incumbent in switching/routing is hardly interested in creating products to speed the demise of its key market sectors.  Their SDN strategy has favored the augmentation of basic switching/routing behavior by improved software control—likely through formal distribution of network policies that would control networks, zones, and devices in a hierarchical way.  In theory you could make this process a complete “mother-may-I” network strategy but in practice it’s more likely that you’d want to add whatever additional capabilities you needed without compromising the basic nature of switching and routing—at least as Cisco sees it.  Cisco is effectively proposing a “revolutionary evolution”, a change in top-level stuff that, for a time at least, leaves the bottom of the network intact.

Cisco has a valid point here; I don’t think that the switching market is ready for revolution and I don’t think Arista believes that either, only that the market is ready for anybody-but-Cisco.  Cisco’s problem isn’t that it’s not radical, only that it’s not quite radical enough.  Arista is an evolution of traditional hardware-based networking, based on a software-centric architecture that starts off with the need to support cohabitation between adaptive and centrally controlled behavior.  They also took considerable steps toward focusing on operationalization, something everyone realizes is important.

Did they take enough steps, though?  If Cisco wants to evolve to radicalism, is Arista trying to revolt to the status quo?  The answer has to come from just how much Arista actually exploits their software-centric model.  If that model doesn’t add much value, then it won’t have a broad market impact.  And I think where the value has to come is in that area of operationalization.

Operationalization in the broadest sense, the creation and sustaining of services on next-gen infrastructure of whatever origin, still seems to me to be the missing link and both the great risk and great opportunities for the Ciscos or Aristas of the world.  Central control doesn’t scale.  Ceding network control to individual applications or users is clearly anarchy and would never work.  What’s needed is some mediating function that operates to balance resources against needs collectively, based on “policies” in the broadest sense.  Cisco is right that policies are the key but a bit vague on what policies are or how they operate.  Arista is specific on the value of operationalization but a big vague on how they’ll achieve it.  Yes, you can exercise it through the APIs, but there’s more to running an army than carrying orders; somebody insightful has to issue good ones.

Arista shows something very important; two things, in fact.  First it’s demonstrating that Cisco cannot rest on its legacy laurels.  It may not have to join the revolutionaries but it will have to shed the wig and robes.  Second, it’s demonstrating that while software is the functional keys to the network kingdom, you don’t have to foreswear hardware completely.  In fact, there are advantages in providing a mixture of fast-forwarding boxes and intelligent forwarding control.  But all that means is that the bar for a pure software solution is higher, and those advantages will probably have to come in the area of operationalization.

I don’t think that Arista is currently threatening Cisco.  The fact is that any new technology can find low-hanging opportunities to justify it over current technology choices.  To change a whole market, to threaten major incumbents, you need to do more than that.  Arista needs to make their differentiation versus Cisco more compelling.  If they don’t then Cisco will evolve to cut them off, or another player will jump in with a truly compelling story.  Either way, Arista has some work to do to prove its stock market success is an indicator of success in the market.

Everyone knows that knowledge is power, but information is not “knowledge”, and that’s the general issue I have with the big data and analytics craze.  We’re presuming that collecting a whole lot of stuff is valuable, which could be true…if we can do something useful with what we collect.  In the areas of SDN and NFV, I think analytics is becoming the classic “universal constant”, which every college student knows is that number which, when multiplied by your answer, yields the correct answer.  Is there a role for data gathering and analytics in SDN or NFV?  Yes, but you don’t fill the role by asserting the inclusion of analytics.  It’s more complicated.

Most of the analytics claims made with regard to SDN or NFV deal with gathering information about network or resource state as a means of 1) making decisions on resource assignment (routing, hosting, etc) or 2) invoking automated responses to conditions like congestion or failure.  The presumption is that by gathering “stuff” and running through it, you can gain an accurate picture of resource/service state.  Maybe.

The first issue is one of availability of the data.  Telemetry can be collected and analyzed only if its source is addressable, and in the case of network failure that may not be the case.  In SDN, for example, the network’s default state can be “no connections” and you don’t have data paths until forwarding rules are created to support transport.  That can be done explicitly and from a central set of stored states, or on demand when packets are presented.  But in either case you don’t have forwarding paths until you set them up, and so if something breaks you may be disconnected from the telemetry that carries resource state, for the thing that’s broken and perhaps for other stuff as well.  There are advantages to adaptive networking where every device cooperates to seek a connectivity map, folks.

The second issue is timeliness.  There’s always a propagation delay in data transmission so the bigger and more complicated a network is, the more likely it is that your knowledge of state is imperfect because the current data is still in flight.  But even if you have it, analytics is essentially the application of robot processes to data repositories, and the regularity with which these processes run will impact the timeliness of any alerts.

Even if you get data when you need it from what’s important to you, there’s still the question of relativity.  Suppose Server Four is overloaded.  Great, but what services are associated with Server Four?  Virtualization means that abstract resources are committed for real when you provision/orchestrate something.  That means that the relationship between server (in this example) and service is elastic.  If we presume that we can relocate something if its server breaks or horizontally scale in response to load, the resource commitments can vary over time.  How does a real resource fault get tracked back to a virtual service commitment?

Then there’s the issue of actionability.  We know Server Four is broken.  What do we do about it?  If the answer is “send a human” or even “tell a human” we’re defeating the whole notion of service automation and compromising our goals of operations efficiency.  But knowing something is broken and what services are impacted is still an intellectual exercise if we can’t remedy the problem in an automated way.  That means that we have to be able to relate issues with remedies at the service level, and associate them there with the proper remedy based on available alternatives.  That, in turn, means we have to be able to rethink the “what we did” to create the service (instantiate or orchestrate or whatever term you like) and do it again, keeping in mind that this time some of the choices have already been made (the stuff that’s not broken) and these choices might still be good, or good enough, or maybe they’re inconsistent with our remaining options post failure, so we have to do some or all of them over again.

The net of all of this is that “data” in isolation is useless.  Status, in isolation, is useless.  We have to be able to contextualize our information and then evaluate it against the rules for how it should be interpreted, for every service impacted.  That, friends, is way beyond what people are generally talking about these days.

The TMF awarded the CloudNFV Catalyst the title of “most innovative” this week in Nice and (keeping in mind my role in launching the concept as fair disclosure here) I think the award is deserved, and in no small part because CloudNFV explicitly recognizes the need for service context in interpreting management events and taking meaningful action.  You could absorb analytics and big data into it in a number of ways, but the key point is that the critical service context is never lost, including when you change something in deployment because of changes in resource state.

Part of the “contextualization” benefit offered by CloudNFV is architectural; it’s a byproduct of the way that services are modeled.  Part is also created by the implementation platform (EnterpriseWeb) that allows for essentially totally elastic binding of processes and data elements, so that forming and reforming pictures of what you’ve done and what you now have to do is straightforward and efficient.  The implementation also provides that second critical element, actionability, because the demonstration shows how network conditions can be fed back to create operational changes in deployment.

The final aspect of this is the integration of all the pieces, something that the multiple-player nature of CloudNFV demonstrated, with its inclusion of a host of other founding contributors and integration partners.  The truth is that nobody is going to have a meaningful single-vendor solution to this problem because nobody has single-vendor networks and OSS/BSS/NMS tools that all come from that same vendor.  We’re living in a disorderly world, tech-wise, and we have to face that or we’ll never bring it to heel.

I’m not saying that CloudNFV is the only way to do what needs done (most of you know I have an open-source project with the same goals), or even the best (that has to be proved by comparison, and there’s nothing yet to compare it with).  I am saying it’s a validated solution where, as far as I’m aware, there are no others.  It’s also a warning to us all.  When we throw out terms like “analytics” like they were solutions, or even paths to a solution, we not only undervalue what the TMF at least has found highly valuable, we submerge what might be the critical part of a debate over how to use information to sustain quality of experience in a virtual age.

 

Tech has always been a kind of swirling mix of trends (and hype), but any ecosystem necessarily supports symbiotic things best—positive feedback is after all “positive”.  We may be seeing some signs of symbiosis in some of the trends in IT and networking, and so we may be poised for better-than-average rates of change in our industry.

What’s really happening underneath everything else in tech is an increased value placed on dynamism.   Mobility has taken consumer communications and entertainment into our pockets, and what we can use at a whim promotes different usage patterns than that we used when we had time to sit at the computer.  Companies are looking at productivity changes less by providing information (essentially hoping someone will do something with it) and more by promoting and supporting behaviors.  Help a worker do a job better and they do a better job.

The cloud, fundamentally, is valuable mostly because it’s dynamic and not because it’s cheaper.  Economies of scale, as I’ve noted, are fragile and easily lost as competition drives down margins and low-apple applications are converted.  But dynamism is inherently useful, particularly because dynamism in demand is difficult to fulfill through static resource commitments.  The cloud is the right vehicle to support the demand trend I opened with.

NFV (as carriers would see it) or “DevOps” as it might be called by enterprises, are a natural response to increased dynamism in both supply (resources) and demand (applications/components).  If we’re into whim-satisfaction, we’re necessarily going to be seeing a lot of changes because whims are transient, dynamic, by nature.  We have built IT on the premise that we could adapt work practices to fit automation models and now we’re doing the opposite, which means that we have to make IT more flexible.  But what’s important about NFV is less the on-the-surface desire to substitute hosted stuff for appliances (that’s like saying the cloud is important because it’s hosted server consolidation) than the fact that when you formalize such a structuring of features you have to address how to deploy them and manage them profitably.

SDN, in my view, is really a tail of an NFV dog and not the other way around.  If I have massive shifts in work created by dynamism, and if I expect my applications and services to be truly whim-satisfying enough to sustain user commitments to them, I have to be able to engineer performance to stay within acceptable limits.  The basic mission of the network used to be connection but now it’s going to have to be delivery of experiences, which is a whole different thing because the experience has to be assembled from cooperative components sited in some logical place, then connected and streamed to the target consumer.  The traditional approach of creating a network that can support open any-to-any is simply not economical because it demands everything be able to draw on unlimited capacity all the time simply because some of the time it will need a lot of it.

Right now, I think all of our giant revolutions are being hampered by “limitedism”, meaning the tendency to atomize something to make it easier to get your head (and wallet) around.  The problem is that we’ve then killed that symbiosis, and created a situation where everything’s benefit case is weakened because it can’t be made with the cooperation of the other elements.  We can’t have SDN without the cloud and NFV, can’t have NFV without dynamic applications and services, can’t have anything without that recognition that the user or consumer is the behavioral—and ultimately financial—driver of the whole picture.

Taken in this light, Apple’s recent shift toward home and health ecosystems may be a more interesting gamble than it might appear on the surface.  It’s facile to say that Apple is just digging itself deeper into consumer electronics, becoming more a gadget company.  Such a move would be an enormous risk because these deeper elements of consumer technology are just that—deeper.  You know what your phone looks like and so does everyone else, so it’s subject to “coolness”.  How many times have you thought “Gee, that motion sensor is really cool?”  Apple can’t possibly be so stupid as to think it can brand a sensor, so it has to be thinking about branding the experience as a whole.  It might be moving into dynamic cloud not through a service but from the experience side.

Amazon’s move with a vCloud connector may be something similar.  If you want to sell cloud services you need to exploit dynamism if you’re in for the long pull.  Applications need to be dynamic to use dynamic resources, so if Amazon can create more dynamic applications by creating containers that let them be moved around (OASIS has a similar goal with its CAMP model).  But migrating stuff isn’t the same as making it dynamic, so Amazon will have to do more to encourage cloud-centric, dynamism-supporting, development models.

Every ecosystem has a foundation, and IMHO the foundation of the dynamic tech ecosystem of the future is the effective use and management of virtualization.  Virtualization is the combination of functional abstraction and resource-independent instantiation.  What’s important about tools for NFV or SDN or DevOps, what’s critical in application development today, is the migration of everything toward a virtual-driven model.  That’s the high-level issue that every one of our trends has to be grounded in, or they’ll lose that critical symbiosis.  That’s why I keep harping on the need to visualize management and orchestration (or “MANO” in the NFV ISG terms) as being more than OpenStack or service chaining.  We can’t shrink our critical revolutionary foundation unless we’re ready to shrink our revolutions.

The TMF event in Nice this week is a focus for an important issue in the evolution of networking, which is the way in which existing network and operations elements relate to newly introduced technologies like SDN and NFV.  The Forum promoted its “ZOOM” project, which is aimed at modernizing OSS/BSS models and introducing (hence the play on the name) faster responses to service problems and opportunities, and some of the Catalysts have been aimed at showing how cooperative evolution can work.  What’s interesting to me here is that there are two underlying realities being demonstrated at the same time, and these operate against the Forum’s explicitly stated goals.

Carol Wilson, who’s covering the event for Light Reading, commented that open source seems to be establishing a competitive position with ZOOM, at least insofar as implementation of next-gen operations models are concerned.  She goes so far as to suggest that ZOOM be considered an open-source project rather than an evolution to OSS/BSS standards.

Most of you know that I’m actually working on defining an open-source implementation of management and orchestration tools (my first tutorial may be out late this month, in fact).  Given that, I’m hardly likely to dispute the value of open-source in OSS/BSS evolution.  However, my experience shows that there are fundamental challenges in using open-source tools, challenges that have to be addressed right up front.  The difficulty for the TMF may be less one of open source as one of timing.

For somebody to kick off a complete open-source MANO project today, and base it on the presumption of new development, would be an exercise in futility.  It would take too long, and it would duplicate dozens of other open-source activities that are already doing good work in subsets of the total problem space.  The right open-source OSS/BSS solution doesn’t have to be developed, it has to be identified, and then customized a bit to fit these available tools together in a cohesive way.  That means starting with a high-level vision of what tools you’re going to use and how they’ll integrate.

The problem this poses for the TMF, and also for OSS/BSS vendors, is that OSS/BSS standards and structures don’t reflect natural open-source boundaries because the dominant implementations aren’t open-source.  I can define open-source implementations for the major elements of MANO and also demonstrate how they can integrate with existing OSS, BSS, and NMS elements but when I do that what I am really doing isn’t supporting a ZOOM project or implementation or evolution.  I’m making one unnecessary.

We’ve seen a couple of TMF-related announcements and Catalysts, notably the CloudNFV one (disclosure: I was founding architect of CloudNFV) and NetCracker.  While the available information on these implementations won’t support a complete analysis of the approach, the material does show that both build what I’ve called a “shim layer” between infrastructure and operations tools and the OSS/BSS processes.  Rather than propose massive changes to operations systems and practices, they propose to support evolution at the technology level through a process of consistent abstraction.  Legacy and evolving processes and service elements are presented in simplified form to higher operations levels.  This is possible because the differences, the details of orchestration and management, are harmonized in the shim.  Thus, the Nice events are demonstrating that you don’t need ZOOM to “zoom” in terms of service velocity or operations expediency.

None of this has to be a bad thing for the TMF.  There’s nothing wrong with advocating a shim layer and with the notion of consistency of abstraction as a framework for ZOOM.  The problem, as I’ve said, is timing.  If you can really build open-source-based shim layers for operations, then you need to focus on how that is done and what the interfaces really have to be.  Not what a standards body like the 3GPP or TMF or even NFV ISG might think are needed, but what are presented by the open-source components you’ll need to leverage.  If you don’t recognize the intrinsic component structure of an open-source solution assembled from components, you’ll define workflows and connections that can’t be supported without writing more code, and you’re lost in terms of market relevance.

The same, arguably, can be said for the MANO implementations that are coming out as we speak.  So far, nobody really has a complete story of MANO because nobody tells a story that envelopes the essential pillars of evolution—support for where you are and for where you need to get to.  The fact we’re gravitating to shim-based solutions without acknowledging that’s what we’re doing doesn’t mean the necessity of the shim approach isn’t being proved, only that we’re not going about the process as we should be.  You rarely happen upon the right answer while digging randomly in the technology diamond pit.

I would like to see an open-source project here, but I’m not sure I’d want it to be ZOOM-based.  The TMF specifications and legacy OSS/BSS structures should be accommodated, just as legacy infrastructure should be.  I like the notion of having the NFV ISG promote an open platform model too, but I wonder whether that would work.  Why do I feel this way?  It’s back to timing.  The right way to do our MANO shim is the fastest way that works.

That’s going to be by assembly, not by new development.  Could TMF people come up with that, given that they are influenced by the desire to perpetuate the value of their current work?  Could a group of NFV people do any better given that they’d try to build to the structural model they defined in their own specs, rather than build to optimize the use of current open-source tools?  Would the proprietary implementations of MANO provide for the integration of open-source elements?  The problem is that we don’t know the answers to any of these things yet, in no small part because nobody is providing much detail on exactly how “shimming” works, even though their solution relies on it.

I think this is going to change, and frankly I hope to be at least an instrument in making it change by defining what is at least one example of an open-source approach to MANO that does offer explicit integration of infrastructure and operations tools.  But I also think that competitive pressure will drive others to try to do the same.  That at least will get our MANO debate and our open-source interests where they belong—on the same page.