Can Operations Join Top-Down and Bottom-Up in SDN and NFV?

With news that Intel is announcing a platform (“Highland Forest”) for hosting network functions for SDN and NFV and an HP exec is taking the role of chairing the ONF’s “northbound API” group, it would seem that our world of “software-defined-everything” is taking on new life.  I hope so, but there’s still a question of whether we’re attacking the right problems.  We may be seeing less SDN/NFV-washing, but we’ve still got a lot of light rinsing going on.

SDN and NFV are starting from the bottom and working their way upward.  We have low-level technology solutions well-defined, and yet here we are just taking up those critical northbound APIs.  How do you build value for something when it’s disconnected from rational paradigms for use?  The problem, of course, is that the opposite is true too.  How do we create credible value for SDN or NFV if we don’t understand how to evolve them from the trillion dollars or so of current investment?  So we’re left with the old “groping the elephant” paradigm; we don’t have a truly systemic view of the network of the future and so we’ve got a lot of things happening that depend on the completion of a task everyone isn’t eager to face.

Not eager?  Why, you might wonder, would network vendors and others be unhappy with a complete SDN/NFV story?  Because it’s pretty clear that the world economy is recovering and that’s created a hope for a tech spending rebound in 2014.  This is not the time when anyone wants technical planners at network operators or enterprises to start humming “Let the old earth take a couple of whirls” when it comes to planning projects and launching spending initiatives.  The focus of the industry right now is not to build value for either SDN or NFV but to demonstrate that what you buy now can be fit into a puzzle for SDN and NFV later on.  That way, you buy now—so they hope.

I think that there is some credibility to the notion that a new hardware platform could be valuable in an SDN/NFV age.  However, I also think that we have ample proof that current software technology from companies like 6WIND (who I’ve mentioned in prior blogs) can provide data plane acceleration to COTS servers.  Before we declare that we have to move into new hardware combinations, we need to understand why this approach wouldn’t be better overall.  After all, it would preserve the value of current server technology.

I also think there’s credibility to the standardization of northbound APIs.  However, I have to wonder if, as you build up from your skyscraper foundation toward the sky, you might not encounter a point where knowing what you expected the roof to be was as important as knowing what’s holding you to the ground.  Can we realize those APIs fully with no clear vision of what we mean by “SDN services?”  If we try, do we not risk building APIs that can do little more than support our current conception of networking?  There is no SDN or NFV revolution if we use different technology to create the same services at the same cost points.

Over the last year, I’ve watched as operators have matured their views of the network of the future.  It started, arguably, with frustration with their vendors boiling out in a “replace proprietary with COTS” model.  Who can blame them; for almost eight years now operators have been asking for support in business model transformation and not getting it.  But in the summer these same operators were recognizing that capital savings won’t do the job; they have to look to profound opex changes and savings.  Now, the leaders are saying that won’t be enough either, we need service agility and the ability to quickly frame offerings to suit the needs of a market that’s increasingly tactical and consumeristic.

All of these new things are at the top of the service food chain, above not only “Level 3” but above all the OSI layers.  Truth be told, they are service creation and service management activities and not traditional networking activities at all.  Do we believe the operators as we describe the future?  I think we have to, and if we do believe them we have to start thinking about how the stuff above the hardware platforms, even above those northbound APIs create the benefits that these operators will demand if they’re to invest in SDN or NFV at all.  If we can’t build down from those benefits to meet the bottom-up-VMs-and-OpenFlow model that’s evolving, if we can’t secure both evolution and our driving goals, then we’re watching a PR extravaganza and not an industry revolution.  In that case, Cisco’s problem with “infrastructure SDN” wouldn’t be that it was too conservative for market needs but that it was unnecessarily radical.

And do you know what?  The same battle between sustaining current spending and securing the future is taking shape up there in the management and service creation layers.  I think I recounted my experience of sitting in a big meeting with a Tier One and listening to one person say that NFV had to support the current operations practices and investment while the person sitting next to them said they needed NFV to quickly replace both.  The TMF is actually grappling with some changes in its architecture that would acknowledge the business and service reality of the network of the future.  I’m not getting a lot of comment from the OSS/BSS guys to suggest that they’re rushing out to make that same sort of thing happen at the product level.

Here’s my suggestion to everyone.  The evolution/revolution balance is set by benefits.  If the future is really, really, valuable then there’s a lot you can tolerate in terms of costs and write-downs to get there.  If it’s only marginally valuable, then you can’t fork-lift even a small pallet.  By not looking to the skies here, by not specifically framing our path to the value of both SDN and NFV in the long run, we’re making it harder to justify even tiny little steps in the present.  I believe firmly in the value of both, and so I’m determined to get those benefits on the table.  That’s my promise for 2014.

Leave a Reply