SDN World Congress Day One

I’ve not gone to trade conferences for a while and I forgot how exhausting they can be!  Yesterday I had a chance to peruse the booths at SDN World Congress, and I met with Charlie Ashton of 6WIND for a demo of their technology.  I’ve blogged a bit before about the importance of data path acceleration in NFV, but this was an opportunity to see exactly what difference it made.

The demo is simple; you set up a server with an OVS connected to a load generator and pump a over a dozen ports full of information, measuring the packet throughput per port and noting the variation among the ports and the “jitter” of a given port.  You then repeat the test with 6WIND’s technology installed.  The difference is astonishing.  Packet throughput was increased about 15 times, and the variation in performance per port and port-level jitter were cut to less than a third of their original values.

If you’re a network operator trying to get the most bang from your cloud service or deploying NFV (6WIND is a CloudNFV founding member) a 15x throughput increase in itself is a significant benefit.  This would translate to the ability to load the server with more network activity, meaning that network connections wouldn’t be a limiting factor in the VM density.  It would also clearly improve the performance and response time of the application.

With respect to the variability, the most fundamental presumption of a cloud is resource equivalence, meaning that you can assign an application or VNF to a pool of VMs when it’s necessary and pick any VM that’s available.  If you have significant variations (and I observed almost 20% variation among ports without 6WIND’s acceleration) then you don’t get equivalent performance from each VM, and you have to try to match apps to the VMs that give you the best connectivity.  The problem is that this varies over time, as the jitter rate per port of about 13% showed.

When you don’t get consistent performance out of a system you have to engineer your SLAs conservatively, which again means under-loading the servers and increasing your cost per user.  You also have to expect that performance issues are going to increase your customer complaints, and if the variability is extreme enough you may find you can’t write a business-grade SLA for the service.  That would significantly reduce the potential revenue yield too.

All this adds up to a totally different picture of first cost, the dreaded period when carrier investment in a service drives cash flow negative, where it stays until you can sell enough and collect your fees and bring things back to normal.  Cash flow starts off like the classical sine wave, but dipping before it rises.  Anything you do to reduce yield and increase costs makes first-cost worse, and that makes it harder to get approval for a service rollout.

Another announcement at the show came from Mellanox, who has joined the CloudNFV initiative as an Integration Partner, the first firm to complete the process since the project launched in August (Metaswitch, whose Clearwater IMS was announced as the demo use case, was a partner at the time of the launch).  Initially, Mellanox will be supplying 40G NIC cards to allow for high-throughput testing of the IMS use case for the public traffic-carrying demonstration in December, and the first cards are already on their way to the Dell lab for integration.

Mellanox is also the first partner in the newly announced Active Data Center component of CloudNFV.  The importance of getting a complete platform integrated and running is something all operators will appreciate, and Mellanox has a line of fabric switches and storage networking solutions that will enhance the “horizontal” or inter-NFV connectivity that virtually all NFV applications generate.  Fabrics mean that the relative location of the VMs selected to host a set of virtual functions won’t generate different performance levels because of different packet transit delays due to hop variations in classic tiered data center switch configurations.

With the Mellanox addition, CloudNFV’s foundation platform for execution consists of Dell switches and servers, the Mellanox NICs and in the future switches, Red Hat Enterprise Linux and 6WIND data path acceleration, Overture carrier Ethernet switching, and Qosmos traffic probes (Qosmos also supplies DPI-as-a-service for packet-inspection-based use cases and the evolving Testing and Monitoring as a Service framework).

Active Data Center would host the VMs for CloudNFV and it could also be used to run the software that deploys and manages services that include NFV.  EnterpriseWeb is the provider of the foundation software platform for the optimization and management tasks, and Overture provides the orchestration and OpenStack interface.  Both these can run on Active Data Center but the specific requirements for hosting them would vary with the configuration and are generally less than needed to run the VMs hosting the virtual functions themselves.

There are a number of big network operators at the show, speaking or captaining tables for discussion, and in conversations I found some interesting common threads.  One was that operator interest in and commitment to both SDN and NFV remains very high, but operators are also very aware of the work to be done in getting the most bang for their buck in both technologies.  One issue that was expressed by almost every one I talked to was that of multi-vendor support or open interfaces.  Another was management, which is so far only vaguely addressed.

I think we’re going to see progress in both these areas, in no small way because of the operators’ emphasis on them.  For SDN, I think that the biggest issue may be settling on a controller framework, and for that I think OpenDaylight is the leading contender.  I’ve always liked the inclusion of the Service Abstraction Layer in the software, but as I heard from talking with the folks in their booth, OpenDaylight is like NFV in that it’s a project and not a product.  Somebody is going to have to run with it in a formalized way to make it suitable for carrier or even enterprise use.  Red Hat may need to make a more formal commitment to that to insure that SDN shines.  For NFV, early development is (according to operators who have seen the presentations) largely proceeding in vendor-specific projects.  CloudNFV is an open approach (and data model and optimization demos are being offered to operators at the SDN World Congress event) but the OpenStack Neutron interface is a limiting factor in what can be done to build connections, both across vendor boundaries and in terms of general service/connection models.  We’ll probably see more NFV options as currently “secret” vendor NFV projects become public, and hopefully some of the offerings will have strong support for multiple vendors and open interfaces.  Operators need to gracefully transition to either SDN or NFV, and single-vendor support won’t make that easy.

Revolutionary Coming-of-Age?

What will SDN and NFV be when they grow up?  That’s a question we often ask children, but infant technologies ought to be prepared to answer it too.  Kids don’t find answering easy nor do they get it right often, and it may be that technologies don’t do any better.

If you define what you are by consensus, then SDN and NFV are doing pretty well.  In almost all the surveys, people think they’re revolutionary by more than a 2:1 margin.  Fully a third of businesses say they already have SDN (but roughly that same percentage say they have terabit Ethernet and almost that many think they’re descended from royalty).  Nearly all the Tier One operators say that NFV plans are well advanced, nearly all network vendors say they can deliver on NFV and SDN right now.  Hey, the war’s over folks.  Go home.

Where we really are, according to survey results I’ve gotten so far this fall, is a lot less inspiring.  SDN has no significant traction outside the data center, and even in the data center the rate of adoption (versus tire-kicking) is less than 2%, which is below statistical significance for my surveys.  NFV?  Your chances of having it are less than being struck by lightning.

If instead of looking to others for definition we look to formalism, we also get some interesting results.  There are now published references or specifications for both SDN and NFV.  About half of users say that SDN is fully standardized, and about a quarter say that NFV is.  Neither is, of course, and the first specifications for NFV became public only last week.  Some insiders in the SDN space told me that there were more standards to be done than there were already completed, and I believe it.

Where are really, though?  Or isn’t there any reality to measure?  I think that there is an objective state to both SDN and NFV but I don’t think that the current state of either gives us much of a hint as to where the mature version of either technology might go.

We have two issues with our two revolutions.  First, both of them are aimed primarily at improving costs and not improving services.  Revolutionary cost reduction approaches are kind of oxymoronic because revolution generates enormous risk and buyers apply enormous risk penalties that would make savings very difficult to validate.  We would therefore be forced to accept the cost-reducing paradigm as the driver of our technologies, or accept that they are revolutionary, but not both.  Second, both of them suffer from what could be called a “lack of holism”.

How much could SDN or NFV save?  Buyers say that both are likely to generate a 20% reduction in capital cost (so far; the survey results aren’t all in).  How much of that savings would be offset by increased operations costs?  The estimates vary from half to levels of opex growth that would be more than 1.5 times the capex savings.  Nearly every buyer says that they could accept such savings absent significant adoption risk but remember that most think there is such a risk.  You can’t help but recognize that both SDN and NFV stand or fall not on their capex reduction but on their ability to cap or even lower opex.

Which is where our second point comes in.  SDN is so far a kind of point technology.  You can do itty bitty pockets of SDN or you can do SDN at a thin boundary in your stack, but you can’t to reeeeeallllly big SDN.  Most vendors target SDN at the data center only, and most buyers say that their network costs are not even 50% focused in the data center.  Further, buyers can’t identify specific equipment from specific sources that would address SDN in a broader context, which means that they don’t see SDN as a replacement for current network equipment in a general sense.

NFV is similarly contained.  The specifications for NFV acknowledge an end-to-end service but also acknowledge that parts of it are likely to be outside the domain of hosted virtual functions.  That would mean every NFV service is a hybrid of current and NFV technology elements, but how that fusion is created and managed isn’t clear.  Would we automate the deployment of virtual functions and fall back to legacy practices to build the non-NFV pieces?  Would we manage one piece of a service using NFV principles and the rest based legacy?  In fact, could we harmonize NFV management with current operations practices at all?

SDNCentral defines SDN, NFV, and NV with the latter meaning “network virtualization” and I think there’s merit in this.  The real transition here is to the notion of as-a-service networking where the “service” is created by something other than a tinker-toy assembly of fixed devices.  By, in short virtualization.  We need to be thinking about how we’d build a network if we didn’t have device constraints, not thinking about how we’d replicate current devices by creating virtual versions of them.  How can we hope to optimize absent an agile service vision to match the agility of our revolutionary technologies?

I’m hoping to see how some of these issues are addressed by the vendors and operators at the SDN World Congress this week.  I’ll keep you posted on whether I’m pleased or disappointed.

Business Deals and “Experience Edges”

Since it’s the Monday before an SDN/NFV show, Columbus Day in the US, and a day when there’ll likely be no earnings announcements or much news, we can take a look at a few items that didn’t make the “news” cut last week.  It’s not that they don’t show something interesting as much as something else may have showed it better.

Juniper and NSN’s expanding partnership in mobile is one such thing, and I noted it in passing last week.  One reason why it’s not a lead item is that Juniper has been struggling to get a mobile position that did anything tangible for years now.  MobileNext was finally shelved, and you can be pretty sure that the NSN expansion is a direct result.  No news there.

Where something interesting might come in is that the NSN alliance itself is either an attractive billboard or a placeholder.  Juniper is about the only metro player that NSN could work with unless it wanted to pull its competitors into deals.  I don’t think that the arrangement is going to raise sales for either company if that’s as far as it goes, because I think the two were likely supporting common interests here in any case.

But where could it go that’s further?  The only logical step forward is for Juniper to supply “Liquid” metro/core in the same sense that NSN has been touting it.  That would mean a clear turning of Juniper R&D and positioning to support the Liquid concept fully.  In turn, that would mean that NSN and Juniper would have to agree on critical things like the cloud, SDN, and NFV.  I don’t get the sense that the two companies see any of those technologies in the same way, or that their thinking is converging.  It could, of course, but not yet.

The biggest question is whether Juniper would be willing to submerge its positioning in NSN’s Liquid theme.  On one hand, Juniper’s positioning has ranged from inane to vacuous recently so it’s not much of a loss.  On the other, Juniper has very significant technical strengths that it could leverage if a new CEO provides the company with a more strategic set of marching orders.  So what this may come down to is whether NSN and Juniper would become one, which would mean Nokia would have to merge with or buy Juniper.  At the current Juniper price levels, I think Nokia’s financial team would blanch at the thought, which would mean that Juniper would have to buy NSN out of Nokia.  Leaving Nokia, I think it’s fair to say, nothing.  So it’s really hard for me to see how this plays out.

Financial analysts think that Nokia is more likely to buy Alcatel-Lucent’s wireless business, which would make a lot of sense for Nokia but might create some issues for Alcatel-Lucent.  It’s not that the RAN and IMS are killer opportunities, though.  They’re deal-introducers, but there could be other better ones like the cloud, SDN, and NFV.  Alcatel-Lucent, after all, has not only the sole public offering from a major vendor in the NFV space, it’s actually a nice concept with the tie I think is essential—the tie to the cloud.

Another thing I’m struggling with is this whole gigabit Internet thing.  Google Fiber is supposed to be driving the whole industry to gigabit levels.  This, despite two key points.  First, customers in multi-tier-by-speed service areas cluster at the lowest speed and the cheapest service.  Second, there is little relationship between Internet access speed and service quality overall once you get above about 15 Mbps.  Yes, some households will stress access with multiple streams of video, etc, but if you fix access congestion you tend to roll the problem deeper into the aggregation network.  If you think that we’re going to get superInternet at next to no price increase, dream on.  This is more of that “attractive billboard” stuff, or something like the political posturing we’re seeing all too much of here in the US.  You can clock an interface at any speed the media is capable of, but how many home networks could even deliver a gig?  How many devices could absorb it?  In any event, all this would do is further commoditize bits if it were made real, and what operators are trying to do is monetize services.

The obvious questions in the services area are which services and how are they deployed.  What’s inside all the cloud, SDN, and NFV hype today is the realization (yes, in a fuzzy way just like politicians realize truth in a fuzzy way) that mobile and the cloud are combining to create a future where extemporaneous demand will drive the market for contextual solutions to contextual problems.  A mobile user wants instant gratification because if there’s a delay they’ve walked or driven away from the stimulus.  “Where do I turn here?” is meaningful as a question if the “here” isn’t five blocks back by the time a response is available.  Answers and solutions aren’t the same thing; the former is “information” and the latter is “contextual information”.  We are going to shift all of online services to contextual responses because we’re shifting all of the demand to mobile.

A less-obvious question here is whether there’s a kind of contextual app family that has to develop to optimally couple users with resources.  We know what a cloud looks like, how software defines networks (we just don’t bother to relate these realities to near-term product launches because it’s too hard to monetize).  Do we know what contextual apps are or if we need them?  Pertino, who launched a distributed-services vision out of a remote access platform, has equated NFV in the network with similar agility at the service-agent level, but the connection isn’t as tight or elegant as it could be.  I’d like to see them, and others, explore the question that we really have to ask here, which is whether all the technology revolutions inside the infrastructure of the future have to marry a revolution on the outside.

How the Cloud Could Lift Cisco

Barclays released a note on Cisco yesterday, based on an interview with David Ward, and there are some interesting comments and views, most of which I think are consistent with how I see Cisco’s evolution.  The key point, I think, is that in a technical sense Cisco is moving to become a cloud company in order to be what CEO Chambers would call a leader in IT.

The cloud is the “cultural fusion” of networking and IT, and it’s a fusion that’s going to bleed opportunity and risk between the two in a number of ways.  More IT power is going to undermine the role of purpose-built network devices, for example.  But more network agility is going to re-frame the notion of how people use IT to deliver experiences—for work or entertainment.  So Cisco is clearly spot-on if they do see the road to IT success being through the cloud.  What I’m less sure about is whether Cisco had fully accepted the other truth, which is that SDN and NFV are relevant insofar as they support this cloud fusion.  If you don’t fully grok SDN and NFV, you’ll never get the cloud right.

In the Barclays note, they correctly note that Cisco’s SDN strategy is very top-downish.  If Software is going to Define the Network, says Cisco, then it’s the APIs that permit that to happen that matter and not the plumbing that brings about the stuff the software is asking for.  By focusing on the APIs, Cisco has been able to frame the future of SDN as what could be a somewhat trivial technical evolution from current practices.  That’s very appealing to those who have invested heavily in those current practices, which is why Cisco gets high marks for ONEpk in our surveys.

The thing that’s missing here is an explicit notion of the service model.  I know you may think I’m harping on this, but the point is that if all software can ask a network to do is build an Ethernet LAN or an IP subnet, how are we really changing anything?  Cisco has nailed the evolutionary part of SDN but has yet to seize on the revolutionary part.

The Network Convergence System is pegged by Barclays as Cisco’s door into revolution, which may be correct insofar as intentions are concerned.  IMHO, NCS is aimed at creating the hardware platform for the cloud network, the platform that accommodates that bleeding of functionality from network into IT.  Some of the accommodation is aimed at making the network more controllable under centralized SDN principles.  Some is aimed at boosting the role of the network device in missions where the value of hosting versus embedding functionality isn’t all that strong.  My model says that about 28% of current router spending is clearly suitable for a software-switch implementation, 34% is clearly not suitable, and the middle 38% (the largest piece of the pie) is up for grabs.  If NCS can grab half of that Cisco holds on to most of the routing/switching value proposition.

What we’re left with now is the NFV piece, and I confess that Cisco’s approach to NFV is the one I have the least information about.  Operators in my spring survey told me that Cisco had shared NFV thoughts in confidential discussions, but almost half those who had heard the story said they didn’t fully understand the position.  To be fair, Cisco may have been a victim of NFV literacy; the standards process had at the time of the survey only just gotten off the ground (the first significant public documents came out today, in fact).  However, even today there’s more visible of competitive NFV implementations (particularly Alcatel-Lucent’s which is public) than of Cisco’s.

The reason that having a good NFV strategy is important for Cisco is that NFV is the only movement toward orchestrating the cloud/network fusion that has any realistic chance of success.  I don’t know how many people in the ETSI process would agree with this (many of the operators do, I know) but what NFV is about is really the provisioning of fused services.  Yes, you can apply the principles to hosting virtual functions but you can also apply them to hosting anything that requires cloud deployment and network integration.  A good NFV implementation is a great cloud foundation, and an unsurpassed framework for things like mobile empowerment.

Which, as you can easily see, is why Cisco needs to have one and why its competitors need one even more.  Barclays says that NFV isn’t going to be a factor in the market until “at least 2015” but I disagree.  Alcatel-Lucent already has announced CloudBand and though its features will in fact not be fully ready until 2015, it’s at least a proto-NFV.  My own CloudNFV initiative is going to be available for public demonstration and lab deployment in December of this year (we can do some demonstrations of the data model and management processes now).  We have three active integration projects for CloudNFV and five more under review.  And while most of the NFV announcements made to date don’t pass the “un-wash” test of actually conforming to ETSI ISG NFV model requirements, we hear of new ones every day.  The point is that this stuff is moving fast, and while Cisco may like being a fast follower, that still requires actual following at some point.  Hopefully before the leaders are out of sight.

The TMF is also moving along.  They’re putting important revisions to their GB922 SID model up for comment today, and these will be the first steps toward recognizing software, IT, virtualization, and the cloud explicitly in management standards.  Some operators have already told me that they are less concerned about whether virtual functions can be deployed on servers than they are whether the whole resulting cooperative system can be managed—not just efficiently, but at all.  Half the operators want to cast out the demons of past OSS/BSS and the other half say that OSS/BSS as it is must evolve to suit networking and the cloud as they will be.  That’s another area where Cisco needs to be thinking, because a good management strategy from a competitor could hurt Cisco’s evolutionary plans, and most of Cisco’s competitors (excepting only Juniper, who just tightened their mobile alliance with NSN and may also be drawing on NSN management skills) have a better OSS/BSS story than Cisco.

Next week is the SDN World Congress, and what I’m most interested in seeing is whether the conference demonstrates progress toward recognizing the technology trinity of cloud, SDN, and NFV.  If it does, then Cisco and everyone else had better get their act together.  If not, we could still face a long period of buyer confusion and indecision, and a market with only listless movement.

Could a New Compute Model Create a New Network?

We’re seeing some indications in IT spending, particularly on personal computing, that suggests businesses are cautiously restoring some of their budgets for technology.  The numbers also show that the PC isn’t totally without friends, which is important both for the computer space and for networking.

If you look at the PC market, you’ll find it’s really always been two distinct markets.  One market is made up of buyers who actually need personal computing, a category into which I fall.  These people do stuff that requires significant power and storage resources and they work whether they are online or not.  The other market is made up of people who want to be online and who have, up to recently, had no mechanism to do that other than the PC.

A smartphone or a tablet is surely a more convenient way of getting online.  If you have marginal needs for storage or rarely exercise your need for computing in a place where online storage isn’t available, some tablets (those with decent keyboards) will serve you.  The point is that the Second Market and part of the First can be addressed by tablets and smartphones, and so you can expect that people will begin to move away from PCs as they refresh their technology options.  In some, this will increase their consumption of online storage.

Some people have suggested that things like tablets accessing cloud storage represent a new source of traffic, but my data has consistently shown that users consume cloud storage to the extent that it’s free.  It’s free because it doesn’t represent much of a resource drain, and so it isn’t going to impact usage.  I did a little experiment on utilization and found that websites that played video clips used more bandwidth than any of the popular cloud drives did.  I see no current indication that the cloud will increase traffic/utilization for consumers at this point.  I can’t predict all of the future trends, but it seems very unlikely that anything other than video and gaming will have any significant impact on traffic over the user interface.

Inside the network might be another matter.  Logically, mobile user support is going to drive applications in the direction of providing answers rather than providing information.  That means that, in effect, a “search” is going to be contextually/semantically filtered and processed inside the network to provide the user with something easier to use while moving around.  This has the effect of increasing what’s called “horizontal” or “inter-process” traffic as functional elements of the cloud talk to each other to gather “information” and process it into “answers” as users demand.

How much this traffic might impact networks is very hard to say because we really don’t have a good handle on the pace at which this kind of answer-driven empowerment will proceed.  I ran some numbers using NFV optimality—the best-possible NFV business case with the most efficient possible NFV implementation—and found that it could build as many as 35,000 data centers in the US and create new metro traffic that amounted to five times the level now generated by business network services.  Consumer IPC traffic could obviously be larger than that given the number of consumers, but how much larger is just impossible to say at this point.

One of the things that’s important about this new traffic is its geographic scope, and that is also hard to pin down.  Modeling NFV again, we find that most NFV services will drive up IPC traffic inside the metro areas only.  There appears to be little near-term credibility to major IPC coordination across metros simply because it makes little sense to distribute virtual functions far from users.  With “empowerment” IPC traffic, though, we have to presume that some (and possibly most) of the “information” that gets processed would be dragged from global search or other large web-service databases.  This traffic could end up crossing metro boundaries, but “could” is the operative word.

My early model work here suggests that we’re entering the age of what could be called the “IDN” or “Information Delivery Network”.  CDNs cache content based on usage, with the ultimate goal of putting the content very close to the access edge.  IDNs would do the same, pushing cached information close to where it’s used.  The driver for this is the same as for CDNs—improve QoE and contain network costs.

Close to “where it’s used” is ultimately the user’s own device.  IDNs should be able to push resources right onto the user’s device, perhaps even to share things across nearby users using P2P technology.  What this does is to offer an incentive to increase the power of the user’s on-ramp to cloud-based services—the very services that up to now have been seen as reducing the need for PCs.

A smart computer company (Dell, HP, IBM) might well be able to profit from this.  There could be a loss in PC sales where PCs are simply thin clients, but there could be a new market for PCs as cloud partners.  There’s certainly going to be a market for servers to host all this info-to-answer and NFV stuff.  Playing the trend right could generate a computer win instead of a loss.

In networking, what this means is that we really need to think about what the metro network looks like.  Mobility adds a new dimension of connectivity to a metro network that’s historically been little more than an aggregation funnel.  If we started generating a lot of IPC and pushed cloud-hosting to each edge office or near each cell site or even into the user’s hands, and we then started applying SDN and P2P technologies to all of this, we’d reshape the whole metro network and we’d have a business case behind it.  Interesting, huh?

Are Networking’s Revolutions Disintegrating into “Oldthink?”

I noted yesterday in my blog that vendors and operators alike were guilty of what might be called “Oldthink”, the practice of honing in on today’s problems through the mechanisms of past solutions and thus simply reinforcing the past instead of creating a future.  We have other examples of that phenomena today, and in other places.

Public policy is a good example.  Regulations on telecom are based on an industry structure, service set, and competitive situation that doesn’t exist any longer.  AT&T, speaking at an industry event, noted that there are more Skype connections active at any given moment than there are wireline voice lines from both AT&T and Verizon combined.  But we regulate lines and not connections.  We have “technology-neutral” notions of how voice services have to be offered but often these regulations inhibit new technologies.  VoIP services can’t be used to replace wireline voice, we say, unless they provide E911 except that there are plenty of people who use VoIP services like Google Voice or Skype as their only voice service.

Net neutrality is of course the most problematic of the policy issues.  Google raised eyebrows by proposing to apply decidedly non-neutral policies on its own fiber services.  Mobile has different neutrality rules than wireline, and in all cases we’re playing a silly game and saying that you can’t offer priority delivery for experiences to consumers if the service provider pays—the consumer has to pay instead.

A good test of any policy is how many times you have to make exceptions or overlook violations to avoid being trapped in something patently stupid, and by that test our telecom policy is an abysmal failure.  What we need to be doing is asking how to balance the clear need for more investment in and differentiation of access to the Internet with the need to avoid saddling new ventures with undue cost burdens.  Could we not provide a “curb lane” for the Internet that would be free to providers but best effort, and still have a “passing lane”?

SDN and NFV at the technical level are other examples of Oldthink.  How many times do we hear that these two things are going to spawn a total revolution, laying waste to old network techniques and causing chaos among vendors?  Services, security, management and operations—all these things get transformed.  Or so they say.  The problem is that when we look at SDN application we see people building SDN networks that replicate Ethernet or IP as the services and that run on legacy switches and routers.  Where exactly is the revolution here?  I can see revolutions if we can build network services with different devices, or build different services with the same devices, but isn’t “different” kind of the watchword of revolution?  How many barricades have been stormed to keep things the same?

Underneath all of this is a single truth, which is that we’re in the software age.  Public policy on telecom has gotten off-track because it’s still regulating telecom hardware when the services are software-based.  SDN and NFV are being misunderstood and misapplied because we’re only capable of thinking of the future of networking as being the future of virtual devices that map 1:1 with current devices in capabilities.  We think we’ll manage an NFV cloud by managing a collection of virtual stuff that looks to the management system like a real router.  How, if we build a network that has to be managed as a router network, will that network ever rise above what we can now do?  It’s a kind of “You are what you eat” principle, and service management should never be allowed to dictate service evolution.  It has to be the other way around.

Organizationally, you can blame this on SOX, and I’ve done that, but I think we also have to accept a measure of responsibility ourselves.  I get all kinds of comments from people who can rightfully be called network experts but who can’t conceptualize the notion of connectivity except in the framework of IP and IP subnets and default gateways and DNS and DHCP.  We’ve made these touchstones of the here-and-now into the goals for the future network, when we should be asking how in a mobile world with users in no particular place doing no specific thing could best be connected.  The solution for mobility management in the future, in this age of SDN and NFV, is still said to be a feature of IPv6.  This, when we can control forwarding explicitly and define connectivity any way we like.

We could build a network that could happily connect users with five or six different addressing models at the same time, even with each other.  We could build a network that could allow users to roam around at will without having the fancy EPC manipulations that today keep us connected to sources when we move from cell to cell.  We could optimize and re-optimize content delivery and cloud access across a totally dynamic set of consumers.  But we have to think differently to do that.

Vendors will tell us that these kinds of changes would be too hard for the market to absorb, that operators would never “fork-lift” their networks to adopt them.  Well, how do we know that we can’t tolerate the trip if nobody shows us the destination?  Operators say that vendors expect them to sign a blank check to support any of these revolutions, but is “Out with the new and in with the old” the only alternative to the other way around—nothing in between?

Might it be that deep inside, we’ve become too comfortable with the state of the art?  When I got into networking there were probably four or five data architectures vying for attention, and a good pro knew them all.  Now we have one, and one is all that “good pro” knows, or wants to know.  It may be that the long-sought IP convergence also created IP fossilization.  A tagline from one of my old projects comes to mind; “Think outside the bit”.  Good advice for our time, I think.

Alcatel-Lucent: “Shift” or “Cut”?

We’re now hearing that Alcatel-Lucent’s “Shift” may not be shifting enough and that the company is planning to lay off 15,000 and hire back 5,000 new employees for a net loss of about 10,000 workers.  There are lessons here for Alcatel-Lucent, obviously, but also I think for the industry.  Alcatel-Lucent’s problems fall into two simple areas—anemic capex growth among operators and commoditization of the equipment base.  What’s less simple is what to do now.

Operator capex is tied to revenue.  Historically, operators have tried to keep their capital spending at a level between about 17 and 24 cents per revenue dollar.  It follows that if revenue isn’t growing spending won’t grow either, and if you’re an equipment vendor you need “organic” growth in spending to drive up your own revenue, or you’ll have to steal market share.

That’s where the second problem comes in.  If you sell a product that buyers can’t differentiate based on features, they’ll price-shop instead.  Networking has lost its innovative luster in many areas, but in particular in the lower OSI layers that weren’t exactly bastions of visible features to start with.  A price-shopping buyer is a buyer of Huawei’s gear, and all you need to do to validate this is look at Huawei’s growth at a time when other vendors are struggling.

It’s into this mix that we have to toss the innovations of our time—the cloud, SDN, and NFV.  How do they impact the potential capex and differentiation future?

The cloud, if successful, is an incremental revenue source to operators, which is why the cloud has outpaced all of the other “monetization project” categories in rate of progress over the last three years.  But the cloud is about IT, not networking.  IaaS services as they’re framed today substitute hosted for in-house, and that substitution is going to be price-based, so you can’t command a large cloud margin.  Many operators tell me that IaaS is as bad a business as the one they’re already in!  That means that cloud success can’t subsidize network capex even if carriers would let that happen.  You have to move up the food chain to make the cloud more valuable and useful.

SDN and NFV might arguably help in doing that.  By making the network more agile, by linking its services more effectively to software, you might be able to conceptualize new services whose margins would be better.  Since these services would have been formulated in part with “network ingredients” it’s reasonable to believe that the agile features would spawn network spending and provide differentiation.

The problem is that we’re not looking at either SDN or NFV in those terms, at least not effectively, and that’s as true for Alcatel-Lucent in particular as it is for the industry in general.  NFV is actually dependent on solving a problem, a series of problems, that every cloud buyer and provider will have to solve.  So is SDN, but in the most recent survey we did, we found that buyers had no statistically significant awareness of that point, even in the operator world.

Alcatel-Lucent has the best-articulated NFV position of any of the major vendors, but the buyers don’t have a good understanding of Alcatel-Lucent’s SDN strategy.  On the NFV side, one of the strengths of the Alcatel-Lucent position lies in its notion of an ecosystem of NFV stakeholders, and another strength is the cloud linkage.  What’s lacking, in my view, is a strong vision of the value of NFV and SDN to the buyers’ futures.  Operators need to be “service providers” or they’re simply commodity bit-pushers who will be annually sharpening their pencils to generate more cost cuts until they vanish to a point or get supported somehow by governments.

I know that the operators themselves are partially to blame here; visionary thinking happens inside every Tier One but you’re not likely to run into it because it’s buried in the cotton ball of traditional Bell-head thinking.  The thing is, you can’t have a market where the buyer is responsible for making the sale.  The seller here, including Alcatel-Lucent, has to show that they can be the solution to buyer needs, not wait till the buyer has an epiphany.

There is a need for a “shift” here, but not the mechanistic shift that Alcatel-Lucent proposed and that isn’t addressing the innovation or articulation gap.  With a million-buck budget, Alcatel-Lucent could create the next generation of NFV, SDN, and the cloud.  So could any of the other vendors in the networking space.  Technically the problems aren’t that large that we don’t have solutions for them literally staring us in the face.  The challenge is that when it comes to grasping those brass rings, we somehow hold back.

I know that Alcatel-Lucent frames the job announcement as an implementation of its shift plan, and I don’t disagree that emphasis changes are needed, and will nearly always mean workforce changes too.  I do think that seizing the vision and making it their own in the marketplace would have been an easy low-apple task to undertake.  It could help them understand just what specific areas of technology needed to be shifted from or shifted to.  To say “I’m shifting to IP” as every operator fights to reduce their spending on IP technology seems as risky to me as not shifting at all.  What part of IP?

We have three revolutions—the cloud, SDN, and NFV.  Every network vendor, from Alcatel-Lucent to Huawei, has to either play those cards or invent another revolution.  Doing neither, which is what’s been happening up to now, is not an option for anyone.

Blackberry Buyer Builds Boffo Business?

Ever since Blackberry turned in its abysmal numbers, stories have vacillated between “Blackberry goes private and becomes a 900 pound gorilla behind the cloak, then emerges to terrorize the industry” and “Blackberry gets bought by somebody who terrorizes the industry.”  You probably see the common denominator here.  Blackberry in any non-dead state is a terror to the industry.

I blogged last week that there was in fact a way that a Private Blackberry Rampant model might indeed be a bit of a game-changer.  I still believe that could be, staying with my general military-induced precept that you judge an enemy by its capabilities not its intentions.  It would be logical to think that Blackberry might be able to pull the same terrorizing stunt as the pawn of some other industry giant, but we’ve all seen how industry giants tend to take root and become trees, innovation-wise.  Would Cisco or Google or SAP, the three companies named as potential Blackberry suitors even be logical candidates to pick up the ailing smartphone company, and would any of them have any realistic options to make a go of it?  Let’s go in alphabetical order through our list.

Cisco has mobile aspirations for sure, and they have to be worried about the fact that operators do tend to give a big chunk of mobile business to the guys who can support either RAN or handsets. Cisco’s deal with Facebook on WiFi deployment seems like a serious case of RAN-envy to me.  Might grabbing a handset be a smart move for Cisco?

On the plus side, Cisco could probably do a lot to create the cloud/appliance symbiosis I recommended for Blackberry.  Build a kind of Linux shell that looked like the new Blackberry OS to an application, and you could port stuff between the cloud and the device—the big step in my rehab plan for BB.  Cisco has servers, a cloud distro of their own, and more than enough ambition and sales moxie to push this through.  By making the appliance part of the cloud, Cisco might also throw some FUD into VMware’s HQ, which Chambers would like.

On the minus side, Cisco has been shedding consumer products and appliances.  They might find smartphones different because they’re really kind of sold to carriers not directly to consumers, but surely it would be a big management distraction, and it still doesn’t give Cisco a RAN story.  Nokia sold their handset stuff off to Microsoft, which suggests the in crowd thinks RAN trumps handsets story-wise.

Google already has handsets, of course.  It’s very doubtful that Google would want to keep a competing OS if they had Blackberry, so the big question would be whether Blackberry’s customer base (carrier and business users, primarily) would be worth what Cisco would have to pay if there was no real technology they wanted.  Blackberry has some patents I’m told, and some still think patents are why Google bought Motorola.

SAP is complicated.  This is a software company, for gosh’s sakes!  But on the other hand, mobility is the key element in what I’ve been calling Point of Activity Empowerment, which is where Blackberry’s big chance would be.  Productivity is the key to SAP’s own future, and if they could create a PofAE model by grabbing Blackberry, it could pay off really big for SAP.  Who, by the way, really needs something to pay off in the cloud.  Despite everything from nomenclature revolutions to entertainment, SAP hasn’t been able to show any cloud strategy beyond, “Well, we can run on one”.  That’s hardly compelling given that darn near everything can run on one.

The issue for SAP may be the same issue Nokia faced on handsets.  European companies just don’t seem to have the marketing fire in the belly needed to make a go of things in the mobile device space.  Some would argue that Canadian companies don’t either (look at Nortel), which might have been Blackberry’s problem in the first place.  The fact that SAP might be able to sell a PofAE story to business wouldn’t erase the fact that being a business smartphone wasn’t enough for Blackberry.  Would it be enough for SAP?  If not they might be better off selling a smartphone unit than buying one; Brooklyn Bridge, anyone?

Where this leaves us, IMHO, is that none of the three proposed buyers of Blackberry have any clear shot at making the deal work out.  Cisco isn’t as bad off here as the other two in my view, but I think they’d be better off sticking to their WiFi strategy or pushing to buy a RAN player.  Maybe NSN?  Even for Cisco, though, the story of PofAE is pretty complicated, and Cisco doesn’t like complicated educational sales stories.  They like the “Traffic Chicken Little” tale a lot better, as we’ve seen again recently with their “Internet of Everything Sucks Your Network’s Blood Like a Lamprey Eel” story.

This is all relating to my vision of the Blackberry supercloud move I blogged about last week.  Could there be M&A based on some more pedestrian asset set?  Cisco and SAP have been talked about as buyers of Blackberry’s secure email/messaging processes, for example.  I’m not impressed by that logic unless the deal is a fire sale because I don’t think it would be difficult for Cisco or SAP to replicate the technology and if they don’t buy the whole business it’s not clear how they’d be able to keep the messaging service alive if the phones went elsewhere—or nowhere.

So sorry, Blackberry and Wall Street Speculators.  I don’t see any of these three companies making a buy of Blackberry work and I’m not prepared to propose they’re dumber than I am.  The best hope for Blackberry is indeed to take the Dell path to private company and work out something compelling behind the scenes.  That way they get to keep the money, too.

Can We Really “Distribute” NFV to Devices?

Nothing is ever as easy as it seems, particularly in networking.  We had some recent proof of that this week as RAD announced a bit more about its “Distributed NFV” concept.  On the one hand, “classical NFV” says that you want to remove functions from devices and host them in servers.  RAD says that’s not necessarily so; you want to put functions where they make the most sense, including in devices.

Other vendors have talked about hosting stuff on device blades.  Juniper took that position quite a while ago with its universal edge concept, but they tied the idea more to SDN than to NFV so it wasn’t recognized as an argument for a more flexible attitude toward function hosting.  With RAD joining the chorus of “let the functions kids play on devices too”, we have to ask whether “distribution” means distribution to any arbitrary hosting point.

RAD and Juniper would likely agree on their justification for edge-hosting in devices; you put features at the customer edge because that’s where the traffic is.  Firewalls, NAT, security, and other virtual functions make sense if they can be kept in the data path, and put close enough to the customer that you don’t have to add complexity to pull out individual customer flows to act on them.  I agree with this; you have to factor in the affinity of a function for the natural data path if you’re going to optimize its location.

What’s not clear, though, is whether you’re extending NFV to host on devices or just hosting on devices and citing NFV function distribution as your excuse.  You’re doing the former if you have a generalized architecture for NFV orchestration and management that can accommodate hosting on devices.  You’re doing the latter if you’re not linking the device hosting very explicitly to such a general NFV model.  Right now, I think most people are doing the latter.

I just spent some time reviewing the data modeling for the CloudNFV initiative, which defines services by assembling what the data model calls “Nodes” but which represent the TMF-SID components like “Customer-Facing Service” or “Resource-Facing Service” or the NFV notion of a “Package”.  Each of these defines one or more service models to collect interfaces, and each service model has a Service Model Handler that can deploy the service model if called on.  The standard Service Model Handler uses OpenStack and deploys via Nova, but you could develop one to deploy on devices too.  Thus, if you are satisfied with the overall NFV capabilities of CloudNFV, you could create an NFV-based device-hosting model with it.

The trick here is to be able to define services so that for each unit of functionality, you can define optimizing properties that determine the best place to put it.  I think operators would not only accept but applaud a strategy for function hosting that admitted devices into the picture as long as they could define how they believed the capex benefits of server hosting related to the potential complexity and operations-cost risks of that strategy.

Probably the big determinant to the value of distribution of functions into network edge devices (or in theory any other device) is that question of benefit/risk balance.  It’s likely that capital costs would be lower for handling functions via servers, but it’s not clear what the operations costs would be.  Both SDN and NFV currently suffer from management-under-articulation.  There is no clear and elegant model proposed for either to insure that injecting dynamism into a network by hosting software to control its behavior doesn’t explode complexity and drive up operations costs.

If you under-articulate management, you tend to create a convergence on the legacy model.  SDN and NFV either have their own management architecture or they inherit some existing architecture, which means inheriting the current one.  That would mean that we managed “virtual devices” that corresponded with the real devices we already manage.  It sounds logical, but let me offer an SDN example to show it’s not like that at all.

Suppose we have a hundred OpenFlow switches and an SDN controller, and above the controller we have our northbound application that imposes a service model we call “IP”.  We want to manage this, and so we have one hundred “router MIBs” to represent the network.  The problem is that the “routers” are really composites of local forwarding and centralized route control, so we can’t go to the routers for full knowledge of conditions or for management.  We have to create proxies that will “look like” routers but will in fact grab state information not only from the local devices but from central control elements.  How?

If we centralize these virtual MIBS they’re not addressed like real router MIBs would be.  If we distribute them to the routers so we can address the “SNMP Port” on the router, we then have to let every router dip into central management state to find out what its full virtual functional state is.  And you can probably see that it’s worse in NFV, with functions scattered everywhere on devices whose real management properties bear no resemblance to the virtual properties of the thing we’re hosting.

So here’s my take on the notion of function-hosting in devices.  You have to look at whether there is a cohesive deployment and management strategy that treats devices and servers as co-hosts.  If there is, you have truly distributed NFV.  If not, then you have a way of hosting functions in network devices, which doesn’t move the ball and could in fact be flying in the face of the operators’ goals with SDN and NFV.

Common Thread in the SDN/NFV Tapestry?

We’re in the throes of one show involving SDN and NFV and in less than 2 weeks, the SDN World Congress event where NFV was launched in the first place will be underway.  It’s not surprising we’re getting a lot of SDN and NFV action, so let’s take a look at some of the main stories in more detail.

AT&T’s main spokesperson on things SDN and NFV, Margaret Chiosi, is calling for SDN APIs to support the abstractions at the service and network level.  This to me is the best news of the day, even the week, because it is a comment beyond the usual hype and drivel we see on SDN/NFV these days.  What takes it beyond is the “abstractions” reference.

You can’t have service without a service model.  SDN has to be defined at the top by the services it presents, and these services then have to be mooshed against the network topology to create specific forwarding requirements.  Absent any specific mechanism to describe either of these, the layers of SDN that I’ve called the “Cloudifier” (services) and the “Topologizer” (network) have no clear input and thus no clear mechanism for connection to software, networks, or much of anything.

We have specific examples of “Cloudifier” abstractions with OpenStack’s Neutron, but these abstractions are too server-specific and the process of enhancing them or adding to them isn’t flexible enough or tied enough to the general needs of telecom.  We have a number of ways of describing network topology, but the only way we have to exchange topology in a reliable way comes from the adaptive behavior of devices and their advertising of routes.  The purist center of SDN thinking is trying to eliminate both these things, so we surely need to know what replaces them.

Perhaps the lack of APIs, which would seem table stakes for software-defining any sort of network, is why Ciena is reported in LightReading as saying that we don’t take SDN seriously enough; “under-hyped” is the term reported.  I’m reluctant to say that anything in this industry is under-hyped or even admit that state is possible to achieve, but the point Ciena is making is that new optical capacity can’t be used to direct bandwidth where it’s needed and thus some of the capacity improvements technology could bring are wasted.

Nay, I say.  The problem isn’t getting bandwidth where it’s needed, it’s getting it to where somebody will pay for it.  The challenge of SDN is that technology that impacts delivery can only impact costs.  Technology that impacts experience can impact revenue, but the great masses of network service consumers won’t pay for “experiences” that are only improvements in capacity or network performance.  In some cases, like here in the US, there are regulatory impediments to doing anything to make the Internet recognize premium handling.

This is what takes this back to the issue of APIs.  If SDN could be made to offer service models that would enhance higher-level experiences it could actually link increased capacity to increased revenue.  Content delivery is an example; the FCC exempts content delivery networks from net neutrality, so we’d be free to build one that extends close to the access point and offer premium handling on it.  Can a content delivery network be built with current IP or Ethernet service models?  Clearly it can, but if SDN is really valuable then it would have to be true that we could build a better one by building in custom forwarding rules—a new service model.  That means APIs capable of supporting that, right Margaret?

At some levels, you could say that HP’s SDN ecosystem and Alcatel-Lucent’s NFV ecosystem, already announced, could address this, but that may be a stretch.  Developer ecosystems are built around APIs more than they build the API.  It is possible that the experiences gained by the two parties in their respective ecosystems would uncover the need for the kind of abstraction-tuned APIs that are essential to service models, but it’s far from certain.  It’s also possible that competing vendors like Cisco, Ericsson, Huawei, Juniper, and NSN—or even IBM, Microsoft, or Oracle—could come up with the right answer here, but that’s even less certain.  The dynamic of the network industry today is to fight like hell for the near-term dollar and let the future take care of itself.  I don’t see how SDN is going to create enough near-term dollars without the ecosystem in place, which won’t happen till those APIs are popularized.

Another point that’s being raised, this one in an article by InformationWeek is that conflicting views of SDN implementation are at least now being recognized and explored.  The article, about the conflict between physical and virtual visions of SDN, points out that some vendors (not surprisingly, network hardware vendors among them) view SDN control as applying to both physical and virtual devices while others say that ties one of SDN’s legs to a tree before the race.

Here again we have some good points, but not necessarily good discussions.  I’ve said for months that SDN to succeed has to be made a two-layer model, where the top layer is totally virtual and agile and is directly controlled by software, and the bottom layer is controlled by policy to provide services to the top.  This is actually the SDN model that gets the most deployment, but because we’re still not thinking in these terms, we’re not answering the critical questions.  One is how the two layers interact—the boundary functions exposed by the bottom as services—and the other is how the policies are enforced onto the real infrastructure.

Which I think gets back to service models.  We’re messing up a whole industry here because we can’t think in modern terms about the product of a network—the service model.  I’m hoping that the SDN World Congress will at least raise awareness of that issue so we can get it behind us.