Month: November 2014

For months I’ve been following the evolution of HP’s NFV strategy.  I’m happy to say that on December 2^nd and 3^rd I’ll be attending the HP Discover 2014 event in Barcelona for an even deeper dive.  While there I’m part of a panel entitled “The New Business of the Network: Network Functions Virtualization” (9:30  AM to 10:30 AM on the NFV track).  HP luminaries Saar Gillai (SVP and COO of HP Cloud and GM of HP NFV) and Prodip Sen (CTO of the HP NFV business unit and former chairman of the ETSI NFV ISG).

During this panel we’re going to take a very objective and perhaps sometimes a bit controversial view of the NFV space, throwing in comments from the perspective of the standards people, a vendor, and an industry curmudgeon (me).  I’m particularly happy to be joining Saar and Prodip for this because Prodip has guided the ETSI NFV process through its critical formative period, and Saar is the only head of an NFV vendor program who is a cloud guy, not a network guy.  If you want a broad and realistic view of NFV, please join us for the session and ask questions during the public Q&A.

HP has a track on NFV at their event, and I’m planning on hitting the other sessions on it.  If you’re an operator interested in what NFV can do—and do today—I recommend you attend too.  The topics are all important—the priority in virtualizing functions, the collision of IT and networking and how that changes services and infrastructure, the union of SDN and NFV.  All of this discussion is happening in the context of the most credible NFV implementation available from a major vendor—network or IT.  I’ve blogged often on the quality of HP’s approach and I’m looking forward to learning more about it.

Which means I’m at this event to attend sessions and assess HP’s strategy.  I’d love to say “Hello!” to you as we move between sessions or to chat on a break, I’m not going to be setting up any appointments or meetings while I’m attending.

If we still had typewriters these days, I’d bet that the typewriter vendors would be claiming support for NFV because they put “N”, “F”, and “V” keys on their keyboards.  A few might even add an extra “V” key (we have “VNFs” in “NFV” implementations, and call what they do “advanced NFV support”.  It’s no surprise then that we’re hearing a lot about the role of analytics and big data in NFV.  But is any of the stuff true or relevant.  Some is, some isn’t, and so overall we need to look pretty hard at how analytics plays in NFV.

In networking, analytics or big data relate to the gathering of network information from all the possible status sources, and correlating it for review.  This is obviously two steps (gathering and correlating), and both require a bit of attention.

Gathering status information from a network means accessing the MIBs (in whatever format is required) and extracting the data.  With NFV, one of the possible complications here is that of visibility.  Is all of the management data created by NFV elements and resources visible in a common address space?  Resource information, being multi-tenant and owned by the operator, is likely not available in the service address space, and even if it were the information would likely be compartmentalized.  Service information, from either customer-dedicated “real” devices or per-customer VNFs, might be visible only as a MIB in the service address space, not accessible to a central collection process.

Even if we address the visibility issue we have the question of availability.  We don’t want analytics processes polling MIBs that are already being polled by management systems and perhaps by VNFs and users too.  The problem of exposing “infrastructure” and associated management data to applications and users was taken up by the IETF (Infrastructure to Application Exposure, i2aex) but it’s not advanced there.  We do have commercial and open-source tools (OpenNMS for example) that use the i2aex solution, a central repository where all management data is deposited and from which all application/user management access is derived via query.

It seems to me that this repository model is the right answer for a number of reasons.  If we stick with our gathering-phase comments for now, a repository controls the amount of polling of the real device MIBs, which allows designers to plan better for management traffic and per-element access loading.  The query mechanism means that in theory we could present MIB data in any address space and in any convenient form.

Assuming we have the data gathered and accessible, we have to correlate it to make it useful.  A central truth of management is that you have to make a high-level decision regarding what you are going to use as your service resource planning paradigm.  Here there are three options.  You can simply manage resources, let services vie for them without constraints, and offer best-efforts services.  Second, you can manage resources but exercise some form of “service admission control” to limit the commitment of resources to your planned level, which lets you offer broad grades of service.  Finally, you can map the specific way that services and resources are linked—provision services, in short.  The approach you take determines what you’d do with your data.

In our first two options, we don’t necessarily need to know anything about service-to-resource relationships, so we can do capacity planning by examining resource usage and service demand.  This is a “pure” big data or analytics problem, big because you’d likely need to look at everything and at frequent intervals, time-stamping and recording each combination.  You’d then examine trends, peaks, valleys, and so forth—classical usage-based capacity planning.

Even here, though, we may have some issues relating to services.  Capacity planning typically demands that we be able to relate service needs to resource usage, and unless the services are totally homogeneous in terms of how they use resources, we would need to understand a bit about the service mix, and also about any policies that were used to link services to resources.  An easy example is that if an operator is looking at the question of provisioning more service features via NFV, they have to know what resource usage can be attributed to the NFV approach relative to the “legacy” approach.

But it’s our final category that really cements the need to have service context.  When a service is provisioned, we are making a fixed resource assignment.  Unless we presume that all NFV VNFs are multi-tenant, at least some provisioning of this sort is inevitable in NFV deployments.  If there is a fixed resource commitment to a VNF or to any part of a provisioned service, we have to be able to derive the status of the service from the composite status of the assigned resources, and also to correlate resource faults with service-level SLA violations.  I’ve talked about this issue in other blogs so I won’t dig into it here.

There’s also a third thing, beyond collecting and correlating.  The final thing we have to consider in our big-data-and-analytics discussion is actionability.  If we want to do service automation, meaning really operations automation, we have to be able to visualize the service as a finite-state machine of many layers, and we have to assume that the service data model will tell us how to steer events to processes depending on what’s happening and what it’s happening to.  Analytics can easily feed things like capacity planning, but if we want to be able to make near-real-time or real-time changes based on analytics we have to have mechanisms to inform the service lifecycle processes or the resource processes that we want something done.  For that to work, this informing has to be an event and it has to be handled in a way dependent on the state of the resources and services we might be impacting.  So we’re back to state/event yet again.

I think the discussion of analytics and big data with NFV deployment is a clear demonstration that we’re building tires without having designed the car.  Management implementations are necessarily slaves of management policy, which is in turn a slave of service policy.  I think the right answer is actually visible here if you look at things that way, so we need to start demanding vendors take that approach.

Cisco has for years been two companies—one that generated most of the revenue but was focused on the clearly threatened switching/routing space, and another that aimed at high-flying and largely unproven opportunities in “emerging technologies”.  The difference has been stark enough that Street activists have called for a breakup of Cisco so the speculative urges of the market could play the emerging piece without dragging the legacy piece along.

Collaboration, or UC/UCC, has been a Cisco focus for quite a while.  They bought WebEx to get into the web conference space and they’ve launched both high-end telepresence and more SMB-friendly systems aimed at bringing video to the corporate mainstream—and video traffic to Cisco networks.  But collaboration has lagged expectations, and now Cisco is trying a reset on its approach, with what it calls Project Squared.

I’d love to give you a hands-on review of the new Cisco app-based model but I’ve not yet been approved to join it.  In the meantime, I’ll have to rely on what Cisco has said to take a high-level look at the Squared notion and see if it makes at least some sense.

The model Cisco seems to be using for Project Squared is a familiar one; you can get a free app and basic collaboration services over the Internet for nothing.  You can then, presuming you want/need to, buy enhanced capabilities to increase the utility of the concept.  This is very much like the model that some web conference players use, and what Microsoft is now apparently aiming at with its Skype for Business rebranding of Lync.

The Cisco approach seems to be based on virtual rooms, which are of course logical collections of users who combine to create a community in which information can be communicated and shared.  Being admitted (invited) to a room conveys you privileges of sharing files and communicating, something like shared folders in the cloud would do but much more ad hoc.  It would appear that a room can also sustain a bit of context, so like a Facebook page or Google+ Community it is also a way of establishing continuity for exchanges that are more than casual.

The differentiator for Project Square versus prior Cisco UC/UCC projects is the notion of an app, which can be run on laptops/desktops, tablets, and smartphones.  Cisco is framing this focus as a response to the increasingly mobile slant to worker communications, and it’s smart to do that.  First, the shift to mobile is real, and second, this is the most logical way to promote the Cisco shift in strategy.  The first punch of the one-two has to land for the sequence to be effective.

So does the second, though, and that’s where it may be harder for Cisco to drive the market.  Free stuff won’t make Cisco’s numbers in subsequent quarters.  They need to be able to sell adjunct capabilities and features.  Skype, which is the obvious market leader in casual communications, has been able to sell things like inter-calling with the PSTN and “inter-messaging” as well, but while Microsoft is clearly looking to create a link between Skype and Lync, they’ve yet to prove that people who are conditioned to free communication can then be made to spend something on an enhanced version.  Or at least that many will, and “many” is what Cisco needs.

The question in my mind is whether Cisco can step beyond traffic.  Project Squared needs to be valuable to users, and made more valuable by insightful features and extensions that Cisco would offer to augment the free app-based platform.  Those features had better not look like more naked traffic-driven opportunism.  They can’t be the Internet of Everything or the Cisco state-of-the-network report designed to convince operators to buy routers now before it’s too late.

We have file sharing.  We have personal communication.  It’s hard for me to see how Cisco can enhance either of these things in a material way, certainly not enough to build a business on the enhancements.  What is left is context.  I’ve blogged for a long time about the fact that mobile workers/users are different because context matters to them.  That’s the thing Cisco could, should, even must exploit.

There are two elements in context that Cisco could take aim at.  The easiest one is what I’ll call “historical” or “retrospective” context.  It’s a way of reviewing information and getting up to speed, of establishing the framework for something that you may not have been involved in from the first (or forgot the beginnings of).  The second and more difficult one is “situational context”, meaning the combination of external stimuli acting on collaborating parties at any given time.  It includes classic location-based services, conversational context, etc.

Both of these are valuable, but while historical context is both useful and relatively easy, it’s not proved compelling in the past.  Google Wave was arguably the most sophisticated attempt to establish and sustain historical context, and we all know what happened to it.  Google may have some patents strewn around the historical context landscape because of Wave, and the Google Docs/Apps stuff certainly gives Google a bit of a leg up on historical context by providing it a means of introducing documents and versions into the mix.

Conversational context might make a lot of sense for Cisco.  You could certainly link it to VoIP and telepresence, and you could also perhaps make a useful link to the Internet of Everything.  Imagine a worker sent out to fix something, a worker who gets there and establishes a “room” in which a team of experts joins in to discuss the problem.  Into which the “something” the worker was sent to fix also joins.  Collaborative work where what you’re working on also collaborates could be a big concept.

Too big, though?  Cisco has always been known as a fast follower, somebody who doesn’t make the market or take the risks, but relies on its own execution to take it from a trailing position to market leadership after the market is proven but before it really gets moving.  But that reputation was earned in the switch/router space, not in “emerging technologies”.  Cisco might surprise us with what they have planned for Project Squared.  I hope so, because I really don’t want to hear that the “Internet of Everything” has become the “Internet of Everyone and Everything”.

It’s also worth thinking that if Cisco does move more into contextual-linked collaboration, it’s likely to drive the market to respond.  That would generate a class of applications especially well-suited to the cloud because of their dynamism in both traffic and location of users.  The traffic patterns among components could be a driver for SDN because they’d be more data-center-centric except for the access connection.  The contextual link would also promote NFV, because automated deployment and management of complex multi-component applications is the key to their profitability.  Cisco is a network vendor with UCS feet; perhaps such a shift would even induce them to be more active with NFV!

Of all the components called out in the ETSI NFV E2E architecture, it may be that the most important is the VNF Manager or VNFM.  As the dialog on NFV advanced, there’s been a shift of benefit focus from savings in capex to improvements in operations efficiency and service agility.  In addition, the reliability, availability, and performance of NFV depend on its ability to respond to load changes and failures quickly and optimally.  The biggest question in all of NFV is whether VNFM is up to the job.  Maybe even what, specifically, the VNFM is.

There is very little said about the VNF Manager in the current E2E document; two sentences that say its role is lifecycle management and that a single VNF Manager could manage only one VNF or several.  If you look at the interfaces defined for the VNFM you get the sense that it is in fact the central repository for management functionality, but it’s difficult to see how it works.  Let’s look at the concept to see if there are any clues regarding how it should or must do its job.

Or let’s try.  Conceptually it’s hard to say just what a VNFM is.  Probably the best definition is that it’s the sum of the management requirements of both VNFs and their resources, but that definition is little more than saying that the VNFM is a kind of conceptual place-holder for stuff we need to get done and can’t assign anywhere else.  That leaves the VNFM in a kind of (virtual, of course) limbo.

In at least one sense, a VNFM should ideally be a piece of the “package” of functional components that deploys (via the Orchestrator).  Because it would be co-resident with the VNFs (in the same address space and mutually addressable) it could then parameterize the VNFs as needed.  In theory, it could also terminate any access that VNFs expect to make to resource MIBs, allowing us to synthesize a management view of multi-tenant elements and exercise control without stability and security risks.

The problem is that if a VNFM is a component of a loadable package, it’s potentially a major security risk.  It’s hard to see how a generalized VNFM could “know” what VNFs expected unless it was provided with them.  If it is, then giving it access to underlying multi-tenant resources is as bad as giving the VNFs direct access to the resources.  Every vendor who supplies VNFs could tweak things in their favor at the expense of other functions and services.

At a more mundane level, having a management component part of every deployed VNF package means that a lot of these VNFMs might be polling resource MIBs at any time, which could generate so much traffic that it destabilized the network, not to mention the resource being polled.  You can’t easily discipline what’s embedded in a vendor’s VNF package.

All these factors would argue against making a VNFM a part of a VNF package, but the most compelling argument is the assertion that VNFMs might manage multiple VNFs.  That would suggest that management functionality could be spread across services, and that would of course pose a significant risk if the VNFM were supplied on a package basis. If a single VNFM manages multiple VNFs, meaning multiple packages representing different services, then it creates a passageway through which information could flow between the services.  That, in my view, would mean that a VNFM could not be provided by a VNF vendor, or that such an offering would have to be carefully tested and certified by the operator.  So VNFMs should be centralized in some way.

Not much help so far, huh?  We’ll have to look further.  There are plenty of high-level issues with a VNFM, but those aren’t the only issues.  If we look at the mission again, the VNFM is expected to fulfill both the VNFs’ “local” management needs, providing parameterization and presumably asserting the MIB interface the user of the service would expect.  Both these requirements present challenges.

The most obvious problem at the mission level is that a network function has likely been decomposed into multiple VNF(Cs) for deployment.  That means that we have a set of interdependent components to deal with, and that these components may now have to be parameterized and managed both collectively (which is how the user likely sees them—as a virtual device) and separately since separate is what they really are.  There’s a general view that the VNF provider can offer parameterization and management in a suitable way, and that may well be true providing that there is no need to know anything about the underlying resources, or to operate on those resources in any way.

But is that the case?  Clearly the management state of a VNF could depend in part on the state of its resources, but even where the resources weren’t part of VNF state, the composite nature of functions like service chaining mean that you’d have to be able to construct a view of a collection of VNFs to present as the state of the “virtual device” to the user.  It’s also true that even parameterization of a device might set communications parameter values, in which case the process is now accessing resources.

I’ve pointed out before that the problem with management in NFV is that the management processes don’t necessarily understand the relationship between resources and services.  In NFV, the Orchestrator commits resources through a Virtual Infrastructure Manager.  The VIM clearly knows what resources it’s committed, but does it know anything about the relationship between the management parameters of the resources and the management state of the related services?  In order for the VNFM to work properly, it will have to inherit knowledge of resource commitments, but more than that it will have to be told what the specific resource-to-service management derivations are.  Does this particular value in that particular resource MIB convert to this or that status?

This gets even more complicated when you realize that the VNFM is expected to use the Orchestrator to deploy changes to the service, resulting from either changes made by the customer or problems/conditions encountered during operation.  We now have the possibility that the Orchestrator will be telling a VNFM something while the VNFM is also telling the Orchestrator something.  And of course, the VIM actually has to make the connections to the resources for any changes.  Chasing one’s (functional, virtual) tail comes to mind.

Which raises the question about management connections.  In the ISG’s E2E document it appears that the Orchestrator would generally pass fairly high-level requests to the VIM for deployment.  Given that, can we assume that the VIM has “told” the Orchestrator the management details of the resources?  Does the VIM also have to talk to the VNFM to propagate resource information?

If we stay with the functional mission of the ISG we can say that the VNFM does lifecycle management, but that gets us back to that almost-too-vague notion that it’s the NFV equivalent of the Universal Constant.  It seems to me that, speaking functionally, a service model has to define the structure of a service.  I don’t know of any proven way to describe things, though we could clearly pick from several different models or make up a new one.  Whatever model we pick, though, it should describe how we commit and manage resources, so both the Orchestrator and the VNFM would be anchored in the model.  Why not combine them, in effect at least?  If we said that each element in the multi-element model of a service steered events to processes via the data model, we’d be recognizing the structure the TMF first called “NGOSS Contract”.  A given service element could have a number of defined lifecycle states, and for each state a number of management events it recognized.  The combination of state and event could define a set of processes to be executed.  Since we could define “Ordered” as a state and “Deploy” as a command/event, we could then say that orchestration was a lifecycle phase, and the Orchestrator was invoked by VNFM.

All of this is enough to cause headaches, which may be why VNFM ended up as the place where unassigned management functions go.  But with management-driven benefits emerging as critical to the NFV business case, we need to get the VNFM out of limbo and either make it work or replace it with something that will.

We really need to start thinking of this stuff as software, and think of how we’re going to model the elements of a service.  A data-driven approach to lifecycle management seems not only mandatory but consistent with past efforts.  Protocol handlers are state/event, after all, and so (apparently, in a goal sense at least) was the TMF’s NGOSS Contract.  NFV fits somewhere in between; isn’t it logical it could be data-driven too?

Alcatel-Lucent announced last week that it was getting into the virtual router business, and at the same time announced an evolution to their Nuage SDN platform strategy.  The Nuage stuff it good; some of what they did is what Alcatel-Lucent and others should have done from the first with SDN.  Some of it also creates a vision of network services that could actually have made a better and broader business case for a virtual router.  All of it has potential, but it’s still not clear how far Alcatel-Lucent will push it nor how easily customers will accept it.

We’ve always tended to build IP networks using either a single large address space (the Internet) or by partitioning forwarding in some way to isolate portions of the network (VPNs).  When Nicira came along and proposed an overlay VPN, they opened the door for a different conception of network services.  In the overlay model, traditional networking (IP, Ethernet, even vanilla optical paths) simply provides routes for a new layer that’s “above” the traditional Level 3 but below Level 4 in the OSI model.  It plays the role of Level 3 but structurally uses services that would include “real” level 3 services.

Alcatel-Lucent’s Nuage approach has always focused on expanding on the overlay model by proposing that network equipment that could live in both worlds, to create a more effective network services by hybridizing overlay and traditional switching/routing.  However, it was initially focused on the data center, and so it just had the potential to create a different network service model.  What Alcatel-Lucent has now done is explicitly extend the model to branch or satellite locations, and thus realized that end-to-end property that’s obviously critical if you’re going to build a useful “network”.  Without it, you’re building only a network segment.

I’ve always liked the idea of using overlay SDN principles to create end-to-end networks and services.  What this would allow you to do is to establish application and service networks in the cloud and then pair them with edge/access services to create a complete pathway between user and resources.  I noted the potential Nuage had for creating such a service when their product first came out.  Now, Alcatel-Lucent has introduced most of what I’d hoped for in Nuage Virtual Network Services (VNS), and there are potentially significant benefits.

One benefit is that any combination of transport/connection resources can be used under VNS (you might have to fiddle to use underlayment services below the IP layer but it should be possible).  This would offer more choices in VPN provider, harmonize multiple providers, and combine all of that with public Internet where nothing else was available or feasible.

Related to this is the fact that since your overlay routing is highly flexible, you can select different paths for different types of traffic, using a more expensive service for stuff that justifies it and the Internet for lower-value traffic.  You can also fail over from one to the other under policy control to manage availability and cost.

A third benefit is that the overlay network is more secure.  While it may still be possible to attack points in the underlayment through DDoS for example, you can’t get onto the overlay easily because access is security/policy controlled.  You could even use the strategy to create application-specific networks and join groups of authorized users to them.

There are a couple of possible benefits too, ones I think either are already supported or are likely to be near-term extensions.  I can’t find validation in the documentation so we’ll have to retail the qualified notion of benefit for now.

The first of the possible benefits is application-specific networking all the way to the user.  If you could create multiple overlays, per-application or group thereof, in the data center and if you could link these to the branch, then selectively to “class-of-user” groups in the branch, you could fully segregate application traffic for security purposes.  I think this can be supported in the data center but I can’t see specific claims to be able to terminate multiple application networks in a single branch gateway.  It would be a great feature.

The other relates to the cloud.  Since the gateways can be either physical devices (appliances) or virtual ones, it would appear that you might even be able to put one of them into a cloud.  If that’s true then this could be a way for users to merge multiple cloud providers and internal data center resources into a single network.

The user could build VNS overlays on their own, but it’s also possible for an operator to build services based on this framework and offer them to users.  That could make VNS available to even SMBs, and it could open a pathway toward creating custom network relationships for cloud services.

If you think about the VNS approach, it raises some interesting questions about the broader application of IP to services.  Suppose we were to build a network infrastructure entirely of low-level pipes or tunnels, which could be based on any handy point-to-point protocol.  We could lay something like VNS on top of this and essentially do without routing in the traditional sense.  There might be scaling issues, but there might also be a way to overcome them—and create some agility at Layer 3 at the same time.

Suppose we go back to our low-level pipes, and instead of directly laying VNS on them, build instead a layer made up of virtual routers. Yes, the same kind that Alcatel-Lucent announced last week.  If we presumed that our low-level “pipe infrastructure” linked cloud data centers, then we could host router appearances in these data centers and create what would be parallel disconnected Level 3 networks.  The virtual nature of the routers means that you could select a Level 3 topology based on your traffic topology (likely based on branch/satellite office locations and connectivity).  You stick the routers where the traffic pattern says you need a node.  If it changes, you change node locations.  These could be offered per customer, per service, or whatever.  Again, this isn’t a complete replacement for IP and routers as we know them, but it could be an alternative way of offering business services.

And maybe more.  This model would allow operators to separate how VPNs and business services are offered.  It could also allow them to separate consumer services by service type, aggregating the traffic in serving offices and cell sites to create a single address space.  There might be less need for lower-level switching/routing using real devices; the “bottom of the stack” could be agile optics and tunnels—including SDN.

How far we’ll go along these lines is hard to say, and it’s harder to say how fast we might progress to whatever the destination happens to be.  Vendors may have a choice here—do they embrace the virtual model of the router, which would lower their revenue but also eliminate hardware cost and perhaps raise their margins?  Do they embrace the migration of lower-layer connectivity downward to the optical layer?  It think it’s clear that vendors like Alcatel-Lucent have more incentive to change the game in routing because they have related service and optical technologies that will still sustain them.  For the pure-play switch-router vendors, this trend might be a difficult one to navigate.

The media is all agog over the decision by the President to endorse a path to neutrality that would include reclassifying ISP services as Title II, meaning making the ISPs common carriers in terms of the Telecom Act.  I’ve read that it means the ISPs would become public utilities, or that they’d then have to share all their infrastructure.  I’ve also read comments that say that ISPs have to be regulated, that their natural behavior would be the end of the Internet.  I’ve read that the President is opposed to the kind of settlement that Netflix made with ISPs and that’s why he did it.  I’ve read he was playing politics, and that Republicans who oppose his view are playing politics.  I’ve read almost nothing that actually conveys anything realistic about the situation or our choices going forward.

As I’ve blogged in the past, the current state of Net Neutrality is that there isn’t any, in a formal sense.  The FCC has always said it had the authority to stop ISPs from blocking lawful content.  The issues arose with the last FCC (when Genachowski was the Chairman) because they wanted to take “neutrality” further, and specifically prevent any form of settlement among ISPs for priority handling, or provider-pays prioritization.  These steps were overturned by the DC Court of Appeals, who ruled that the FCC didn’t have the authority to take the steps it proposed.  Why?  Because those actions were appropriate for regulating common carriers (regulated under Title II) and the FCC had previously said that ISPs were not common carriers.

The legal back-and-forth here comes about because telecom policy was set out in the Telecommunications Act of 1996.  You have to go back to that time to understand why we’re where we are.  Then, the goal was to finalize the breakup of the Bell System by letting the RBOCs into long-distance and at the same time requiring them to share the infrastructure they’d developed while a protected utility.  The Internet wasn’t even mentioned in the Act, and this is why we have to dance around subtleties to get anything to happen.

The only real effort made by the Act to protect what we’d now call “the Internet” or “broadband” was the now-infamous Section 706.  Section 706 charged that “The Commission and each State commission with regulatory jurisdiction over telecommunications services shall encourage the deployment on a reasonable and timely basis of advanced telecommunications capability to all Americans (including, in particular, elementary and secondary schools and classrooms) by utilizing, in a manner consistent with the public interest, convenience, and necessity, price cap regulation, regulatory forbearance, measures that promote competition in the local telecommunications market, or other regulating methods that remove barriers to infrastructure investment.”  That’s been seen as giving the FCC broad authority to tweak regulations, but look at the text carefully and you’ll see the problems.

First, what does “encourage deployment on a reasonable and timely basis” mean?  The FCC has reported the state of Internet availability many times, and you’d have to say that generally people can get on the Internet, but is that reasonable deployment?  Is it “timely?”

Second, what are “advanced telecommunications capabilities?”  The presumption is that they’re broadband, but we don’t have a solid definition of what “broadband” is.  The historical meaning was greater than 64kbps, which is certainly available.

As far as remedies go, what does “a manner consistent with the public interest, convenience, and necessity…” mean?  And if the goal is to remove barriers to infrastructure investment, couldn’t you argue that the best way to do that is to allow things like settlement, paid prioritization, and so forth?  If the FCC calls on Section 706 as authority to do something specific with neutrality, they’ll have to establish a credible position grounding their action and authority in this one sentence, or they risk being back to where the DC Court of Appeals left them before—with no authority to act.

One of our options at this point is to proceed this way, and that’s what the President and others (Rep. Waxman proposed the same thing a month ago) have suggested.  The beauty of that approach is that it doesn’t require Congress to do anything, and that’s good because doing nothing is pretty much all we can expect from Congress these days.

What’s bad about the approach is that it has something everyone hates, which many would say is the sign of a fair start.  The telcos and cable companies in particular hate Title II regulation because unbridled Title II would give the FCC broad authority to do all manner of things, including force unbundling of infrastructure under some conditions.  Many neutrality advocates love Title II but hate the notion of Section 706 forbearance, because they believe that the FCC will simply exempt the operators from all the rules that they could/should apply.  Objective people are just concerned that whatever is done it will end up in endless litigation.  It took almost 8 years to hammer out an FCC interpretation of the Telecom Act, during which many believe broadband investment suffered because of the uncertainty.

The fear that the operators, the ISPs, will then have is that the declaration of Title II regulation would stand (it’s a separate issue but a prerequisite) and the application of Section 706 would be struck down.  That would leave the ISPs fully regulated as common carriers.  Does the FCC then say “I had my fingers crossed when I declared these guys common carriers?”  While it is true that the FCC is not bound by its own precedent (a nice way of saying it can change its mind), waffling on this is not going to improve the FCC’s credibility in the market or with Federal courts through which an FCC order would be appealed.

The other alternative is legislative change.  Congress could eliminate all the uncertainty by legislating a clear position, which both the FCC and the courts could then enforce.  The challenge is that legislating anything these days is difficult, as I’ve noted, and telecom regulation is really a battle of lobbyists.  One Congressman, after the Act was passed in 1996, said “We brought one side in and gave them everything they wanted, then we brought the other side in and gave them everything they wanted.”  Does this sound like a bulletproof process to you?

But legislation, presuming we could get it, have the advantage of actually creating rules that address the problem.  As I said, we’re backing into neutrality policy based on a legal framework that was never really intended to address that issue at all.  Enlightened legislation is obviously the best solution, but again I have to ask how anyone could believe, given the last couple years, that enlightenment was even possible.

And legislation would likely take a year or more, and that won’t be the end of the story.  Whatever is decided here by Congress or the FCC will end up in court.  Any FCC order will be appealed, as the last one was.  Any Congressional bill will mandate that the FCC publish rules to enforce it, which is what the Telecom Act did.  That’s how we spent the years between 1996 and 2004, finding rules that the courts would uphold.  We could easily waste the whole remainder of this decade and have nothing to show for it as 2020 dawns.  Most people would agree that the period after the Telecom act was the desert of broadband investment, in part at least because of regulatory uncertainty.  We could go there again with our neutrality efforts if we’re not careful.

And there is no right answer anymore.

We could debate the “best” policy here, but I have to say that it’s a waste of time because we probably could never get it passed and upheld in time.  The industry fears uncertainty more than policy, which is logical given that telecom investment is made on a 5-15-year capital cycle.  Until we have some promise of stability, we’ll suppress investment.  That’s why Cisco came out against Title II, but the same argument can unfortunately be applied to any path we take at this point.

Except perhaps one, which is the one we are on.  The FCC expressed confidence that it had the authority to stop operators from blocking lawful traffic.  Even if that’s not true, I think that publicity regarding a true blocking incident would be a disaster for the ISP who did it.  The fact is that this is about as far as realistic neutrality rules should go, not because it represents the optimum long-term policy we could set, but because it’s the least harmful option available to us now.  We have forces to balance, vast financial empires in the ISP and OTT worlds, and we have absolutely no idea what steps would be ideal, or even survivable.  When in doubt, let the market decide.

The industry needs ISPs at least as much as they need OTTs.  There’s no utility to an open Internet that you can’t get to.  We have to balance the consumer’s goal of getting everything for nothing with the supplier’s mandate to make a profit on what it invests.  That’s what regulators are supposed to do, but when they can’t do it effectively the best approach may be to get out of the way and let the market sort out everything but egregious abuses.  If Netflix doesn’t want to pay for transport of video, let them refuse and see what happens.  Let Comcast or Verizon let Netflix quality deteriorate and see if they can hold onto their customers.  Let other competitors decide if they’ll provide guarantees to Netflix for nothing, just to get some of those customers.  What is profitable for all is best sorted out by the marketplace.  That’s how we buy cars, after all.  And no matter what the government says, you’re not going to get BMW to lease you a high-end model for twenty bucks a month.  You’re not getting high-end Internet for that either.

An industry is an ecosystem, a cooperative economic unit that shows its directions and signals its changes in many ways, through many channels.  Today we have a set of signals that add up to something very interesting, very disturbing to many.

Cisco reported their numbers, which the Street characterized as “solid” but with “disappointing guidance”.  The net of the numbers is that Cisco is leveraging its position as a market leader in a market that’s not going where Cisco wants it to.  I think that one of the most interesting comments on the Cisco call is where Chambers says “we are winning the SDN battle with application-centric infrastructure.”  What Cisco is doing, of course, is winning against the pure notion of SDN with something designed to reduce the gap between what legacy networking could do and what SDN promises.

What SDN promises is lower costs in networking, which is why Cisco doesn’t like the pure notion.  We have a really simple truth developing here, developing in fact for almost ten years in the network operator space and half that in the enterprise.  We have not developed new benefits for networking, therefore our applications of networking are less profitable, less beneficial.  That means we have to spend less.  QED.  SDN is interesting to buyers because it would achieve that goal, but it’s in the vogue to talk about all the things SDN could do rather than that big unpalatable thing it would do.  Unpalatable because no vendor wants their market to get smaller.

What Cisco’s numbers demonstrate is the consequences of simply wishing away problems.  Cisco’s stock is off, people are disappointed with guidance, because in the end Cisco isn’t developing a new value proposition for networking, one that would raise benefits and thus help raise spending and margins.  And Cisco isn’t alone.

At the end of last month, before Cisco’s earnings and before Juniper’s sudden change of CEO, Juniper’s chairman and CTO did a Wall Street talk in which he said the networking industry was “confused” and that he proposed to end that confusion.  It had comments like “Less than 15% of the market is subject to commoditization”.  Wrong; with no real new benefits and buyers 100% focused on cost, all of networking is at risk.  Or “the market is coming to us” because traffic is essentially all IP over Ethernet.  Wrong.  The market already came—the success of the past is due to the shift toward IP, “convergence” which was also cost-driven.  And the operator revenue per bit has fallen through that whole shift.  The market is coming to Huawei, the price leader.  And how about “All networks need routers”.  Wrong.  It’s not even true that all networks need routing.  80% of all profitable traffic never needs to be “routed” at all.  You could do it with a metro aggregation network and a giant BRAS.  And eventually we will, unless vendors get smart.

Juniper’s solution is more boxes, more ASICs.  Cisco’s solution is to trap just enough of the projected features of SDN to obscure the fact that its notion of winning the SDN world means sustaining product price and margins in a market that is expecting reduced costs.

The third big vendor, Alcatel-Lucent, announced yesterday that it was joining the virtual router fray.  But the company was careful to say that despite the fact that it’s touting the performance of its own approach (done in concert with Intel for the hardware side) this new virtual router is really suitable only for edge missions.  That’s not much of a concession given that data center routing is clearly moving toward virtualization given the cloud and hypervisor trends.  A new conception of IP services, as I pointed out with Juniper’s virtual router announcement, could offer the network operators something agile and less expensive, but of course cutting costs isn’t the goal for vendors anywhere.

Except, perhaps, “vendors” who are not network vendors.  Also yesterday, HP announced a partnership with Nokia to provide Nokia mobile functionality as VNFs to an HP NFV platform.  You might see this as yet another of those “NFV billboard” announcement where somebody joins someone else’s ecosystem so they can both issue a press release, but there’s more to it.  The “more” may spell the big story in industry change.

NFV’s success depends on being able to run a bunch of stuff as virtual functions.  Ideally, as I said in both my CloudNFV and ExperiaSphere initiatives, you should be able to run anything that runs in a virtual machine/container or in the cloud, or on a popular host platform as a VNF without changing the software being run.  The thing I think is important about HP/Nokia is that VNFs created by one vendor are being framed for deployment on a platform of another.  While that doesn’t promise my utopian vision of “run-everything”, it at least addresses the problem of “VNF silos”.

Remember IP convergence?  Well, as one operator put it, “I didn’t converge on IP infrastructure to create service-layer silos on top if it.”  The network equipment vendors have proven virtual function resources they can deploy, and most of them intend to deploy them on their own NFV platform.  They also want to deploy their own “SDN” on their own “Controller” platform.  All of this is great at supporting prices and margins for those network vendors, but again it defies the buyer’s interest in controlling costs.  The only people who can break the logjam are the IT vendors.

What makes HP particularly interesting here is that the Nokia thing is the second partnership—the first was with Wind River.  With the Wind River deal, HP acquires all the tools to build an industrial-strength platform for NFV execution, something that can provide services that an operator could guarantee and for which the buyer could contract an SLA.  Now they frame the first explicit signal of VNF populism in the market.

And they are cloud people.  Saar Gillai, who is the GM of HP’s NFV business, is also the COO of HP’s cloud business.  As far as I know, he’s the only NFV head who is a cloud guy.  That’s important because the only path for SDN and NFV to add value instead of just cutting costs is to extend both notions across both carrier infrastructure and information technology for the enterprise—public and private.  We’d never accept a cloud platform that runs only applications from one vendor, after all.  We’d never accept a data center connectivity solution that works with only one class of switches and locks us into that vendor forever.  We won’t accept NFV or SDN to create new kinds of silos instead of breaking silos down.

If network vendors were the only source of SDN and NFV functionality, we might see the technologies roll out in anemic form in five years or so, once the vendors had figured out how to protect their turf.  IT vendors like HP can break that pattern because their entry into the market introduces a player who has nothing to lose in abandoning the past.  And while the lesson will surely be painful for the network vendors to learn, the fact is that it’s just as much the market teaching it as HP.

From the first, Juniper has had perhaps the strongest hardware technology of any network vendor.  For a time, in the middle if the last decade, it also had some of the best marketing.  Then things turned for Juniper.  It brought in a CEO from Microsoft, a CEO who was supposed to take the company into the new age of software.  He didn’t.  They then got an activist investor who pressured for increased shareholder value.  A new CEO came in, one who seemed focused on spending the company’s cash to prop up share price.  Now, that CEO is gone too, after only about a year.  A new CEO from inside was named, Rami Rahim.  The obvious question is “Can he turn things around?”

The plus side is that Rami is a Juniper insider, a person who knows the company’s culture, people, and strength.  He headed R&D and was involved in Juniper’s seminal MX router.  You also might assume that getting a product guy into the role is a signal that the Juniper Board is changing its own course, and trying to build a future and not mortgage one.

The minus side is that Rami is an insider, perhaps too rooted in the boxes-and-chips mindset that was great a decade ago but that has now run its course.  The future of networking is software, and can a hardware guy preside over a spurt of software innovation?  Maybe, if he does the right thing.  What might that be?  Not being one to hold back on advice, let me give some (unsolicited) to Rami.

First and foremost, you have to create a solid story in SDN and NFV.  Not the anemic me-too stuff you have now, but something that will address what the operators really need to get from both technologies.  SDN and NFV stands or falls on software above the traditional network hardware–above the network in fact.  There’s a lot of open-source stuff out there that could be harnessed to tell a more complete story in service and network operations, orchestration, and management.  You need to get it, and tell that story.  You’ll have to fight your own roots, some old friends, and maybe even some old bosses to do this.  It’s necessary.

Second, you need to inspire your own company.  Juniper has had years of bad management at the top, and you’re suffering a major hemorrhage of human capital, the very mobile, industry-aware people you can’t afford to lose.  Most of them don’t want to go, but they don’t see a choice.  Give them one, and show them which choice is the right one.

Third, you have to inspire the Street.  Your predecessor wasn’t my kind of guy, but his biggest problem was that he was dancing to the Street’s tune.  Some of the problem is likely your own board; who hired your last (bad) pair in the first place?  Some of the problem is the “activist investor’.  You need to avoid having costs run away while you’re establishing your software credentials, but you also need to present a compelling vision of the network of the future and Juniper’s place in it to Wall Street.  Juniper needs to be a growth company to keep the sharks off your neck.  Show them how that comes about.  Otherwise they’ll just push you out too.

Fourth, you have to harness hardware and not let it drive the bus.  Hardware, in the IT world, is something you run software on.  We’re heading there in networking, but unlike the IT world there’s still a big opportunity to define just what it takes to run network software.  Juniper has done some great work in ASICS and done some lousy positioning of that work.  Mostly because it wanted the chip to be the center of the universe.  Make it a tool, the thing that can make your software better.

Fifth, harness your visions.  Juniper has been out in front of a lot of important developments.  Juniper talked about what became the cloud before anyone else.  They talked about proto-SDN and proto-NFV.  They then let all of that leadership go to waste.  Juniper had a separate chassis for an expanded control plane; it’s gone.  They had a global initiative to modernize service creation and deployment, one that actually had a better foundation than either SDN or NFV.  It’s gone too.  It may be too late to turn back the clock, but it’s darn sure not too late to turn back the practice of turning away.

Sixth, get your marketing mojo back.  Your positioning has been insipid for years now.  You can’t educate a marketplace, you have to inspire it.  You can’t spend cycles and money buying favorable opinions of yourself and your products; the customer sees through all this stuff.  The press will never sell your product.  analysts won’t sell it either.  YOU have to sell it, using those other channels to connect to your buyer, not to carry your message.   Your PR is awful, your website is awful.  But fixing both is a wave of the hand for you now.  Wave.

Finally, lead.  This is no time to build consensus, to seek opinions.  Be sensitive to their ideas, respect their views, but lead.  You need to get Juniper moving very quickly because they have sunk a very long way and there’s not much time left.  That time has been given to you.  Use it wisely and you’ll be remembered as the guy who made Juniper great again.

OSS/BSS is part and parcel of the business of network operators, the way they manage their people, sell their services, bill and collect, plan…you get the picture.  The question of how OSS/BSS will accommodate new stuff like SDN and NFV is thus critical, and anything critical generates a lot of comment.  Anything that generates comment generates misinformation and hype these days, unfortunately, so it’s worth talking a look at the problem and trying to sort out the real issues.

To start with, the truth is that accommodating SDN and NFV isn’t really the issue.  The challenge operations systems face these days arises from changes in the business of the operators more than the technology.  Operators acknowledge that their traditional connection services are returning less and less on investment in infrastructure.  That means that they have to improve their revenue line and control costs.  It’s those requirements that are really framing the need for operations changes.  They’re also what’s driving SDN and NFV, so the impact of new technologies on OSS/BSS is really the impact of common drivers.

Human intervention in service processes is expensive, and that’s particularly true when we’re talking about services directed at consumers or services with relatively short lifespans.  You can afford to manually provision a 3-year VPN contract covering a thousand sites, but not a 30-minute videoconference.  We already know that site networking is what’s under the most price pressure, so most useful new services would have to move us to shorter-interval commitments (like our videoconference).  That shifts us from depending on human processes to depending on automated processes.

Human processes are easily conceptualized as workflows because people attack tasks in an orderly and sequential way.  When we set up services from an operations center, we drive a human process that when finished likely records its completion.  When we automate service setups, there’s a tendency to follow that workflow notion and visualize provisioning as an orderly sequential series of actions.

If we look at the problem from a higher perspective, we’d see that automated provisioning should really be based on events and states.  A service order is in the “ordered” state when it’s placed.  When we decide to “activate” it, we would initiate tasks to commit resources, and as these tasks evolved they’d generate events representing success or failure.  Those events would normally change the state of the service to “activated” or “failed” over time.  The sum of the states and the events represents the handling model for a given service.  This is proven logic, usually called “finite-state machine” behavior.  Protocol handlers are written this way, even described this way with diagrams.

The processes associated with setting up a service can now be integrated into the state/event tables.  If you get an “activate” in the “order” state, you initiate the provisioning process and you transition to the “activating” state.  If that provisioning works, the success event then transitions you to the “activated” state where you initiate the process of starting billing and notifying the customer of availability.  You then move to “in-service”.  If provisioning fails, you can define how you want to handle the failure, define what processes you want invoked.  This is what event-driven means.

The reason for this discourse is that OSS/BSS systems need to be event-driven to support service automation, for the simple reason that you can’t assume that automated activity is going to generate orderly progression.  A failure during service activation is not handled the same way as one when the service is “in-service” to the customer, and we can’t use the same processes to handle the two.  So what is necessary in operations systems is to become event-driven, and that is an architectural issue.

We always hear about conferences on things like billing systems and their response to SDN or NFV.  That’s a bad topic, because we should not be talking about how processes respond to technologies.  We should be talking about a general model for event-driven operations.  If we have one, billing issues resolve themselves when we map billing processes into our state/event structure.  If we don’t have one, then we’d have to make every operations process technology-aware, and that’s lousy design not to mention impractical in terms of costs and time.

But a “service state/event table” isn’t enough.  If we have a VPN with two access points, we have three interdependent services, each of which would have to have its own state/event processes, and each of which would have to contribute and receive events to/from the “master” service-level table.  What I’m saying is that every level of service modeling needs to have its own state/event table, each synchronized with the higher-layer tables and each helping synchronize subordinate tables.  The situation isn’t unlike how multi-layer protocols work.  Every protocol layer has a state/event table, and all the tables are synchronized by event-passing across the layer boundaries.

Where do our new technologies come into this?  First, they come into it in the same way the old ones do.  You can’t have automated operations that sometimes works and sometimes doesn’t depending on what you’ve translated to SDN or NFV and what’s still legacy.  All service and network operations has to be integrated or you lose the benefits of service automation.  Second, this illustrates that we have a level of modeling and orchestration that’s independent of technology—higher levels where we ask for “access” or a “VPN” and lower levels where we actually do the stuff needed based on the technology we have to manipulate to get the functionality required.

We could deploy SDN and NFV inside a “black box” that could also contain equivalent legacy equipment functionality.  “AccessNetwork” or “IPCore” could be realized many different ways, but could present a common high-level state/event process table and integrate with operations processes via that common table.  Any technology-specific stuff could then be created and managed inside the box.  Or, we could have a common architecture for state/event specification and service modeling that extended from the top to the bottom.  In this case, operations can be integrated at all levels, and service and network automation fully realized.

Our dilemma today is that every operator is looking for the benefits of event-driven operations, but there’s really nobody working on it from top to bottom.  If you are going to mandate operations integration into SDN or NFV state/event-modeled network processes, then you have to define how that’s done.  But SDN and NFV aren’t doing management.  Management bodies like the TMF are really not doing “SDN” or “NFV” either; they’re defining how SDN or NFV black boxes might integrate with them.

We can’t solve problems by sticking them inside an abstraction and then asserting that it’s someone else’s responsibility to peek through the veil.  We have to tear down the barriers and create a model of service automation that works for all our services, all our technology choices.

Juniper has followed the lead of competitors Brocade and Cisco in launching a virtual router product.  Their press release on this was refreshingly entertaining, offering the announcement in the context of an example of what it might do.  The only problem is that Juniper hasn’t really done anything more than either Cisco or Brocade in explaining the benefits of virtual routers.  That raises the question “Why not?”

Under the covers, every virtual router has a common goal—allow what used to be a router device to become a software-hosted equivalent.  The most obvious benefit you’d achieve from this sort of substitution is the capex benefit, the assertion that the combination of the router license cost and the cost of the server that hosts it would be less than the cost of the “real” router device.  It’s a kind of NFV argument, although routers were not specific targets of NFV.

The issue this creates from the vendor side is pretty clear.  If a real router device costs x dollars, and the sum of the costs of software and server have to be no more than perhaps 0.75x, then the cost of the software has to be a lot less.  That means that by promoting virtual routing, vendors are undermining their revenue stream.

Cisco and Juniper have deep issues here, obviously, because they’re in the router business.  They either have to try to align the mission of their virtual products to minimize their impact on current router sales (which seems to be Cisco’s approach) or suggest there are benefits to virtual routers that go beyond capex—which is what Juniper’s press release implies.

Brocade can dodge this issue because its Vyatta line aims at a routing market where Brocade doesn’t field traditional devices at all.  Arguably, Brocade is in the position to be the disruptor in this whole space because they have little or nothing to lose.  Buy Vyatta and a server and save (for example) 25% of your budget off the top.

In the end, though, a vendor likes a market that’s getting bigger rather than getting smaller.  Declining network budgets reduces the perceived importance of networks and the influence of network personnel.  This, at a time when revolutions like SDN and NFV demand new concepts be explored and deployed.  Cost reduction as a goal effectively drains the pool while you’re trying to learn to swim.

Juniper’s approach to evading a pure-capex-reduction value proposition, as it outlines in its release, is postulating a future of services where the network operator can turn on cloud-based features and applications from a simple portal, responding to business needs the way an OTT player could respond.  It’s the most creative way Juniper has presented its offerings, and there’s an element of truth in what they propose.  Also, three issues.

The first issue is that service agility at the network level and service agility at the application level aren’t necessarily strongly related.  If an enterprise wants to augment basic Internet with cloud-based UC/UCC and other applications (as the Juniper release proposes), most of that augmenting has to be done above the network.  In fact, if the OTTs are really the preferred providers for these services as the release suggests, there can be no network tie at all since the OTTs can’t manipulate the network underneath.

The second issue is that whatever is agile and whoever provides it, you have a service management and operations problem first and a technology problem second.  Building the kind of service described is an exercise in combined network/cloud orchestration and management, and so it’s really an example of what NFV should provide.  Most of what vendors want to claim for operations efficiency and service agility can be claimed only if you change to a more comprehensive implementation of NFV-like MANO.

And issue three is critical.  Servers are not as reliable as hardened devices, and while you can manage availability through resiliency and performance through load-balancing and scaling, this adds complexity to the operations side.  It does you no good to postulate benefits that can be attained only at a cost that’s greater.  Traditional network ops can’t manage virtual devices effectively.

The sum of these points is that you need a really flexible operations-management framework to provide agility and efficiency, over top of whatever network-layer accommodations to those goals you might make.  But even with one, there’s still no specific link between agility/efficiency and virtual routing.  What Juniper, and Cisco and Brocade as well, need to do is to tie virtual routers explicitly to services in some way.  So let us, in the way of an exercise, look at how that might be done.

What’s the difference between a software router and a physical device, in an agility sense?  The answer is that a physical device is put somewhere physically, and a software router can be put somewhere virtually.  If you assume a server pool that’s reasonably distributed through an operator domain, you can put virtual routers anywhere.  When you build a private network for a user, you can put routers where they should logically be based on traffic patterns.  When you build service networks designed for multi-tenant operation you can do the same thing.  If you used physical devices, you’d have to move current boxes and install new boxes, or pre-position boxes that could be used effectively in a multi-tenant mission.

This means that the value of virtual routing is greatest where the distinction between virtual and physical placement is most valuable.  Where a virtual router is really helpful is where you create separate Level-3 service topologies ad hoc.  Traffic patterns are created by the juxtaposition of process points and information sources/sinks.  Effective topologies match traffic patterns.  If we build VPNs or any other business service by assembling lower-layer (agile optics, Carrier Ethernet) pipes and connecting them with routers, we can do it better and faster and cheaper with virtual routers.  That’s because we can put those virtual routers where traffic dictates.  If we build partitioned networks at Level 3 for services like IMS or cloud computing, we can do that better/faster/cheaper too.  The move toward agile optics, toward contained and service- or customer-specific subnets, could boost virtual router value considerably.

You could make a strong case for virtual routing of this type even if you were an OTT, presuming that you were networking virtual routers together with tunnels.  That means cloud computing could use them, and content delivery and more.  But to get back to my early point, all this agility is useless if you have a two-week-long manual process associated with just taking the order, or you squander human capital just keeping your network connected.  We have to wrap something that can be agile in a framework that exploits the property of agility to secure provable business benefits.

The moral here is simple.  We are starting to jump on the opex-reduction and service-agility bandwagons now because capex reduction is 1) already done, so it’s no longer news, and 2) it’s eating the vendors’ own young.  Getting PR is a good thing.  Creating a strategy that’s not self-cannibalizing is also a good thing, but you have to go beyond the slogans to get the benefits.  That means redoing operations.  Nobody—not Juniper, Cisco, or Brocade, has that in their message or offers what I’d consider a clear path to it.  And no, OpenStack integration isn’t the solution either; not by itself.  You can’t solve a problem by handing it off to something else, unless that something solves it.  OpenStack and OpenDaylight aren’t full management and orchestration, and that’s what the virtual world needs, whatever your product strategy might be.

Juniper’s heading on their release is The New “Virtual” Reality, and that’s a fair characterization of where we are.  We’re discovering that agility is the cure for inertia, and virtualization is the path to agility.  We now need to discover that this virtualization thing has to envelop operations first, or we can’t take it anywhere else and be effective.  None of the virtual-router players so far, including Juniper most recently, have done that.  But it can be done, and eventually somebody is going to get this right.