Month: March 2013

Oracle’s decision to purchase Tekelec, having just done the Acme Packet deal, seems to be indicating that the software giant has something in mind.  The question is what that something might be, and it’s a pressing question because of Oracle’s size and potential in the network market.

The obvious possibility is that Oracle is looking to expand its portfolio in support of UC/UCC.  The fact that it’s picked up two companies in the VoIP space actually reinforces this possibility.  You could argue that Acme had some history in deep packet inspection, which has a broader mission for the future—including support for NFV as I noted when I blogged about the Acme deal.  While Tekelec has created hosted versions of some of its voice functions, that trend isn’t really linked to NFV at this point, simply because we don’t have any NFV architecture against which this stuff could deploy.  Content delivery networks were on the target list for NFV in the white paper, you may recall, and we’d been seeing a shift of CDN implementation from appliance to cloud before NFV was even dreamed of.

If UC/UCC is the driver here, then Oracle has to be betting on some major systemic trend that the classic vendors in the UC/UCC space aren’t seeing.  One good possibility is that Oracle is seeing a transition from TDM to IP voice on a more aggressive level, an active migration, and that would open a host of UC/UCC-like services for both business and residential users.  Another possibility is that Oracle is seeing the NFV trend creating a kind of “open IMS” framework where RAN players won’t be able to dominate IMS deployment like they’ve done so far.

A third possibility is that Oracle is seeing the elimination of the PSTN completely, a transition not to a carrier-hosted VoIP model but to an OTT model.  This transition will obviously be resisted by the major carriers and the major network equipment vendors but embraced by the Googles and Microsofts of the world, which would mean that if Oracle wanted to be a player in the future and compete with those two, Oracle might need its own voice strategy.  Everything Oracle has purchased would facilitate a deployment of something Skype-like but with a stronger SIP flavor, at least in the sense of being able to interwork with SIP and PSTN calls.  That would give Oracle three avenues to pursue; sell to operators, sell to OTTs, or deploy their own service set.

If Google and Apple and perhaps even Microsoft are looking at being MVNOs, as I’ve suggested they might be, then Oracle may have to take action now.  Mobility is the major driver of application changes (point-of-activity empowerment as I’ve been calling it) for both enterprise and consumer, which might make it a major driver of software overall.  Oracle might even be looking at handset deals in some way, and Oracle buying Blackberry would be a lot more logical than it buying a network equipment vendor for example.

How about “all of the above?”  I think there’s clearly a lot of competitive counterpunching in Oracle’s M&A, not the least because Oracle is first and foremost a sales-tactical player and not a strategic player at heart.  NFV may not be a specific target for Oracle but it may be a symptom of a functionality shift from network to IT that Oracle either has to play for its own benefit or see as a pathway through which it could bleed market share.  They just turned in a frankly bad quarter and their only real strategy (so their earnings call said) was more feet on the street.  That’s not going to cut it, even for a sales-tactical player, if the market is really changing at a strategic level.

The next question is “Who next?” both for Oracle and for competitors.  There are still some SIP players out there (Sonus, for example) and there are certainly Oracle competitors.  IBM has stayed out of this fray, but it’s not too late for it to move.  Players like NSN, who have narrowed their product focus to a pure mobile broadband play, may need to think about buttressing their voice and UC/UCC potential.  In short, this could be interesting.

Alcatel-Lucent is scheduled to announce it’s “data center SDN” vision next Tuesday (April 2^nd) and the announcement may well be one of the most important in the company’s history from the perspective of addressing a compelling need.  Whether it will be important in the sense of moving the SDN ball forward, even in the specific confines of Alcatel-Lucent, is what I’m going to have to be watching for.

The lowest hurdle Alcatel-Lucent has to clear is the validation of their Nuage acquisition.  The announcement is a Nuage story according to their advance material, but all that Alcatel-Lucent really has to do to make its decision look strong is to demonstrate a useful mission for SDN.  That’s not all that hard to do, right?

In the data center it is.  If you look at the data-center SDN stuff, it’s tended to focus on creating segmented or overlay networks.  I’m not disputing for a moment that you need some mechanism to segment public cloud data centers to support a large number of users who have to be completely isolated from each other—read VLANs of some sort.  That’s what Nicira has been focusing on, after all, and there are other developments (the IETF’s NVO3 for example) as well.  But the network of the future isn’t made up entirely of public cloud data centers that need multi-tenant isolation, and even if it were I’d argue that the Nicira overlay approach might well suit that very specific mission.  As I’ve said all along, you can’t co-opt software defined networking for software-defined connectivity, which is all this stuff does.  Alcatel-Lucent has to be wary they don’t fall into that trap.

The second point is that once you cast the multi-tenancy mission aside and look at general data-center needs, you’re struck with the question of just what SDN does.  Yes, it’s a great approach to building better multi-switch large-data-center LANs.  The question is how many of them you are going to need, and also how SDN-linked switches would differ from fabric solutions.  My view is that if you’re looking at cloud data centers in a general sense, meaning public cloud and private/enterprise, then you need to rethink the whole architecture and ask what an optimum connectivity solution would be given the evolving mission, which includes private and hybrid cloud but which is really dominated by more dynamic application-to-worker and component-to-component relationships. Remember point-of-activity empowerment?

The next point is the network operator.  I remain convinced that the most fertile field for any new data center architecture is the place where the most green field data centers are going to spring up.  That’s the network operator in general, and the metro in particular.  In the next five years operators could deploy more new data centers than enterprises have in total.  What are their requirements?  At a per-data-center level we can muse about that one for ages, but there’s one reality about these new data centers that is not only unequivocal, it’s fundamental even to the “public cloud” stuff we started with here.  These data centers are highly interconnected.  CDN is an operator-cloud application, for example, and you can see immediately how interconnected it has to be.

That’s what I’m worried about with regard to Alcatel-Lucent’s announcement.  It’s fine to make a data center announcement for SDN, but I’m not of the view that data center by itself will present a compelling story for network operators, and I’m darn sure convinced that if you can’t win with network operators and SDN in the next three years, you may as well pack it in.  Enterprise value for “real” SDN strategies can’t build up that fast.  A market driven by SDN centralization needs, by NFV, and by the top monetization goals of operators, is going to outrun the enterprise in the early years, and this market is doing to be looking not at data center but at metro cloud.  It’s very possible to argue at this point that the interconnect of the data centers is as important for the metro cloud mission as the data center networks are, and if that’s true then you can argue that metro SDN is as important as data center SDN.  And I think there’s a heck of a lot more money in metro SDN.

We are already seeing the router guys positioning themselves for the validation of IP in the metro.  Cisco and Juniper have both been taking steps in a product sense and in the promotion of changes in the IETF, steps designed to validate the idea that the changes in the cloud mission, the metro mission, will demand the displacement of basic Ethernet with IP routing.  Why?  Because they have to, because these guys know that what I’ve been saying here all along is true.  All of the money in the network of the future will be made in the metro, so most of the infrastructure that deploys will go there.  If you want to sell routers, sell metro routers.  That’s what the router guys are saying.  So if you want to sell SDN, you’d better be selling metro SDN too.

 

I’m all for having discussions on the impact of SDN.  I’d prefer they have some substance, though, and we have a couple of examples this morning of SDN-impact stories that don’t (in my mind at least) hold much water.

FRB downgraded both Cisco and Juniper yesterday, citing among other factors the view that SDN was going to reduce the switch/router ports deployed by operators by 40% in 18-36 months.  To me this is a particularly astonishing vision, given that I just finished (and published in our Netwatcher journal) our detailed analysis of SDN and NFV market impacts, and found nothing whatsoever to support any claim of port reductions due to SDN deployment in that period.

Look around your network plant, buyers, and tell me how many SDN ports you see?  The current number is statistically insignificant.  Look on the inventories of vendor products supporting SDN today, and tell me how many are not switches and routers.  The number is statistically insignificant.  Right now, if you want to do SDN in either its central (OpenFlow) or distributed form, you do it by running SDN software on the same switches and routers that Cisco and Juniper and others have been selling all along.  There are no current contenders to “replace” switch/router ports with SDN ports because you can’t do SDN without the same darn ports!

This isn’t to say that there aren’t reasons to downgrade Cisco or Juniper.  I talked about a previous Juniper downgrade in yesterday’s blog.  There is in fact a change taking place in network infrastructure spending, but that change isn’t technology-driven, it’s profit-driven.  Operators are going to spend on the parts of their network that generate the most ROI, and there is very little profit to be made by global, uniform, open connectivity.  Most revenue, as I’ve said, is derived from services that move traffic for 40 miles or less, and nearly all the incremental revenue fits that pattern.  Clearly building traditional edge-core router networks isn’t fitting the profit bill, so less will be built.  But offering SDN technology, even if had some impact on network costs, isn’t likely to change the profit reality.  Will we stop caching content because of SDN?  Hardly.  Will we build one big cloud data center in Missouri to serve the whole US just because we could use SDN to get to it?  In the end, SDN is a somewhat cheaper and more controlled way of moving traffic, but it’s not moving it faster than light and at a negative cost.

That gets to a second story, which is one in Light Reading asking whether SDN isn’t going to hurt operators because it creates all this bandwidth on demand, encouraging enterprises to replace their persistent-capacity services with rent-a-bit services.  First, nobody says that SDN is going to offer bandwidth on demand any more than other technology options we already have.  We can deliver elastic bandwidth with Ethernet and IP.  Second, nobody says that having elastic bandwidth is going to reduce consumption of bits or produce lower costs.  Generally, enterprises say they’d use elastic bandwidth in applications like failover of data center assets into a public cloud.  That sounds like a new application to me, one that generates new revenue not kills off old revenue.

In the real network, the network that ROI builds, the network Cisco and Juniper have to really face, it’s not SDN that’s the driver, it’s NFV.  NFV addresses something that is very real, the displacement of service functionality from specialized devices to cheap commodity servers.  If you were to look at how centralized, software-controlled, SDN could be implemented, the answer is likely to come out of NFV.  Your future security offerings are NFV offerings, and so are the CDNs that deliver your content and the components that support your mobile roaming and your mobile payments.  NFV defines the partnership between IT and the network.  The network of today isn’t about communication but about service delivery, and NFV defines the hosting of service components.

Well, maybe it does.  NFV is just getting started, and its treading a path that other bodies have tried to blaze in the past without success.  I’ve personally worked on standards aimed at creating a partnership of hosted elements and connectivity for five years now.  We still don’t have them.  So now you understand why I think it’s so silly to be thinking about 40% penetration of SDN ports in 3 years or the erosion of business service revenues by bandwidth on demand.  We’re still tangled up in the starting gates of most of the value initiatives in networking.  The guys who ought to be downgraded are the companies who are doing nothing to break out, and we’ll know who they are by this fall.  We’ll also likely know who will win.  Why?  Because 2014 and 2015 are the two years my model says that carrier capex will increase and where opportunity factors will start to drive a new network model.  That means the planning cycle this fall, the cycle every vendor had better be ready for, may be doing vendor triage.

Software giant Oracle surprised the Street with a pretty major miss on their top line, sending their stock tumbling in the after-market yesterday and pre-market today.  The truth is that the Street may be underestimating the questions here, because all of the indicators for the tech space says that Oracle should be doing better.  Software has a more direct connection to productivity gains and thus can drive benefits and projects better than hardware.  Hardware is nearly impossible to differentiate, and software is all about differentiation.  So what the heck happened to these guys?

Market shifts, for one.  Business confidence suffered in the last quarter for sure, and that may have had an impact on projects.  The problem is that it didn’t stall Oracle’s rivals as much as Oracle, and our indicators tell me that the real problem has to be something beyond simple macro conditions.

One issue is clearly the hardware.  Oracle’s hardware numbers slipped again, and it’s pretty obvious at this point that they will never make a go of general-purpose servers.  Yes, there’s a product transition, but why has it been so dramatic?  Companies have these all the time.  What’s disappointing is that they can’t make up for that server shortfall by creating explosive database appliance sales (30% growth here simply isn’t enough; they should have been able to double that), which means that if they don’t fix their problems their whole hardware strategy and the Sun acquisition is toast.

The bigger second issue is Cisco.  Our surveys tell us that Oracle is getting hurt by Cisco more than IBM or HP, because Oracle’s hardware business has traditionally focused on the communications applications that Cisco has gone after.  UCS has been a big success, perhaps the most significant success in all of networking even though it’s not a network product.  Furthermore, with operators talking about SDN and NFV, servers could be the mainstay of carrier deployments and infrastructure in the future.  Oracle needed to hit the ground running in all of these areas, and it’s just not moving the ball at all.  I’ve never seen them out-marketed as thoroughly as they have been in the comm-server area.

But all of this pales in insignificance compared to Oracle’s problem with the cloud.  The company’s anti-cloud stance in the early days, stated with Ellison’s usual forceful style, has made it very hard for Oracle to create an effective cloud position.  They’ve failed most particularly in generating a strong architecture for a “Java cloud” and for PaaS, even though it’s obvious that these two areas could be highly differentiating for what’s after all a software company.  A good cloud strategy with a strong articulation of database appliance relationships to cloud services could have helped the appliances but also showcased the servers.  Solaris is the best commercial real-time OS on the market, and it’s amazing that Oracle hasn’t been able to leverage that truth.

The most alarming thing is that cloud strategy is darn sure where Cisco is taking the game in the network-server world, and nobody has to ask why.  Cisco is naturally good at IT/network fusion, and in any case what the heck is a cloud if it’s not network and IT?  Oracle seems to have missed this obvious point, not perhaps completely in its marketing but at least in an effective sense.  They need leadership in the cloud.

Ironically, this quarter might drive Oracle to do something truly, fatally, stupid while trying to do something smart.  There are already insiders there who tell me that one camp of executives believes that Oracle’s problem is that it needs network equipment like Cisco has, that they should buy Juniper or Brocade.  I think that’s the wrong approach.  You don’t win a puzzle-solving race by buying more pieces to make the puzzle bigger.  The fusion of IT and networking that forms “the cloud”, that’s driving SDN and NFV, is a boundary function.  You don’t have to be in the network to own the stuff that network technology initiatives are working to move out of the network.  If you’re in the IT space with the right boundary position, you just open your arms and gather them in.

At this point, it would seem that it’s too late for Oracle, but I don’t believe that either.  Cisco could have shut them down this quarter, eradicated Oracle’s own hopes of becoming a full-spectrum IT giant and thus killed off a formidable risk for Cisco, but Cisco is still being too conservative at that network/IT boundary.  Falling prey, as vendors nearly always do, to the obsession with defending current markets and products (which, in the long term, will decline in TAM) has kept Cisco from taking the steps that would have set up a conclusive Cisco victory by about 2016.  And that means that Oracle could still, if they were smart and aggressive enough at just the right place in the network/IT picture, pull off a comeback.  But make no mistake, this quarter was a big mistake and it’s going to take something big to really fix it.  Otherwise Cisco has stepped over its first IT victim on its road to being the self-described IT leader.

The OFC event is offering us a pretty clear picture of a pretty dramatic contradiction, if that’s not a contradiction in itself!  On the one hand, it’s increasingly obvious that there is going to be a lot of optical activity in the next two or three years, but on the other hand it’s clear that Wall Street believes that none of the optical system players are going to cash in.  They like the component people.

To drive the point home, Goldman Sachs downgraded Juniper at the very moment that the company was announcing a new “core router” that’s based on the PTX optical exchange product family and declaring itself to be an optical company.  They noted that the core router space was in continuous decline and that Juniper’s market share was in any event at risk to Alcatel-Lucent and other players there.

The story behind this all is one I’ve been telling you for some time—the metrofication of networking.  When you shift from delivering connections among users to delivering experiences to users, your traffic patterns change.  No more any-to-any because there’s simply not that much widely popular material to experience.  Look at the top movies or top TV shows or top books on the best sellers list; there aren’t that many items.  If you have 80% or more of your traffic focused on a couple hundred content elements, you’ll cache them all in every metro area.  Content drives up access and metro bandwidth needs, and drives you more to fiber distribution, but it doesn’t do much for core networking, which is fine because nothing goes through the core that can make any money.  You have long-haul Internet access and you have business VPNs, and both are under constant price pressure.

Then there’s mobile.  The average metro area has a couple hundred central offices, but it might have twenty or thirty thousand cell sites.  As you move to LTE deployment you’re not going to feed towers with a couple T1 lines, you’ll use 100M Ethernet at least, which means fiber.  But here again we’re not seeing a mobile market that’s a profit hockey-stick on the charts, so there’s a lot of price pressure on the devices.  There’s also precious little differentiation among products based on features; you just need to push cheap bits upstream toward a service point.

And finally, the cloud.  Presuming that we do have a dramatic increase in cloud computing, how far do you think carriers will haul cloud traffic?  Cloud users, whether they’re consumers or workers, are counted in population data.  Population is in metro areas.  Any good metro area will either have enough cloud demand to justify metro data centers, or there’ll be no cloud market to care about.  Sure there will be players dabbling with cloud services over the Internet, like Amazon or Rackspace, but for real cloud opportunity they’ll either have to push their own servers into metro areas or they’ll be eaten by operators who can use local servers and short network connections to generate better response times and higher reliability.

So why, arguably, aren’t vendors like Cisco and Juniper telling a better story in metro?  In large part it’s because they don’t have any RAN, and absent a radio network strategy you don’t have much of a mobile strategy, and without mobile you’re missing a big metro driver.  They also don’t have an arresting IMS position, which is the next thing on the checklist.  But both Cisco and Juniper do have a mobile story in the EPC sense at least, and there’s where I think both companies have made a mistake, because you could tie EPC to metro cloud.

Operators need to completely rethink “networking” for the metro of the future.  We go from a hundred COs to tens of thousands of cell towers, to delivering 80% or more of traffic from a cache point 40 miles or less from a user, to building services by assembling virtual functions and controlling networks with explicit central functionality rather than distributed adaptive behavior.  If differentiation is important in sustaining pricing power for a vendor, what’s a better place to look for it than in the heart of a revolution in metro?  But where’s the revolution from either player?  Juniper did announce a notion of hosting elements of EPC, but didn’t tie it to NFV.  They announced a great metro router (see my blog of yesterday) but didn’t assign it any specific metro mission, they just washed the story with the “metro” and “optics” taglines.  Juniper has every single component needed to build the metro cloud of the future today.  They don’t talk about it.  Cisco has the same, and they’re not talking either.

I’m sure by now that everyone who reads this blog knows my view that the hot spot of networking is metro-cloud.  Juniper just announced a small-form-factor member of its PTX optical transport box that’s designed in large part for metro applications.  The PTX 3000 is part of the Juniper “Converged Supercore”, which is a distributed architecture for an integrated optical/electrical core transport network based on MPLS.  The company is going to be pushing this product at OFC/NFOEC, which has created a bit of a media stir because Juniper seems to be elevating its optical credentials and because it’s calling the new model a “router”.

We’re spinning a lot of useless cycles on these points, frankly.  First of all, the PTX family has been an LSR (Label Switch Router) all along; it’s an MPLS device, has an IP control plane, and runs Junos.  Second, obviously, it’s been optical all along too.  There are two differences here, both subtle, and some ongoing questions about what Juniper might do next.

The first market difference is that optical capacity is now in ascendency; it’s cheaper to create bits than to manage a lot of aggregation, and unit cost of bandwidth has to fall quickly because of retail price pressure.  So any network that’s going to be carrying a lot of traffic has to be bent toward the optical layer, thinning down the complexity of electrical-layer aggregation.  So there’s nothing wrong with shifting your push toward optics, claiming to be an optical company.  Everyone who wants to be into high-capacity transmission of bits has to be one.

The second market difference is the one I’ve been talking about—metro cloud.  Nearly all the profitable Internet traffic transits less than 40 miles, meaning it never leaves the metro area.  Smaller form factors for the PTX mean that you can run them out toward the CO to build a fiber-based virtual LSR that covers a metro area with high-capacity, low-latency routes.  That’s a good thing, a very good thing in fact.  Juniper has been fielding a better solution to IP and metro cores for a while, but the smaller PTX improves the distributability of the solution, which not only means more sites to host stuff, it means more potential sales.

There are still some kinks to work through here, though, to address the full opportunity.  One important one is the relationship between QFabric and the PTX, which is one of my ongoing issues with the positioning of the products.  In a metro-cloud, nothing would be more logical than to link cloud data centers supported by QFs directly to metro-fiber cloud cores supported by PTXs.  The problem is that the PTX is, as I’ve said, an LSR and it needs Label Edge Router (LER) functionality to get traffic onto it.  QFabric isn’t an LER, and that’s something I think Juniper needs to fix.  There are two ways to do it; add LER features somewhere or support OpenFlow on both devices.

LER features on the PTX or on QFabric seems quite feasible.  Adding “complete” LER capability to either of the two product families probably doesn’t make sense.  Truth is that you don’t need packet routing in a traditional sense in a dense core, metro or otherwise.  You’re switching routes, not packets.  All you’d really need is to have an Ethernet on-ramp to an LSP and you’re home.

By the same token, supporting OpenFlow connectivity between the two devices would be easy.  If you can do LSR MPLS switching in something you can do OpenFlow switching with not too much more than some control logic, which should be easy enough since Junos runs on both these devices and is adding full OpenFlow support over time.  Juniper people have told me several times that it was in fact possible to link PTXs and QFabric via OpenFlow.

If I were Juniper, I’d jump on the LER solution big-time.  Metro is where all the money is going, and metro-cloud is the mission that’s going to drive metro.  If Juniper were to provide good coupling between the PTX and QFabric they’d have a single-technology cloud-distributed fabric that could not only span a whole metro area (even one with an enormous population and traffic level) it could be interconnected with an OTN core and create a national or even global cloud core.  I’d hoped to see something about this in the latest announcement, but I didn’t catch any reference to LER capabilities in Juniper’s material or in reporting on the topic.

On the SDN-interconnect front, Juniper has to make a choice.  There is no question that it’s to the advantage of any incumbent router vendor to create an MPLS-dominant strategy in metro because it sells routers.  It’s likely that operators will want SDN support too, and of course you can fulfill SDN missions without OpenFlow.  So Juniper has to decide whether to buck the OpenFlow trend and create an SDN story that’s very IP-centric (as rival Cisco is doing) or to support OpenFlow and an IP/MPLS SDN story in parallel.  Smart choice?  The latter.  OpenFlow-based SDN isn’t likely to progress fast enough in the higher layers to be a threat, and having a solution based on OpenFlow would make Juniper’s position harder to assault, whether the rival is Cisco, Alcatel-Lucent, or Ericsson.  There would be no simple and obvious omissions that competitors could push against.  Watch how Juniper evolves this; it will tell us a lot about how they’ll fare in the future and how fast metro-cloud will become a market issue.

Some of Cisco’s bigwigs have been talking SDN at the Cisco Tech Editor’s conference, and the sum of their perspectives validates our view that Cisco’s plan for SDN is to seize its benefits without embracing much of its technology.  Before you decide I’m off on another rant, let me add that I think that’s perfectly fine.

Before Cisco started singing its SDN tune, the whole SDN movement was a technology in search of a value proposition.  We were hearing about goals like “separate control plane” or protocols like “OpenFlow” but we weren’t hearing much about business value, or even about how software was doing all this network-defining stuff.  Cisco has stepped up and put some substance around the top of SDN, and as I blogged at the time that’s a good thing.

There are, they say, many ways to skin a cat, and Cisco found (or knew all along) that it would be possible to meet SDN higher-level goals without doing anything much to the way that routers in particular behave.  In fact, they found that if you do some extensions to current Internet protocols like BGP you can make an argument for more routing in the future by making it easier to drive specific network behaviors through current network technology.  The thing that’s still at least vague if not missing in Cisco’s vision is the details on the software-to-“SDN” interface.  Exposing all of the current network features in a bazaar-like hodgepodge of APIs isn’t going to make software control possible, it’s going to make network stability questionable.

Alcatel-Lucent is expected to make an SDN announcement on April 2^nd, and Light Reading is reporting it will likely integrate Network Functions Virtualization (NFV) as well.  They also reported on a financial-industry report that’s asking whether NFV might have an impact on the network equipment market.  Good question, not only for NFV but for SDN, and the big step needed to move toward answering it is the step of defining that central process.

The logical template for everyone in the SDN and NFV space to use as their “descriptor” or high-level APIs is OpenStack’s Quantum interface, not because Quantum has all the answers but because 1) Quantum is likely to represent a cloud’s-eye view of SDN service requests and 2) what Quantum doesn’t do well can show us what the best complete strategy would look like.  Quantum focuses on creating an “application network”, meaning one that can host applications and then offer application services to the masses.  The logical model is a subnet (a virtual LAN) that includes IP-addressed entities and the service components above the network (DHCP, DNS) that make the application network a part of the glorious IP whole.  Obviously we can’t have SDNs that are only part of IP networks or that obey a pure subnet model because we have demonstrations already (Google in the IP core, Ericsson in the metro) that don’t fit that model.

Cisco, Alcatel-Lucent, Ericsson, and pretty much everyone are committed to Quantum, and so it seems to me that everyone should be speaking out and promising to bind their vision of SDN via high-level APIs to the Quantum interface.  That at least would make SDNs work as cloud application hosts.  It also seems to me that all these players would recognize that we need to be thinking about all the services SDNs might offer, which means all the service models.  We know of three connection topologies, for example; LINE, LAN, and TREE.  Why not start by defining three connection models, and then define a series of “service models” (IP, Ethernet, whatever) that ride these connection models.  At that second level you can start to define components like DHCP that are needed for the service you define.  You could also look at introducing NFV “virtual functions” where they are appropriate to a service level, as a firewall would be to an IP service.

Taking things to this level would define a simple high-level SDN API.  Think of it as being a command that looks something like this:

BuildSDN(connectionModel, serviceProtocol, endpointList)

So you tell me—is this not an example of a useful highest-level description of an SDN service?  Does it not easily take us to the next level, which is defining what it takes to create the connection model and extend the service protocols to the listed endpoints?  Could application developers use an interface at this level?  If all of this is true, and I think it is, then you have to wonder how we’ve avoided saying something so simple as this for all this time, and how we’ve thus avoided drilling down from need to implementation in a useful way.  It’s time to make all these SDN players start at the top.

Well, it’s “Recap Friday” again, and fortunately there are quite a few sound bites we can recap this week.  At the top of the list is the Credit Suisse report on their Next-Generation Data Center Conference.  Like most of these conferences, it was a vendor love-fest littered with the usual exaggerations (and perhaps a few outright lies), but there was some decent pickings among the details.

On the SDN front, it’s becoming clear that server consolidation is indeed driving data centers to scale up, and that this is increasing the primary problem that enterprises face in the data center network, poor resource efficiency due in large part to the natural inefficiency of Ethernet switching.  What SDN can do is to almost eliminate that inefficiency by permitting explicit flow routing and thus better utilization…maybe.  The qualifier here is that of the three models of SDN that we (reluctantly) recognize, the overlay model doesn’t really bear on this because it doesn’t influence per-device routing, and the distributed model doesn’t bear on it because the protocol development to support it is at the IP layer and not Ethernet.  Only the “centralized” OpenFlow model works.

We also have to point out that the trend is speaking against traditional fabric solutions.  A fat data center that’s fat on scaling up traditional applications doesn’t create cross-component traffic and require any-to-any connectivity.  What you need in this kind of data center isn’t non-blocking any-to-any, but malleable some-to-some.  This validates traffic-based malleable-capacity models like Plexxi versus fully connective fabric models.

There were also (as expected) some cloud claims in evidence.  One is that adding private cloud to virtualization could increase your efficiency by an enormous quotient, which I don’t buy for a minute unless we assign the term “could” to events whose probability is equal to that of your flapping your arms in exasperation and launching yourself over the rooftops.  What is important in justifying the transition from virtualized data centers to a public cloud model is the ability for applications to exploit highly dynamic resource pools.  We are not there yet in most enterprises, and we’re not getting there in the next couple of years.  When we start that move, it will be more to exploit “externalized” dynamism, the ability to roll components into public-cloud overflow resources.  That doesn’t require a redesign of the local data center.

Speaking of cloud, we have the story that IBM and EMC are both looking to acquire cloud provider SoftLayer, perhaps spending a couple billion on the deal.  There is nothing remarkable about SoftLayer’s service offering in my view; it’s IaaS and that’s not the way of the future.  However, they have stuff in place, they have a framework from which you can create your own cloud or host on theirs, and they’re privately held.  They also have decent marketing/positioning, and that may set them apart from rival Joyent, who actually has better technology but has been completely hopeless in articulation.  It pays to sing, gang; let this be a lesson.

I think EMC is a more likely winner here, or at least they have more to win than IBM, but I also think somebody like Cisco should be the one looking to deal.  You cannot be a provider of cloud infrastructure if you don’t offer a public cloud service to ease your customers onto a private cloud and to showcase your wares.  You can’t be an IT kingpin without offering cloud infrastructure, and Chambers says he’s going to make Cisco an IT kingpin.  QED.  But EMC does need a cloud too, particularly given its new push on Pivotal, though SoftLayer is stronger in the SMB space where things like cloud-specific applications are a ways out, adoption-wise.

On the SDN front we have news that Dell is favoring SDN standards via OMG.  On the one hand, we sure seem to have enough people wanting to define SDN standards these days—so many that a gladiatorial match to cull the herd may be in order.  On the other hand, I’m firmly behind the notion that we need to be looking at everything relative to software control of network services in object terms (and so who better than OMG?)  The key question for SDN, though, is the timing of a holistic vision.  We do not have that now, not from anyone.  We have itty bitty SDN pieces that a vendor has glommed onto and tried to make into a sexy story.  For example, if data center efficiency is a goal and traffic engineering is the path to that goal, then the Nicira overlay model is a complete waste of time because you can’t engineer traffic with a network overlay that the switches don’t even know about.  But if we don’t have a top-down vision of SDN, everyone can claim to be it/have it.

I think this whole issue of SDN standards is going to come to a head in the Network Functions Virtualization area.  Unlike SDN, NFV is focused on function hosting, which forces it to consider a network as a service-layer cloud of features.  Logically that’s a software framework that logically needs an object model to define it.  Otherwise functions are neither portable nor can they interact with each other, and both those are required if NFV is to meet its stated goals.  SDN has gone so far and gotten so diffuse that I don’t think it’s possible to fix it any more.  Somebody will have to envelope it; whether it’s OMG or NFV or NFV endorsing OMG, something has to take the right slant on this.  And even OMG and NFV can be too late to the party.  My model says that both concepts are dead if they’re not completed by 2015 because by then pressure on network cost will have driven operators to proprietary strategies.

The EMC/VMware dog-and-pony show on the Pivotal Initiative may be a kind of turning point for the cloud, or more correctly it might be the second of two turning points.  It’s certainly going to be a key element in the forward planning of the players, and in my view it’s possibly the beginning of market recognition of the “truth of the cloud”.

Most people would cite the dawn of the cloud age as the dawn of IaaS, but the real question isn’t what started a trend but what establishes it.  Protoplasmic mites may have been necessary conditions for manned spaceflight; it’s probably unrealistic to think they’d accomplish that goal without a bit of evolution along the way.  You don’t create an IT revolution by deciding whether you favor public or private shared hosting.  There’s just not enough money on the table because there aren’t enough compelling benefits.  Everything we’ve experienced in the cloud today hasn’t moved us out of the primordial soup.

The question, of course, is what will do that, and I think that we could deduce the answer if we’d take the trouble.  If you want to make the cloud a revolution, then you have to be able to create something in the cloud that’s way more valuable than the pre-cloud stuff.  If the cloud is only a cost revolution, it’s ultimately going to be a subtle play on relative economies of scale.  If it’s a benefit revolution, the sky’s the limit.

If you’re creating a benefit revolution, though, you have to present something that wasn’t there before.  Push Word into a hosted form and what benefit do you have?  The same one you had locally.  OK, maybe you can say that you can access your files anywhere, but I’ve carried a laptop around now for maybe 20 years and that gave me “anywhere-files”.  OK, then you say “well, you could lose your laptop”, except that I can then say to cloud-Worders “well, you could lose the Internet a lot easier”.  You get the picture; we’re dabbling here.

I think the compelling argument in favor of Pivotal is that you can’t create a benefit revolution without a benefit-driven architecture for the cloud, an architecture that focuses on building cloudy things where nothing could have been built in pre-cloud days.  The key statement from EMC/VMware in December at the Pivotal launch was “We are experiencing a major change in the wide scale move to cloud computing, which includes both infrastructural transformation and transformation of how applications will be built and used based on cloud, mobility and big data.”  Dissected at one level, that means Pivotal will address the transformation of applications to a newer benefit-biased form, based on harnessing flexible resources, point-of-activity empowerment, and expert-agent analysis of large quantities of activity-contextual data.

You can dissect too much, though.  A bank runs a commercial that shows a mother and daughter coming into a competitive bank to count coins so the little girl can buy a dollhouse.  The robo-bank decided that she wants a mortgage, that her age is the term she’s looking for, and thus makes a nonsense offer.  That’s an example of a failure of point-of-activity intelligence to consider context.  But you can see from this example that the process of making the cloud into an agent that can support work or life in an appropriate way is no small one.  It’s not just pushing a bunch of servers into the cloud, or saying you have cloud support for big data.  And that’s the too-much-dissection risk.  Progress at Pivotal can easily become the creation of support for the nuclear objectives of the initiative—cloud, mobile, big data.  Pivotal has to be a cloud architecture for analytical empowerment of mobile users through contextual data injection.  And that’s where Pivot has to start, if it’s ever going to make the grade.

Our primordial mites could collectivize and build something that has the mass of a modern human, but at the completion of that mite Granfalloon won’t even be smart enough to drag its knuckles, much less launch a Saturn booster.  Pivotal, to succeed, has to start at the top, with the fusion of things that make point-of-activity empowerment real.  Otherwise we’ll step on its remnants next time we’re out in a bog.

Ok, I admit I have a cynical bend to my mindset.  John Gallant, bigwig at Network World at the time, called me “curmudgeonly”—and that was back in 1999!  But anyway, when I read an article these days I assume there’s something in it that’s going to set me off.  Today, it’s a piece in LR about a new core router startup.  Can it, the piece asks, avoid the “curse of core routing?”  Well, that depends on whether we understand what the curse is.

Any study that’s ever been done on network economics has pointed out the price per bit for bandwidth is lower the deeper you go into the network.  One I recall from about a decade ago was showing that the price per bit of SMS was about a million times what it was for the Internet core.  So we can start our exploration of the curse by speculating that any time you’re trying to provide a product for a spot where the price per bit is in the toilet, you’re going to see a lot of brown in your future.  Core routing startups probably fail first and foremost because you can’t make money in a space where operators can’t make a profit.

And it gets worse.  We live, says a company spokesperson, in a petabit age.  Well, yes, but not all in one place.  The successor financial truth to my first point here is that all of the valuable services we’ve defined to supplement pure bit-pushing are serving mass markets.  Content is a big revenue generator because it has a big audience.  The cloud will be a big success to the extent it can produce the same thing.  Mass audiences are massive because they’re pervasive.  If we have a bunch of people who want to stream video, we have a bunch in the major metro areas.  Most of that streaming will focus on a couple of hundred titles.  That means that we can host content directly in servers or through CDNs in every metro area and serve most of the video.  Which means that the content traffic, petabits or not, never gets out of the metro.  It will be the same for the cloud.

So maybe you’re bored with the financial spin here (you shouldn’t be; we are what we spend, network-wise).  Let’s look at a technical point, in a bit of a whimsical form.  If we find people congregating more and more at the ferry landing, we can think of designing a ferry with bigger decks, more decks, higher speed…or if we can see the far shore a couple of hundred yards away, we can just think about building a bridge.

We don’t need a revolutionary router, we need a revolution in routing.  Routing has inherited a conceptual model of open connectivity that isn’t viable in the current world where nearly everything we want comes from a couple dozen sources.  In fact, an increased chunk of our network dollars are being spent building firewalls against the connections we’ve allowed by default at the network level.  Routing also presumes a hierarchical structure, an aggregation toward the core, and that’s valid where traffic is evenly distributed among a bunch of connecting peers.  Is it true for the Internet even today?  I submit that operator pressure on OTN is already demonstrating that they don’t see the future as bigger, faster, routers but as networks that connect without a traditional core at all.  Even SDN is aimed in part at creating that sort of future; it’s what Google has demonstrated in its own SDN work.

The network of the past was a connection network designed to transport what endpoints generate.  The network of the future is an experience delivery network, designed to gratify the masses with what they want when they want it.  The simple dynamics of content production and data center economies of scale demand that real opportunities be realized locally to the populous user communities—metro.  We don’t have movies talking to each other, and even in the cloud where some interprocess communication can be expected, we’re not likely to have enough processes to create a huge connectivity issue in the metro.  Users connect to point of service.  We need to be thinking about how to build this kind of network, because this is the network that operators are moving toward, following (you guessed it!) the money.  It doesn’t mean we won’t be able to watch stupid pet tricks (they’ll be cached in every metro by Google, who caches YouTube already) or that we won’t be able to send emails or IMs (each of us connects to a server, which connects to other servers, so we’re not in direct user-to-user connections anyway).  But even things like personal video are going to be shaped by the reality that we’re happy to use it to the extent it doesn’t cost us much.  If it doesn’t cost much, operators won’t spend to sustain it.

Every network product, every standard, every initiative or industry group, will stand or fall ultimately on the question of utility.  Does this concept offer enough value to someone, on a large enough scale, to produce a return on the network investment it suggests?  If the answer is “No”, then it’s not going to amount to anything other than music for the media/analyst dances.  If we want to be entertained, let’s not do it in technology publications.  Let’s just watch a stupid pet trick video.