Month: November 2019

Fierce Telecom did a nice piece on the Top 12 Telecom Disruptors of 2019, focusing on the vendor side of the industry.  I’d like to propose that the top disruptor isn’t on the list, because rather than being a vendor, it’s an “anti-vendor”.  The open-model network is, by the account of operators themselves, vendors, and in my own view, the most important thing that’s happened in telecom since IP.

Open-model networking is in a sense a superset of all the stuff we’ve been talking about for the last decade.  SDN?  It’s in there.  NFV as well.  We can find cloud-native, carrier cloud, 5G, white boxes, gray boxes, virtual networks, SD-WAN, and all the rest tucked into open-model corners.  The whole thing can be seen as an example of how you really should start transformations from the top and move down, because if you start at the bottom it will take a decade for things to shake out to a point where real progress can be made.

A network is a mesh of nodes and trunks, with the former providing for the routing/switching of traffic between instances of the latter, to create full connectivity among the endpoints being served.  From the very first days of data networking, before IP networks were even popular, we built networks with nodes and trunks.  As networks became more essential to businesses, and as operators transitioned to a data-centric service model, vendors supplied the nodal and trunk technologies…at a profit.

The problem with this vendor-centric network vision is that year after year, all public companies are expected to show profit improvement.  That can come only by a combination of raising revenue and cutting cost.  Raising revenue has been the mainstay strategy for network equipment vendors, based on the fact that the public appetite for bandwidth has been growing yearly.  However, the public doesn’t consume routers, it consumes broadband, and the intermediaries in this situation—the network operators—have their own profit-growth goals.  People won’t pay twice as much for twice the bandwidth; they really don’t want to pay anything extra at all.  That’s what launched the open-network model.

The first real interest I saw in open-model networking by telcos was in 2013, before NFV got started.  A big Tier One was looking at the Vyatta hosted-router model, just acquired by Brocade.  The theory was simple; if you had router software that conformed fully to IP standards, and you could run it on a commodity server, you could eliminate the profit margin of the router vendors and build your own network more profitably.

NFV actually kind of short-circuited this early interest; the operator focused on NFV and on hosted-feature models for all devices, but NFV focused on the customer edge devices, the “virtual CPE”.  Another operator (AT&T) has now taken up the leadership position in open-model networking, and they’re elevating the concept to the point where it includes that early hosted-router interest, and a lot more.  Nothing can stop open-model networking at this point, so the question is who will profit from it, and how, and to get to the answer we need to decompose an open-model node.

A node is a combination of feature software and hardware platform.  Commercial off-the-shelf (COTS) servers are a viable hardware platform, providing that the network throughput is adequate and the resource cost is limited.  White-box switches are the other option, a better one where cost/performance has to be critically controlled.  The current trend seems to be to use white-box switches for open-model nodes that are not part of a resource pool (on premises, in cell sites, etc.) and COTS servers where nodal resources are drawn from a pool, and a “universal” solution is needed to maintain pool efficiency.

On the software side, the platform software could be either a scaled-down version of a server OS, meaning Linux, or an “embedded control” or device-specific OS.  The current trend is to use the former for COTS server pools and the latter for discrete open-model nodes.  There are a number of commercial and open-source choices for both approaches.

The feature software itself could, in theory, take one of three possible forms.  First, it could be a simple software instance of a router or appliance, like the original Vyatta stuff.  Second, it could be a virtual network function (VNF) deployed using the ETSI NFV ISG’s mechanisms, and finally it could be a programmable flow machine based on something like the P4 flow-programming standard.  It’s hard to say which of these dominates today, so we’ll have to look a bit deeper at this point.

Today, the reason for the lack of a dominant approach is that we lack a dominant mission.  Simple cloud instances, the “Vyatta model”, are almost surely the best approach where the nodes will serve multiple customers.  While ETSI NFV could in theory deploy “shared” elements, that’s not been the focus of the group, and in my view the work on that mission is inadequate.  ETSI NFV is most useful where a per-customer service is being created by a combination of hosted feature instances, and P4 is most useful when it’s applied to white-box devices that have specialized semiconductor support for forwarding, and are equipped with the P4 driver software.

Over time, what I’d expect to see is a fusion of these approaches, which means that we’ll get a series of “compatible” hardware models, both for specialized hosting of network features in the cloud, and for use in discrete-node applications.  This will be accompanied by a common API set that will present platform features upward to the feature software.  Feature software of all sorts will then be hosted on top, and whether the platform conforms to ETSI NFV management and orchestration or offers P4 flow programming will depend on the feature software itself.

This obviously commoditizes hardware, and a lot of vendors will beat their breasts on that point, but the IBM PC revolutionized desktop computing by creating a commodity hardware model.  You can still make money on that kind of hardware, though obviously not the margins network vendors might be used to.  The defense against that would be to get out of the hardware business, at least for the specific types of our “compatible” hardware models that don’t offer useful differentiation and thus protect pricing from competitive impact.

You could also be competitive at the platform level, the system software that overlays the hardware.  Think of this as the competition among Linux distros that we see today, or the competition among the various flavors of Kubernetes.  Our “compatible” hardware flavors might focus on a series of network missions, and platforms could then support each of the flavors/missions.  That means that vendors could offer a combination of software platform and hardware for specific missions, and work to differentiate themselves through chips, features, and operations support.

In a way, this approach leaves network vendors doing much the same thing they do now—practicing feature differentiation and even some lock-in—but doing it in a different way.  They have to unbundle software and hardware/platform, and they have to obey some standards with respect to their implementation of both, but they can continue to offer proprietary alternatives to any fully open solutions that emerge.

This approach has an obvious problem; being a part of any open-model movement creates a significantly greater competitive risk, particularly when server and software vendors might be better-suited to compete there.  It also has a potential benefit, in that it could prepare network vendors for participation in broader carrier-cloud services, should those services emerge.

The network of the future will be the product of the old smart/dumb debates of the past.  Operators will either have to cut costs to the bone while staying in dumb pipe mode, or climb the value chain.  If they do the former, then their ability to purchase network equipment will be seriously constrained, and that will tip network vendors into the commodity space.  If they do the latter, they will necessarily consume more “feature-hosting” resources.  Network services are also features and can be hosted on these new resources, along with the new service features that live higher on that value chain.  This is a great opportunity for network vendors to look at the feature-hosting, open-model, technology, and make a place for themselves in the space, if they move fast enough to get ahead of the trend.

That’s been the real problem, of course.  Both buyers and sellers in the telecom space have tried to ignore the obvious signs of industry change, hoping for some miraculous force to save them.  It’s time everyone faces facts; they have to do something, something uncomfortable, to save themselves.

What is common to all dreams?  The answer is “dreamers”, and that’s what seems to be dominating the whole 5G, edge, and augmented reality space.  Light Reading’s piece on the subject yesterday talks about how network giants Verizon and AT&T are “hoping” that 5G and edge computing will save augmented reality (AR).  “Hoping” and “dreaming” are different largely in how disconnected each is from “reality” of a different sort, the objective reality of the market.  I think these operators are, as usual, drifting into dreamland.

“Augmented reality” is the process of mixing computer-generated information, images, sounds, and so forth, and the actual scene around us.  As the term suggests, it’s supposed to add information to our inventory of data, almost always by enriching our visual field in some way.  A label that’s superimposed on a face in the crowd could tell you that the person approaching is someone you’d met before, or that the storefront two blocks down on the other side of the street has the product you’re looking for.

There is no question that there’s a need for network-delivered information to do the augmenting of a given reality.  There’s no question that the processing needed to correlate what we see “naturally” with useful augmentations has to be hosted somewhere.  But without the information, it doesn’t much matter how fast our networks are or where that hosting is done.  The corollary to that truth is that providing “better” network or hosting capability doesn’t save AR.  What we have there is the classic “ecosystem” problem.

Predators depend on prey animals, which depend largely on vegetation.  If you want a healthy ecosystem, you can’t populate a desert with sheep and hope that predators will come to thin the herd to a point that the vegetation can sustain, because you don’t have vegetation and you don’t have predators.  Somehow you need to get all the pieces into place before natural processes combine to create a balanced ecology.

If we apply this principle to the technology world in general, or the AR world in particular, we’d say that an application (like AR) will emerge by first harnessing the elements of the current ecosystem it needs to create the new one.  The market opportunity will then build more of those elements, and begin transforming them to better suit the new missions of the new world.  AR, then, should be emerging through piggybacking on current capabilities.

What we call “the Internet” today is really the worldwide web, which is a hypertext application that emerged in 1989.  It was applied first on “the Internet”, a network largely focused on universities and government projects.  We had devices (routers) to move traffic for the Internet, and we now had a visual, generally interesting, way of presenting information through the Internet.  At this moment, operators were struggling with the question of how voice calls were going to fill the capacity that new fiber technology was going to create.  Consumer data?  Perfect answer.

What this picture shows about AR is that its growth depends on a combination of technology and opportunity.  What I think network operators are doing today is believing that the technology is the barrier, that opportunity will automatically create itself once the technical framework has been established.  I don’t believe that’s workable, and yet it’s exactly what operators have done for ages—the old “field-of-dreams-build-it-and-they-will-come” mindset.

That’s how we get into points in the article I cited, like “To get that type of VR-quality latency, operators will need to move the compute power closer to the network edge.”  We’re postulating the needs of an application, the technology best suited to deliver it, without the benefit of the application.  We had the Internet for decades before the web was invented, but without the web it’s very likely that we’d never have had “the Internet” is it is today.  Put another way, the best way to look at AR evolution and success is to look for the single basic technology strategy that would tie together all the resources we know we need.

I’ve proposed that one way of visualizing that basic technology is the notion of information fields.  In a virtual/augmented world, we move in parallel through the real world (defined by time and geography) and the information world (defined by knowledge).  Each element in the real world could be seen as emitting an information field, describing its goals, capabilities, properties…whatever.  A shop would emit information about what it sells, where it is, when it’s open, and also what it might be looking for.

So would each of us.  When we are shopping, our information field, advertising that fact, intersects with other fields representing the thing we’re shopping for.  The intersection can then trigger in us and in the shops, awareness of the mutual opportunity.  That awareness can be signaled to us, in this case via AR.  The process of recognizing mutual opportunity or relevance among information fields is what I’ve referred to as contextualization.  We live in a context, with a set of goals and priorities.  What AR could do is to present information from the virtual world into our real world, based on our context.  Contextualization and information fields form the AR equivalent of the worldwide web, HTTP and HTML.

Except, of course, we don’t have any firm and generally accepted vision of how information fields would be represented and how contextualization would be applied.  I’ve suggested in prior blogs that every real-world element would be represented in the virtual world by an agent process.  It’s that process that would do the heavy lifting, the assimilation of information fields and the contextualization.  That process would then provide the “augmentation” to the reality that we saw in our (hopefully more compact and attractive) AR glasses.

It’s not likely that the implementation of this concept would be in the form of “fields” in a literal sense.  Think of it as a big database.  Say that one index was location, and that for each location the database could return the “fields” that “permeated” (in a virtual sense) that location.  As we moved through the world, our own interest “fields” would be matched to the fields associated with the locations we passed through.

The same approach could be taken with something other than user location as the “key factor”.  Any interest or offering could be used to link a user/worker to an “offer” or capability.  If the user happens to be within view of the place the offer could be realized, it could be highlighted in the user’s field of view.  If not, an arrow could be presented to lead the user to the location.

There are probably a lot of other ways to do this, just as there would be a lot of ways to have created something like the worldwide web.  It’s hard to say now whether any of the other web options would have been better, but it’s easy to see that if no option at all had been selected, we’d be in a very different place today.

The web, in a timing sense, was an accident.  It might be that AR will likewise be an accidental combination of capabilities and interests, but we have an advantage in that we can visualize the goal we’re seeking, and we can therefore visualize both abstract (the “information fields”) and concrete (the agent processes and the database) mechanisms for getting to the goal.  The challenge is putting the pieces together.  A couple decades ago we might have seen something like this act as a catalyst for venture capital investment, but today’s VCs aren’t interested in complexity.

That doesn’t mean a startup or open-source project couldn’t do this, and that’s what I think is going to happen.  I don’t think that AT&T or Verizon, or edge computing or 5G, are going to catapult us into the AR future.  They’re just going to get dragged along for the ride.

When the real broadband wars started in the last decade, cable companies had a major advantage over the telcos.  Cable infrastructure is based on CATV cable, which has a potential capacity of over 10 Gbps over a significant distance, while operators were stuck with twisted-pair DSL model that was taxed to deliver 25 Mbps over a mile or so.  Further, CableLabs has been advancing cable broadband potential through successive upgrades to DOCSIS (Data Over Cable Service Interface Specification) to enhance its support for broadband Internet connection.  Clear winner: Cable.

Then 5G millimeter wave came along.  5G/FTTN can deliver almost-gigabit speeds out to somewhere between a thousand and three thousand feet, depending on the node location/elevation and the nature of the topography and construction in the area.  As an alternative to a passive-optical fiber deployment whose current pass costs are probably averaging $700, the 5G/FTTN combination could cut costs to a quarter of that.

The question for cable today is what to do about the 5G/FTTN hybrid.  The faster broadband later versions of DOCSIS (like 3.1) offer has encouraged cable operators to deploy more fiber, creating more fiber-fed CATV head-end points.  Obviously these could be equipped with 5G millimeter wave and turned into the same sort of last-mile delivery mechanism that the telcos are exploring.  However, 5G/FTTN isn’t a slam dunk for cable operators.

The biggest problem is the in-ground CATV plant.  It’s likely that 5G/FTTN would offer cable companies better profits and offer customers better service, but the cost of a changeover would be considerable, and 5G/FTTN isn’t able to carry linear TV, which then pushes the cable companies to streaming.  Many of the telcos have accepted this because DSL doesn’t really offer anything but some form of streaming video and fiber can’t be provided to everyone, but cable companies have ridden on the benefits of CATV up to now.  Would they be willing to bite all these bullets to move to 5G/FTTN?

There would be a lot of “CLEC-like” companies interested in getting into the broadband business by exploiting old CATV cables, just as for a time there was interest in wholesaling twisted-pair copper from telcos (and still is, in some areas).  A decision by the cablecos to walk away from their CATV plant might well create a CATV-rush and a bunch of new competitors.

Another problem cable faces with the plant is that in many areas of the US, cable companies entered into sweetheart deals with developers or municipalities to provide some form of payment or benefit in return for exclusive access to rights of way for customers.  There’s at least one subdivision in my own community where a single cable company is the only broadband option for residents because of this.  But 5G/FTTN flies over municipal and subdivision boundaries and bypasses right-of-way deals.  If cable companies were to adopt it themselves, might that encourage telcos do accelerate their own plans, and thus hasten the loss of these hamstrung customers?

The telcos might not need much encouragement, though.  If FTTH is too expensive for most markets, and DSL is too slow to be competitive with cable’s CATV, what are the telcos to do?  Particularly when declining profit per bit makes increasing pass cost significantly a losing proposition.  And, of course, if the telcos make the move first, a lot of the 5G/FTTN issues fall away and it becomes a straight-up competitive question.

It’s also true that cable companies don’t surrender all their CATV advantages if they move to the 5G hybrid model instead.  Cable has been building out fiber, as noted above, in order to reduce data congestion on CATV cable by reducing the number of subscribers per head-end connection.  In many cases, that puts cable companies’ nodes in 5G millimeter wave range of customers, and in some areas they’re closer to the customer than telco DSL head-end nodes.

There are other cable liabilities to balance this asset.  The internal rate of return expectations for telcos is lower than for cablecos, which means that telcos could tolerate the investment in nodal 5G more easily.  In addition, telcos have only a small footprint in linear TV delivery, and thus could look at video revenue from streaming TV as an increased return on their 5G/FTTN investment.  Cable companies already get linear TV revenue.

For both telcos and cable companies, the streaming-video thing may be a big question-mark.  Yes, there is more revenue in offering streaming TV than in offering no TV.  Particularly given the fact that there are plenty of streaming options available to consumers already, and possibly even more on the way.  That means broadband customers might well elect streaming service from a third party, leaving both telco and cable companies to carry the traffic without any incremental revenue.

Cable companies are seeing growth in broadband-only customers, and a general loss of customers and premium-service revenues in linear TV.  These customers aren’t swearing off TV, they’re swearing off traditional TV models, meaning linear, live, TV.  Some are moving to streaming live TV, but some are just saying goodbye to the whole live network TV thing, or are moving to use antennas for network reception.  The whole of the TV landscape is changing.

Which might be the critical point for the cable companies.  Telcos never got the majority of their revenue per user from TV, so while a shift in viewer habits may threaten some future plans and hopes, it doesn’t (for most) mean an immediate loss.  Some operators (Verizon) too offer traditional TV and some (AT&T) have satellite TV, but there are many, many, telcos who never got into the TV business.  There are no cable companies who didn’t start with TV, and if TV is changing completely, cable companies have to expect that their business models and technology will have to change too.

Verizon in the US already hammers cable companies on the “same-upload-as-download-speeds” issue.  5G/FTTN offers symmetrical capacity just like PON FTTH, and many cable companies admit that their outside plant is rather disorderly to boot.  At some point, might they be forced to modernize the plant?  Might they have to move away from a shared-cable CATV model for competitive reasons?

“Yes” to all of the above, but perhaps not immediately.  Even cable companies are starting to worry about profit per bit or average revenue per user (ARPU).  I don’t think they’ll move quickly off their CATV plant, which thanks to DOCSIS upgrades still has decent legs.  Before they do that, I think we could expect them to try out 5G/FTTN in new subdivisions, but even before that they’ll have to coalesce on a streaming strategy.  Some (like Comcast) already have one, and so it may be that Comcast is the player to watch when handicapping the 5G/FTTN move.

For both cable and telcos, the big question is how to achieve reasonable profit per bit while providing a competitive level of broadband service.  Telcos know that their legacy infrastructure cannot deliver that formula, and cablecos?  Comcast will tell the tale.

Talking with operators about OSS/BSS is interesting, and I’ve blogged about operator views on the topic before.  The discussions, combined with my own long exposure to the topic, have also given me my own perspective, enriched by recent deep-dive discussions.  This is my view of where we are in OSS/BSS modernization, and what might make things better.

You have to start any OSS/BSS discussion with a bit of history, because that’s what’s guided the evolution.  In the very early days, the ‘70s and early ‘80s, operations systems were primarily mechanisms for managing what operators called “craft” activity, the manual steps associated with service setup and changes.  These were the days when operators sold constant-bit-rate or “time-division multiplexed” (TDM) trunks, stuff like 56 kbps Dataphone Digital Service (DDS), 1.544 Mbps “T1”, or 45 Mbps T3.

When packet services emerged, starting with frame relay and (a little bit of) ATM, then moving to IP, it had the effect of shifting services from per-customer bandwidth provisioning to multiplexed shared-network provisioning.  You still had to provision access connections (as you do today), but the real service was created from the management of shared infrastructure.  In nearly all cases, this infrastructure was capacity-planned to support service goals overall, and perhaps some admission control was added to keep customers within the design parameters of the network.

Politics entered the picture here.  The original operations systems were essentially “clerical” applications, and services were now direct offshoots of network behavior.  The clerical side of things was managed by the “CIO”, who ran business-supporting applications in operator verticals just as the CIO did in other verticals.  The network side of things was managed by network operations, with technology enhancements managed by the Chief Technology Officer (CTO) and staff.  The result of this was a kind of separation between operations and network, and the OSS/BSS tended to be directed more at “services” than at “networks”.

It seems to me that this separation is fundamental to the issues of service lifecycle automation today.  A “service” has a service-level agreement (SLA), and it draws on the network to meet the SLA, but it almost never directly controls the network.  Furthermore, the network almost never relies on service faults as signals for remediation; it has its own network operations processes that are triggered by faults, either failures or congestion/performance issues.

What this has done, without much fanfare, is separate “lifecycle automation” into two areas, one focusing on the service relationship with the customer and one on the network’s operations.  That has some profound implications.

The most obvious problem this separation creates is that a single strategy for lifecycle automation is going to run up against the barrier between service and network.  An OSS/BSS lifecycle automation approach is going to be limited in its ability to manage network problems, because network problems are in the network operations domain, a separate organization and a separate set of tools.  Network operations automation is likewise going to be limited in its ability to integrate service-related issues, including fundamental things like SLA violations.

There are two possible paths that might be followed.  First, you could declare one of the systems the “master” and mandate that it manage all service and network lifecycle issues.  Second, you could create a boundary function between the service and network areas, and have both sides build to meet in the middle.  Both of these approaches would require some high-level mandate to the CIO and network operations people to play nice, and while there were in fact a number of CEO-staff-level teams formed about ten years ago to do this, as a part of transformation, the initiatives have almost universally failed to drive cross-organizational consensus and cooperation.

The most promising approach seems to be the second, the “meet in the middle” model, but even that approach has variations.  One is to presume that the two sides will remain totally independent, creating what are in technical terms two finite-state machines linked by an agreed set of state/event assumptions.  The other is to presume a single “machine” that defines all service and network events and states, and invokes network and service processes as needed.

The “two-different-worlds-colliding” approach is the most politically attractive, and also the one that best fits if you presume that vendors’ offerings will have to be the driver behind any implementation of lifecycle automation.  A service automation model and a network automation model can run asynchronously, communicating an event from one model to the other if something happens that crosses the wall between service and network.  A service change is an example of a service-to-network event, and a fault that could not be remediated by the network’s own operations processes is an example of a network-to-service event.

The notion of an “intent model” is a useful one in this situation, because an intent model exposes properties and not implementations, and thus is abstract enough to represent the service/network boundary.  The only issues are having a two-directional event flow, and agreeing on the properties getting exposed and the events getting generated.  Most intent-model interfaces don’t exchange events, but rather expose a simple API or API set.

I always liked the common model approach, but recognizing the need for a boundary point between services and networks, I divided things (in my ExperiaSphere model) into a service and resource model domain pair.  Network “behaviors” were composed into services, and the network was responsible for behavior SLAs, while the service layer handled customer SLAs.  If the network couldn’t deliver on the behaviors’ SLAs, a reported fault would give the service layer a chance to either accept the fault (and perhaps issue a credit to the customer) or attempt to recompose the service using behaviors that still offered a suitable (or better-than-the-failure-mode) SLA.

This could be done with two separate models, of course.  However it’s done, I think it’s the logical way to bridge the service/network gap.  That means it would be a great place for operators to put their efforts into the game.  It would also be a good place for the IT and cloud vendors who want to take control of next-gen operator infrastructure to spend some effort, and money.

Any lifecycle automation approach that’s comprehensive, and that unites service and network domains, would be better than what we have now.  I think we could rely on vendors to address the scope of lifecycle automation within the service and network domains, as long as they were separated.  What’s more difficult is the uniting piece.

The task of integrating operations elements, within the service or network zones or across the boundary, has been largely focused on APIs.  That’s a problem because the truth is that most API work has ended up encouraging a tight coupling between the two elements—what programmers call a synchronous relationship.  In cloud-native behavior, synchronicity is a no-no because it ties up processing resources waiting for things to happen.  Event-triggered approaches are asynchronous by nature.  What we need to see now is an event-centric vision of operations processes.  I’d like to see that overall, but for many vendors it may be too much of a transformation to complete quickly.  I’d settle for seeing the service/resource linkage done via events, and seeing operators put pressure on vendors to define the boundary relationship that way.

Do we need another online tech news site?  That’s an interesting question given the fact that the founder of Politico is about to announce another venture, Protocol, which is just that.  The press release says that “Great media companies are sharply focused on communities and the ideas that bind them. POLITICO successfully captured the influential government and political communities. With Protocol, we aim to do the same with the world of technology.”  Great goal, but is it possible, or are the skeptics who say that tech media is already a crowded space right?

We have dozens of tech publications today.  Most of us probably use a half-dozen regularly and another dozen occasionally, often through news aggregators or references.  That certainly fits the description of a “crowded space”, and so I think it would be fair to say that Protocol is doomed to failure if it turns out to be just another one of the typical online tech (virtual, of course) rags.

Politico, which I happen to read daily, was one of dozens of political publications when it launched.  That proves that it’s not impossible to come late, as long as you do something that readers in your space aren’t getting enough of in those other, earlier, sources.  What “somethings” might qualify in tech, might make Protocol viable?  That has to start with what’s wrong in tech today, and for that, I have a combination of survey data and pretty significant and long-standing personal experience.

I wrote my first piece in a tech publication in 1982, on the then-dazzlingly-new topic of satellite communications.  I’d given a talk on the topic at a trade show, and in the audience was an editor from the publication, who stopped me and asked me if I’d do an article.  I did.

Almost as soon as the piece ran, I started to get calls from reporters and editors of other publications.  Interestingly, few of them wanted something on satellite communications, but they apparently reasoned that if I knew that, I might know something else too.  I got a lot of ink, and a lot of cynicism, from the experience, and it led to one of my pithy sayings, “An expert is someone who knows an editor.”

This is the start of the problem with tech media, which is that it’s a journalistic take on a non-journalistic topic.  News, overall, is drawn from the collective experiences of our lives, which means not only that we can usually relate to it without major challenges of education, but also that those who write about it aren’t expected to have PhD’s in some arcane field.  Tech isn’t like that.

Think, for a moment, about what would be involved in doing a hypothetical “Heisenberg” publication, an online site dedicated to news on quantum theory.  We have two choices; we do quantum-for-dummies, in which case none of the people who really need or care about quantum theory developments will read it.  Or we do quantum-for-the-quantized, in which case the number of people who can read it, or more important, can produce it, will be vanishingly small.

We used to do the latter in tech.  In the early ‘80s, at the time I did my first article, my surveys of IT and network buyers said that there were about fourteen thousand organized points of purchase in the networking space.  The number of subscribers to the best of the network technology rags ran about the same.  By 1989, we’d increased the number of organized points of purchase to just about sixteen thousand, but ad sponsored reader-service-driven processes had increased the subscribers to network rags by an order of magnitude.  Who were all these other people?  Network dilettantes, relative amateurs.  As a result, we dumbed down network and tech coverage.

The result of this was a significant drop in the influence tech media has on buyers.  Back in 1983, it was the second-most-powerful strategic influence on technology buyers, after experiences of a trusted peer.  By 1989 it had fallen to fifth, and in my 2017 survey it ranked seventh.  The problem is that these are news sites, news targeted to the “average” reader, who isn’t one of those critical decision-makers at all.

News coverage, meaning sites focused on specific news, have an inherent problem of shallowness.  Press releases are always shallow.  When something new is dug up, there’s almost always a race to “scoop” rivals, which doesn’t contribute to careful analysis.  However, news coverage is essential because it’s what keeps people looking at the site regularly, and because carefully analyzed news is a potential hook to deeper analysis.  The challenge is having that analysis to link to, and that means putting news in a context that supports its linkage with other stories.

That’s what Protocol has to deal with.  Most of all, tech news today lacks context.  It’s not fed by relevant developments, it’s manipulated by vendors.  To be useful to buyers, tech stories would have to be collected around a series of actionable trends, related to each other and to the buying decision that was actually on the table.  In networking, in the cloud, we’re not going to get to the next level by taking random dance steps in the dark.  We need to know where we’re going.

It’s pretty obvious what general political news is important, and for any given country, the political context isn’t something that takes a rocket scientist to figure out.  Look at the US, the UK, the EU, China, or Japan today and you can see what I mean.  In tech, though, national boundaries don’t matter as much as technology boundaries.  We have chips, servers, software, networks.  In each of those we have a context, but how many people could say what the world view of any of those areas would look like?  Without a world view, how could a relevant context be established to guide editors/reporters to the topics that are really important?

Context is a first step, but guidance is the second.  “I don’t want decision support, I want to be told what to do!” is my favorite client quote.  We need to fill a need, and the primary need is for actionable insight.  That means something more than a 500-word glitter-and-buzzword piece on an architectural innovation that might have required a million hours of labor to generate, and will require thousands of hours of tech labor to adopt.  Every story can’t create insight, but every story that’s contextualized can draw a roadmap to insightful follow-up.

Politico has both “news” and a “magazine” section that delivers stories in considerable depth.  That’s the solution to the actionable insight part, providing that the stories in Protocol are written by somebody who actually has some insights to share.  With a space as broad as tech, and one that’s already bewilderingly complex and getting more so literally by the day, that’s not going to be easy, but it’s possible.

The tech industry has been hurt—financially, educationally, culturally—by the lack of tools to give buyers the information they need to make confident decisions and then implement them.  Those tools aren’t just notifications of announcements or happenings.  Protocol could take political-news know-how and try to butt its way into the crowded space.  If they succeed, they might gain something, but the market would gain nothing.  Or they could do this right, in which case they’d not only become a beacon in the space, they might build a mighty tech market.  I say, “Good luck to you!”

Operators have told me a lot about cloud-native, probably because I’ve blogged a lot on the topic and written about it for other software-centric online publications.  Since cloud-native is the number one priority emerging from operators’ fall planning cycles, I think it’s interesting to look at some of the questions I had for operators, and the questions they’ve asked me.

The question I usually asked to open a discussion is Why do you think cloud-native is so hard for operators?  One thing I observed in comparing the way operators are reacting to cloud-native with the way enterprises are reacting is that operators are a lot more pessimistic about their pace of progress and the ultimate outcome of their efforts.  Why?  The answer is interesting because operators divide themselves into two camps on the point.

The majority of operators say that enterprises have engaged with the cloud longer, and engage more deeply, than operators.  One operator told me that one of their largest enterprise customers, whose business was about half that of the operator in revenue terms, had two-and-a-half times as many cloud-qualified development and operations specialists on staff.  That enterprise had relationships with two of the major public cloud providers and was actively deploying hybrid-cloud applications, more every month.  The operator said that they had nothing going on in the cloud at all except some CTO-level experiments, and they see the problem as a simple lack of cloud knowledge in house.

The operator who talked about the imbalance in cloud expertise versus the enterprise also pointed out that lack of cloud skills made it difficult even to hire and manage a team of cloud specialists. “If you make pancake mix and you hire NASA engineers, how long before you land on the moon?”  Obviously a long time.  This is probably the root of what many have said is a “culture problem” for operators.  It’s less culture than a systemic knowledge of cloud projects that can be exploited to plan and promote cloud-native.

A minority of operators report almost exactly the opposite balance of cloud expertise, but end up in much the same place.  An operator in this group said they have almost twice the number of cloud specialists as their big enterprise customers, and they have a significant commitment to partnerships with cloud providers and to the use of the cloud for both their own internal business services and as elements of their connection services.  But their cloud expertise isn’t helping them as much as they’d hoped.

The problem this group cites has two faces.  First, a lot of their cloud skills reside in the CTO group, whose mission for the cloud is fairly consistent with traditional business applications.  The problem is that for operators, the OSS/BSS systems that make up “traditional business applications” aren’t really a broad industry target of cloudification.  There’s no widespread project model for these people to follow.  The second face is that the main focus of operator transformation is network infrastructure, and they find no broad-market public cloud guidance on even the architecture of a cloud-native approach to network infrastructure.

The question most operators ask me is Do you think that SDN and NFV will be successful in creating a transformation model for network infrastructure?  My answer, of course, is “No”, with the qualifier that it’s likely that the intent of both SDN and NFV will be incorporated in the ultimate architectural model for cloud-native network infrastructure.

I think this question demonstrates the impact of the situation I just described.  Operators don’t think that public-cloud or enterprise initiatives in cloud-native are addressing their transformation needs, and they’re admitting that their own projects and standards efforts are producing nothing more than questionable results.  If operators do have skills deficits in cloud-native (which they admit), then how do they think they can run standards or even open-source projects to exploit it?

This is why I think that the only strategy with a chance of addressing cloud-native transformation in any reasonable timeframe will have to come from vendors.  I don’t necessarily mean that network vendors will lead the efforts, but that software/cloud vendors are already seeing the dollar signs that would be associated with major transformation initiatives, and they’re starting to assemble the pieces.  I think that VMware’s latest Project Maestro stuff could be critical—if it means what it could mean.  I asked VMware to comment on my blog on Maestro to check my interpretation, and sadly they did not.  Does that mean I’m too optimistic, and they don’t want to admit that?  Could be.

The next question I had for operators was How does 5G transform your vision of the network of the future, and your own profit picture?  Here, operators fell into three different categories.  One could be called the Optimists, the second the Realists, and the last the Pessimists.

The Optimists, about 40% of all operators I talk with, say that the new services of 5G will raise their profits “significantly” (but they wouldn’t quantify what that meant).  They also think that 5G will pull through NFV, and that 5G mobile infrastructure will combine with 5G/FTTN hybrids to build a new model of network that will be cheaper to build (capex) and operate (opex).  The big driver of all of this is IoT, which will generate “millions of new cellular customers” that operators will be able to charge for service.

The Pessimists, who number only 25% of operators, believe that in the end, 5G is going to be nothing more than a RAN upgrade, and that if anything the marketing of 5G that stresses higher speeds will end up encouraging demand for more bandwidth, but not with any increase in service price.  Thus, revenues with 5G will not go up, costs will go up, and if anything, the profit-per-bit will be worse.  This group doesn’t believe that there will be a significant uptick in 5G IoT service points.

Which leaves the Realists, about a third of operators.  This group believes that 5G NSA (the RAN upgrade) and FTTN hybrids (millimeter wave fixed wireless) will deploy “by 2022”.  They do see an opportunity for 5G core deployment “a couple years later”, but they’re not really sure what will drive it, and whether 5G Core would really add to revenues.  They do think that there’s a capex/opex benefit to a unified infrastructure, and they do think that, overall, 5G will improve their profit per bit “somewhat”.  Not enough to mean no further transformation is required, though.

Their next question operators asked me was When do you think that vendors will adopt an open-network model.  This was an important question, because behind it is the thought that the network of the future will be largely the network of the present, but with cheaper open-model devices replacing expensive proprietary (vendor) technology.  My answer?  “For network vendors, never.  For IT vendors, probably by 2021.”

Flash: Most operators see an open-model network and cloud-native infrastructure as different things.  Most, now, seem to favor the open-model approach.  The obvious question that raises is…

…my next question to them:  Why do you seem to like open-model networking more than cloud-native infrastructure?  A small number (less than 10%) of operators said that wasn’t the case; they were happy with both models.  Interestingly, none said they liked cloud-native more.  The only question for most was whether they had any favorite (a third) or favored cloud-native as I’d suggested (well over half).

There weren’t a lot of specific details offered as an answer to my question, which means it’s hard to provide a clean set of classes of response.  The sense of the majority of answers was “because we know how to do it.”  Operators were comfortable with the process of network-building and their current network management techniques, both of which depend on having boxes in specific places, managed with familiar interfaces and tools.  The next-most-common response was that cloud-native and open-model networking really differed only based on whether you hosted software networking features on servers or on white boxes.

To me, these add up to a common view, which is that a “network” is a mesh of service feature instances, and that all the fuss is really about how the instances are created.  As I’ve commented in the past, cloud-native network infrastructure would have to decompose the features of the traditional devices, not just host them.  You’d need virtual services not virtual devices, and operators either don’t see that or don’t accept it.  I think the latter.

You can’t build carrier cloud from white boxes.  If operators are reluctant or unwilling to adopt cloud-native virtual network infrastructure, then that potential early driver of carrier cloud is off the table.  That might well mean that cloud-native infrastructure planning will be delayed until some credible mission driver emerges.  If that’s 5G IoT, we shouldn’t expect it to emerge soon, unless vendors can somehow move the ball here.

There are other drivers, of course, but they depend on operators raising their sights for future services above the network layer.  Can they do that?  Nearly 80% of operators say they can…eventually.  We’ll see.  It would have been great if we could have had a cloud-native network-layer approach to move things further, and faster, but operators don’t see that happening now, and I have to agree.  Vendors?  It’s up to you.

No business has ever been saved by an acronym.  No enduring market has ever been built on an acronym alone.  That’s all true, but you’d never know it by looking around in the networking industry.  We were “saved” by SDN, and then by NFV, and maybe by ZTA, and now we’re being pulled out of the fire by AI.  I had an interesting exchange with a trio of operators in the last two weeks, and I think it offered a sense of what’s going on, and maybe even of what needs to be.

According to these operators (and quoting one), “there’s a powerful sense of being overwhelmed” impacting planners in all the major telco divisions (CFO, CIO, the operations unit, and the CTO).  All three said their own “transformation” initiatives had been underway for nearly a decade, and all three said that they had enjoyed only “local” successes with it.  “We’ve not transformed, not really,” said one, “what we’ve done is adapted.”

Back in 2015, I did a broad survey of operators’ views on the future.  It covered 77 operators globally, and it showed that over 85% of them felt that their businesses would have to be “fundamentally changed at all levels” within a decade.  They thought that over half their current network technologies would be replaced in that timeframe, that their operations practices would be “totally transformed”, and that the services they were selling in 2015 would represent just a bit more than half their revenue in 2025.  The three operators I talked with were part of that survey; what do they now think?

“Did we say that?” one asked.  “I guess we missed the goal we’d set.”  All three of these operators said that the biggest technical reason why they fell short was that NFV didn’t meet their expectations.  It wasn’t just that they depended a lot on the realization of NFV’s goals, either.  The problem with NFV shook their faith in their old-model, standards-driven, technology and service evolution approaches.

Why do operators think that there was an NFV problem to begin with?  These three cited three separate but symbiotic reasons.  First and foremost, the Internet changed the timing of the communications services market forever.  “What we called ‘services’ used to be tied to specific network infrastructure changes,” one explained.  “The Internet was a kind of universal communications infrastructure and services were consumers of it, not part of it.”  They agree that their early planning for transformation presumed that, as always, they would figure out what to build and offer it.  The notion that services would come first never occurred to them.

The second problem was the way the Internet age collided with the operator’s technology planning processes.  Remember that they were used to the idea that services were a product of infrastructure change, and infrastructure change that preserved competition among vendors meant standards.  Standards processes have been a fixture of CTO organizations for decades, and nobody expects them to move quickly.  After all, services come out of infrastructure, so there’s no hurry.  But in the Internet age, services evolve on their own, and infrastructure standards delays delay the benefits of operator transformation.  That’s what happened.

The final problem was the hype-wave problems in the networking industry, those darn acronyms.  As soon as an idea gets media traction, every vendor and every publication jumps on it.  Nothing much gets written that’s a useful guide for buyers, but every operator said that their senior management was infected with acronym-itis, and that forced them to launch projects around the acronyms.  Since there was little substance to the drives, none of these projects really accomplished what operators had hoped for.

Ok, that was then and this is now.  What do these three operators think will happen?  Up to now, they’ve been almost totally united in their perspectives.  Not with this question.

One of the three operators believes that there will be no transformation in a true sense.  Instead, they see the pressure on profits creating open-model networking and reduced willingness to invest in infrastructure.  They see their company staying a connection-services provider, having no stake in things like IoT other than any additional connectivity revenue it might create.  In operations, they see new but still “local” mechanisms to reduce head count, mostly centering on self-service portals.  No real zero-touch lifecycle automation.

The second operator thinks that her organization will slowly transform, with some carrier cloud services but without any real common carrier-cloud infrastructure policies.  The result of this will be that they’ll get some new revenues, some new operations economies from lifecycle automation, but nothing so radical that an old-like operations type wouldn’t recognize “the network” of their future.

The third operator doesn’t think that either of those approaches would be survivable.  “We’d end up needing government subsidies,” he says.  This operator believes that cloud partnerships, open-model networking, and software-automation in lifecycle management will come along out of necessity.  Not in 2020 or even 2021, but in 2022.

The views of these operators on 5G parallel their world view overall.  One says that they’ll probably never really get to the 5G Core model, that most of their investment overall (and all of it in the near term) will be focused on the RAN and fixed wireless.  The second thinks they’ll have some 5G core deployment by 2021, but that it won’t really add service revenues or change operations practices.  The third still believes they’ll adopt 5G fully, and that it will in fact offer them some new service revenues and some opportunity for operations automation.  The three views on transformation and the three on 5G align in the same order I presented them.

What do I think, based on my own experience and on the views of other operators?  I think the second operator is right, and if I were an equipment vendor, I’d be worried no matter which one sees the future of operators overall.

The big news here in my view is that none of the operators see business going on as it has been.  None of them believe they can sustain infrastructure investment under their growing profit pressure.  They see everything, even 5G, more as an opportunity to rebuild their access networks around a common radio-network technology, one that because it doesn’t depend on per-customer wiring is less capital- and operations-intensive.

Where does our latest acronym, “AI” fit into all of this?  All three operators made a common point, which is that you can have transformation only by transforming infrastructure.  The idea that business practices somehow get AI’ed and that saves the old network model is ridiculous.  These operators all see AI as an example of a “local” strategy, a way to make some specific and limited operations/administrative process more efficient.  Is it helpful?  Yes.  Will it save the operators’ legacy model of networks and business?  No chance.

I agree with them.  In fact, of all the acronyms we’ve looked to for network operator transformation and salvation, AI has the least potential.  It’s either a small part of a major shift, from “network infrastructure” to “carrier cloud infrastructure” or it’s a local adaptation.  In the latter case, it can’t do what’s needed overall, and in the former, the “overall” that’s needed is something most operators don’t think they can achieve quickly.

And that “quickly” is an important qualifier.  If the most optimistic operators are right and they achieve some real infrastructure transformation by 2022, that’s bumping up against an important limit.  Operators don’t think they can go much beyond 2021 without a major shift to open-model networking.  Once that move gets started, as I’ve said before, it will be very difficult to stop it.

The relationship between operators and services, operators and OTTs, is unstable and perhaps even parasitic.  Some have argued that net neutrality rules have perpetuated it, but where such rules have been weakened, there’s been no corresponding improvement in operators’ infrastructure ROI.  Some argue that’s because the removal of rules alone doesn’t create a shift in business policies.  Would paid prioritization, settlement between OTTs and operators, help?  Surely, but we’ve not yet explored the cost of these policy changes.  We’d buoy operators’ profits at the expense of OTT profits.  It may be too late to take the market risk of such a policy change.

Having nationalized or subsidized operators is another popular answer, but it’s not worked out where it’s been tried at scale (Australia comes to mind).  Might it be more realistic to restore protected public utility status?  No, because the challenge to operator profits doesn’t come from direct competitors as much as from arbitrage players, the OTTs.

OTTs aren’t exactly in rosy shape either, it’s just that they’re not facing immediate peril.  Ad-sponsored businesses are limited by how much ad spending there is.  A good example is that network TV is producing most of the online content, and it’s competing for ad dollars with the OTTs that are making money delivering the content.  If the latter impoverishes the former, what’s left but ‘50s reruns?

We might have had a regulatory-driven solution to the dilemma a decade ago.  It’s too late now.  Therefore, we need to look at the business model for both operators and OTTs, and figure out how to build a symbiotic relationship.

If networking turns to an open model, with open-source software and white-box hardware, can today’s network vendors survive?  Sure, but not in the manner to which they’ve become accustomed.  If you’re a big predator in a shrinking habitat, you can shrink to match the food supply (evolutionarily speaking, of course), you can learn to eat something different, or you can move to a new habitat.  That’s the choice that’s facing most network vendors today.

Let’s start off by explaining my “most” qualifier.  I think that open-model networking, when applied to a static requirements set, will eventually absorb the greater part of every piece of the carrier network of today.  Some parts, like optical, will resist for a longer time, but eventually, static requirements breed total commoditization.  Nothing promotes commoditization more than a market that lacks differentiating features, and nothing promotes feature requirement stagnation like a static set of requirements.  That’s the “eat something different” path above.

Vendors have tried for ages (well, at least for decades) to promote the idea that bits, which since they’re either “1” or “0” are rather hard to differentiate, can somehow be made into something more—like “elastic bits” or “on-demand bits” or “QoS bits”.  All these efforts have failed.  Price is always arbitraged against features on basic connection services, and if there’s a very low-cost best-efforts transport available (like the Internet) then applications will seek to leverage it.  Presenting higher-priced options simply won’t work well.

The notion of shrinking to match the food supply is what likely happens to vendors by default, meaning that if they join the other lemmings rushing to the sea, the same fate awaits all of them.  Ignoring the cliff ahead doesn’t create a soft landing, but some vendors might happen to land on a soft spot.  Transferring our lemming analogy to network vendors, some could survive by becoming the “Red Hat” of networking, focusing on telecomizing both open software and hardware and bundling it with support.  Is that a good choice for our network predators?

No.  If networks are built from hosted software instances on commodity hardware, the logical provider for the combination is a computer vendor, not a network vendor.  It’s not that network people couldn’t do it, but that the computer players have the advantage of the “new opportunity” benefit.  A computer vendor who makes an open-model network sale gains the profit of that sale.  A network vendor making the same sale loses the profit difference between the current high-margin proprietary gear and the lower margin of the open-model framework.  Thus, the computer players can move first and fast.  They’d win.

We’re left with finding new habitat, which means finding additional services beyond the current bit-centric connection services that operators could sell, and then providing operators what they need to get to those services.  Is this a good approach?  No, but it’s probably the best approach on the table.

A service “beyond bits” is in OSI model terms, a service above bits.  The lower three layers of the OSI model define connection services, and the upper four define services as presented to applications.  Transport-layer features handle things like flow control and end-to-end recovery.  Session services handle relationship flows, relating to multiple consumers of connectivity at the same network service access point.  Presentation services harmonize information coding and formats, and application services integrate non-connection elements like discovery.  Above all of this are the applications, the experiences.

Networks could in theory provide all seven of the OSI layers, by adding higher-layer features to the network service access points.  In practice, it’s difficult to make these layers’ services useful if they’re disconnected from the actual point of user/resource attachment, which is inside a data center, on a desktop, or in someone’s hand.  That leaves the applications above the network, the thing that delivers the “experiences”.

Some see this truth as the justification for edge computing, but before you run out and declare Gartner’s SASE model the future, consider that the edge is somewhere to host an experience, not the experience itself.  Absent an experience to host, an edge computing facility contributes to global warming and doesn’t do much else.  So, for now, forget the “where?” and focus on the “what?”

I’ve already blogged about the primary experience categories—personalized content, IoT, personalized or social communications…you get it.  The challenge with these experiences, from the perspective of our network operator, are many, but four stand out.

Number one is that operators like pushing bits.  It’s their culture.  The majority of operators evolved when connectivity was a mandate, so they never had to market anything.  They didn’t “sell”, they allowed people to buy.  Experiential services aren’t like that.  You need to promote them because the demand for them isn’t obvious/natural.  To make things worse, the current Internet model and the current profit-per-bit crisis of operators stems from the fact that over-the-top players have evolved to fulfill users’ experience needs.  Operators would have to play catch-up.

Our second challenge is related to the first.  Operators think “Field of Dreams”.  They’re used to deploying into a market tuned for consumption, and that biases their planning to be “supply-side”.  Don’t meet demand, it will meet you as long as you do a good (five-year-long) standards project.  That’s the 5G problem.  We talk about what people could do with 5G, but what we really need to be asking is what services are (1) available under 5G that are not supported under 4G, (2) who is going to build the non-connection parts of those services, (3) who’s going to market them, and finally (4) who’s going to buy them?  What operators need is a new service ecosystem, and they either have to resign themselves to being all the pieces of it or building partnerships to fill the voids they leave.

Challenge number three is first cost.  For almost a century, operators have planned infrastructure deployments based on a kind of “S-curve”.  When infrastructure deploys, the cost of deployment isn’t offset by service revenues because there are no customers for a service that was just announced.  For a period of time, cash flow dips below the zero line.  As adoption picks up, the revenues rise and cash flow rises too, going positive and eventually plateauing as the adoption saturates the total addressable market.  That period when cash flow is negative is called “first cost”.  If first cost is high, which would be the case if a large infrastructure investment was needed just to make the scope and performance of the service credible, then it’s a major burden to operators, one that will hit their bottom line and stock price.  It’s hard to see how you could ease into a new service in a world that the Internet has made fully connected.

The final challenge is architecture.  It’s hard to control first cost, but it’s impossible if you don’t have an architecture that can be scaled with marketing success, and that doesn’t require regular fork-lift upgrades to keep current in scope and features.  And it’s this challenge that vendors could help with.

The problem with architecture for experiential services is that it requires you balance two imponderables.  First, what are the services you’re targeting?  Second, what’s the infrastructure you run on?  Operators have generally grasped the second of these things, and standard/specification efforts like ETSI NFV have illustrated what happens if you accept the two requirements but attack only one, or attack them in the wrong order.  Your first mission is to fulfill the service opportunity; only then does it matter how you do it or what you do it on.

Network vendors and computer/cloud vendors both have a foot in the door here, in that they’re engaged with the current OTTs and thus know what they’re doing, and they’re also engaged with the telcos.  But even here, network vendors are at a bit of a disadvantage, given that their incumbency is in the bit-pushing area, and the opportunity is in what’s actually an application area, the IT domain.  Further, experience with OTTs should show network vendors that those companies have been champions of open-model networking.  Does that mean that having network operators push into experiential, OTT-like, services would promote operators to follow OTTs to the open model?

Still, the help-operators-get-more-experiential path is the best option open to network vendors, because it has at least a chance of working and nothing else does.  The fact that IT vendors are already there simply means that network vendors have to move much more aggressively.  They can’t play to come from behind, because if they get behind, they won’t have any play at all.

Who’s at the advantage here?  Many will say it’s players like Ericsson or Nokia, because of their 5G connection, but I don’t agree.  I think 5G is the boat anchor disguised as a life jacket.  It locks vendors in the vain hope of connection-service revenue gains.  I think that players like Cisco and Juniper have the edge.  Cisco has a computer asset base it’s mishandled from the first.  Juniper has a cloud software base (HTBASE and its Juke composable infrastructure model) that it’s likewise mishandled.  Will one of these players outfumble the other?

For both companies, success may equal failure.  Juniper already reported, and earnings were off for them in both products and services.  Could that motivate Juniper to “think outside the bit”, as my trademarked ExperiaSphere tag line suggests we must?  Cisco reports next week, and if they fall short and take a stock hit it could motivate them.

Cisco may have the better base with the harder climb to face.  They have more assets, but also more assets at risk if they try to shift to a less bit-centric positioning.  Juniper has a very critical asset in the area of infrastructure abstraction, and there are a lot of moves they could make (and haven’t) that could gain them traction above the connection services layers, without risking much in their traditional market.  Of course, they could both continue to do what they’ve been doing, which is “not enough.”

Making no choice is a choice, always.  In this case, it’s the choice of diminution, getting smaller to match the opportunity size.  That’s what’s going to happen to those network vendors who don’t see the light.

If NFV has a problem, then VMware thinks (or hopes) it has the solution.  The company just announced a technology preview called “Project Maestro”, aimed squarely at breaking an NFV logjam that’s caused in part by the problems with integration and onboarding.  This could be really big, or really dumb, and frankly I’m having some difficulty figuring out which outcome is most likely.

Network Functions Virtualization (NFV) has, from the start, presented telcos with two problems.  The first is that the architecture model for NFV is monolithic, an anachronism for a concept that’s supposed to leverage the cloud.  The second is that the elements of the architecture don’t hang together to support full service lifecycle automation.

Network vendors have largely blown kisses at the ETSI NFV ISG spec, and failed to make any progress in extending NFV concepts to create a practical and justifiable architecture model.  VMware, a cloud software giant, would certainly be in a position to do better, and in particular to take a shot at a true cloud model for NFV.

I could look at their architecture picture (shown HERE) and explain how their approach is just what the market needs, and that’s actually a good way to start.  The only problem is that I’m not sure that my explanation is really a description of VMware’s intent, or even capability.  Refer, please, to the figures titled “Project Maestro for telco cloud orchestration” and “Project Maestro – Solution Overview” to follow my discussion, and remember this is an interpretation of my own!  I’ve bolded my major assumptions.

There’s a video on the main Maestro page that’s worth watching, and its title frames the basic approach, which is Telco Cloud orchestration and not just NFV orchestration.  The goal, then, is to build services from the combination of NFV’s VNFs and other cloud components, giving operators an opportunity to expand NFV beyond the keystone application of displacing purpose-built appliances with software components.

VMware’s centerpiece is the Telco Cloud Orchestration element, shown in the first figure and dissected in the second.  This element is a kind of NFV platform as a service (NFVPaaS), a tool that provides interfaces to which various elements of NFV and VMware’s own cloud products.  A generic VNF Manager and Orchestrator are part of the Telco Cloud Orchestration element, so NFV-ISG VNFs and MANO/VNFM processes can be integrated into this component and orchestrated along with generic cloud components into services.

There’s more.  The entire Maestro ecosystem can be linked through standardized APIs to an external VNFM, element management system, OSS/BSS system, and automated lifecycle processes.  That means that service collections created by the Telco Cloud Orchestrator can be presented as VNFs or NFV-orchestrated services to these partner systems.  Vertically, it links through a multi-cloud, multi-NFV-VIM layer to any combination of clouds, data centers, and edge sites, and to both OpenStack and Kubernetes/container deployments.  That gives NFV a cloud-native, container-driven deployment option.

Assurance, monitoring, and management are applied to the full Telco Cloud Orchestration ecosystem, which means they’re available at the service level no matter how the service is composed and what its elements happen to be.  In effect, the model abstracts the entire telco cloud into something that can be presented as an element, a service, or a VNF orchestration, depending on what the operations people want.

This approach would be a true NFV revolution.  It would combine two critical capabilities—the ability to orchestrate NFV orchestrations and cloud elements into a common service set, and the ability to represent any orchestrated service complex as an NFV complex to an ETSI-standard NFV management framework.  It would give us, quite literally, the best of both worlds.  The problem is that while this explanation of what VMware is doing is consistent with the material they provide, the material isn’t enough to say with assurance that this description is accurate.

Going back to the video, it’s tantalizing in its suggestions of capability, and it’s a solid reason why I think my interpretation of what VMware is doing is correct, but it’s still mostly glittering generalities.  That’s also true of the rest of the material.  We don’t see specific interface points, we don’t see the relationships between NFV-defined components and generalized cloud components mapped out, and we don’t see how all of this maps back to the hypothetical NFVPaaS model.  That’s why I can’t say for sure that this is what VMware actually intends to do.

Which, of course, could also be different from what VMware ends up actually doing.  Some of my operator friends who’ve seen the VMware pitches say that they think the story is a dressed-up version of vanilla NFV, something that won’t really move the ball much.  Others’ take is more aligned with what I’ve presented here.  And if Maestro is an experiment, there’s always the chance it will turn in another direction, even if it’s intended to get telco cloud right.

Through the entire NFV process, the industry has made it almost-policy to listen to and then ignore all the signs that they were heading in the wrong direction.  Did that then immunize them to recognizing the right direction?  Does the NFV model, with all its significant limitations, still set the minds of the CTO people who dominate the early technology transitioning we’re now seeing?  If so, VMware would surely change focus to match what they hear.

Actual implementation is also another matter.  I’ve thought as much about orchestration of complex multi-technology elements of a service as anyone in the industry, I think.  There are a lot of wrong ways to do this, and a very small number of correct ones.  If VMware’s actual technology roadmap is based on the same level of detail as the online documents on Maestro, there’s still a chance that they’ll pick a wrong approach and end up with a reinvention of ONAP.

VMware calls this a “cloud-first” approach, and what I’ve described would be just that, a way of building carrier cloud so that it can envelope ETSI-modeled NFV, augment it, or replace it, as the intrinsic value of NFV justifies.  It would be a great advance, perhaps the most significant thing a vendor has done in the NFV space.  If it’s true.

Since I post all my blogs on LinkedIn, I hope that VMware will comment on this blog, provide any guidance on interpreting the material, and tell me if and where I’m off-base.  I didn’t ask for a briefing on Maestro because it’s my policy to judge vendor announcements based on hard copy only; it’s too easy to go off the rails when I’m interpreting some vendor interpretation of what they’re doing.

Better to have a solid foundation, I say, and that’s true in telco cloud and NFV too.  This just might be one…or maybe not.

Maybe we should say that everything old was renamed again, or perhaps that all the old names were given to new things.  Scott Raynovich’s piece in Fierce Telecom makes that point; SDN and NFV won’t die but just rise as different (perhaps totally different) concepts under the same name.  He also says SD-WAN is the sort-of-fusion of the concepts, reborn.  It makes sense, don’t you think?  You get something that garners great ink but (shall we say) falls short technically, and as the faults become clear and solutions are proposed, the old stuff rises from its ashes because the name is recognizable.  Or we rebuild a new concept from the old ones.

Well, maybe that’s a bit cynical in this particular case.  There’s no question that SDN was a launch point for almost everything that’s really new in networking.  It was the first technology that aimed at giving us services of old without infrastructure of old.  You could argue that stuff like P4, the flow programming language, evolved from the concept.  NFV was arguably the launch point for the notion that a network could be created by deploying feature instances on generalized hosting resources rather than by connecting purpose-built devices.  Combining the two gives us a model of virtual networking, something useful even if the details of SDN and NFV have proved lackluster.

What about SD-WAN?  The term, I think, was totally opportunistic.  As the market inevitably applied the SDN term to things further from the original SDN concept, it eventually swept into the WAN space, where it met overlays.  We’ve had overlay networks for literally decades, and the first real virtual network models from companies like Nicira were really not SDN as they claimed, but overlay networks.  SD-WAN implementations are, like Nicira, generally based on an overlay concept.  But there are a few (perhaps three) SD-WAN vendors who actually do virtual networking, who actually build network-as-a-service connectivity.

What’s behind all of this, the common thread?  Separation.  SDN was designed to separate services from traditional adaptive infrastructure used in IP networks.  NFV was designed to separate network features from purpose-built devices.  SD-WAN was designed to separate the service of connectivity from physical networks, from transport connectivity.  In a way, what we’re seeing is not a convergence on SD-WAN but a convergence of goals.  If you can define “separation” as a goal, of course.

Why would we want it?  The answer is that physical networks constrain us.  Boxes fail, or get overloaded, and so do trunks.  Addresses that are based on a global system aren’t always suitable for local needs, particularly when those addresses are linked to a specific physical place, a network service access point.  We, in the Internet age, are increasingly non-physical, virtual.  An application is wherever it runs, we’re whatever device we choose at the moment.  Relationships of two totally elastic things aren’t well served by fixed networks.

The question, perhaps the big question, is not whether separation is good, but whether we’re separated enough.  We still have IP addresses, and we’ll have them in future virtual networks that don’t have a shred of IP functionality as we’ve come to know it.  We’ll probably call feature instances that provide connectivity “routers” even if most of the code that’s currently found in routers isn’t inside those instances any longer.  Can we really be virtual with one of our feet still in the physical, the IP, world?

The big question for all of us in networking is whether “virtual networking” is an end, or maybe it’s just a step toward the ultimate goal, which we could call “logical networking”.  Think about it.  I’m connected to an IP network as I write this, and when I post it, I’ll be using the Internet, as will those of you who read it will do when you access it.  But do you know your IP address, or the IP address of my blog site?  It’s possible to find both, but I’m pretty confident that the great majority of Internet users would have no idea how to do that, or what those addresses even mean.  Fewer would know anything about the protocol we call “TCP/IP” or the header fields and message formats.

My point is that we’re really not consumers of IP by choice, we’re consumers of logical networking that we’ve mapped to IP because IP happens to have been in the right place at the right time.  When business networking got really hot in the early ‘90s, it had evolved for most enterprises on IBM’s System Network Architecture (SNA).  SNA had “nodes” that did “routing”, which they called “PU Type 4” nodes, big boxes as large as a rack of servers, costing a hundred grand or more.  A smug little Silicon Valley company named “Cisco”, who we all knew as a character in a TV western whose companion was named “Poncho”, offered these router things that cost a tenth as much and could move as much traffic.  The rest is history.

The Internet itself evolved from a combination of the invention of the notion of hypertext formatting, the TCP/IP protocol from the defense/university world, and the need of telcos to come up with some reasonable way for regular people to consume data services so they could use up the bandwidth that things like optical transport were creating.  But SNA and the Internet are just carriers for the logical networks that we really wanted.

You want to read an online resource like this blog.  You want display text, and you neither know nor care what kind of magic transports that text to you from wherever it happens to be hosted.  That’s the start of everything, and that’s the end-game for our separation, I think.  We’re going to eventually be not only transport independent, device agnostic, and open-modeled, we’re going to be oblivious to all of that stuff at the technical level, because we never cared about it at the point of use, and never will.

Transport resources and data formats are matters of negotiation, just like a group of multi-lingual people will find a common language for a discussion.  A connection is an information relationship that exchanges information in the format it needs to be in, over something we shouldn’t be caring much about.

A logical network isn’t about protocols, but rather about discovery and negotiations.  We find what we want, and we negotiate for it, not only for the rights to acquire it (pay TV) but also for the framework that will be used to deliver it.  Or, rather, our systems will negotiate that, because you’ll recall that we don’t care about the plumbing.

The real innovation of SD-WAN, in at least some of its implementations, is that it’s a step toward the logical and not the physical.  A user is not an IP address, they’re a person.  An application is an information resource.  The first step to a true future, the ultimate degree of separation or freedom in networking, is to stop talking about people and resources like they were network elements.  They are who we are, or what we want.  The rest is plumbing.

SDN didn’t make that connection.  NFV didn’t make that connection.  Not all of SD-WAN has made it either, but you can find some SD-WAN products that have taken that first critical step.  That, to me, means that SDN and NFV aren’t somehow fulfilled in SD-WAN, but that SD-WAN has finally relegated them to the place they belong—the dustbin.  They’re aspects of the mapping of logical to physical, accommodating what’s now available while we prepare for what will come.

It’s that future we need to be thinking about.  Virtual IP networking is still constrained.  Logical networking inevitably will shrug off constraints, and so it’s very important that we understand the difference between the real goals of connectivity and the artifacts of our implementations.  We’re starting to separate the two, starting to break out of the mold, but until we start with the goals and build in the direction of negotiating and accommodating, we don’t have a structure that can evolve because we don’t have one that fits the mission at the top, where we and our resources all connect.

Do you want your vendors to be visionaries, or plumbers?  See where they stand on these points and you’ll have your answer.