We have no shortage of orchestration activity in standards groups, and the MEF has redoubled its own Life Cycle Orchestration (LSO) efforts with its new MEF 3.0 announcement. The overall approach is sound at the technical level, meaning that it addresses things like the issues of “federation” of service elements across provider boundaries, but it also leaves some gaps in the story. Then there’s the fact that the story itself is probably not completely understood.
Virtualization in networking is best known through the software-defined network (SDN) and network functions virtualization (NFV) initiatives. SDN replaces a system of devices with a different system, one based on different principles in forwarding. NFV replaces devices with hosted instances of functionality. The standards activities in the two areas are, not surprisingly, focused on the specific replacement mission of each. SDN focuses on how forwarding substitutes for switching/routing, and NFV on how you make a hosted function look like a device.
The problem we’ve had is that making a substitution workable doesn’t make it desirable. The business case for SDN or NFV is hard to make if at the end of the day, the old system and the new are equivalent in every way, yet that’s the “replacement” goal each area has been pursuing. Operators have shifted their view from the notion that they could save enough in capital costs by the change to justify it, to the notion that considerable operational savings and new-service-opportunity benefits would be required. Hence, the SDN and NFV debates have been shifting toward a debate on service lifecycle management automation.
Neither SDN nor NFV put SLMA in-scope for standardization, which means that the primary operations impact of both SDN and NFV is to ensure that the opex and agility of the new system isn’t any worse than that of the old. In fact, NFV in particular is aiming at simple substitution; MANO in NFV is about getting a virtual function to the state of equivalence with a physical function. It’s the lack of SLMA capability that’s arguably hampering both SDN and NFV deployment. No business case, no business.
The MEF has taken a slightly approach with its “third network”, and by implication with MEF 3.0. The goal is to create not so much a virtual device or network, but a virtual service. To support that, the LSO APIs are designed to support “federated” pan-provider control of packet and optical elements of a service, and also for the coordination of higher-layer features (like security) that are added to basic carrier Ethernet.
There are three broad questions about the MEF approach. First is the question of federation; will the model address long-standing operator concerns about it? Second is the question of carrier-Ethernet-centricity; does the MEF really go far enough in supporting non-Ethernet services? Finally, there’s the overarching question of the business case; does MEF 3.0 move the ball there? Let’s look at each.
Operators have a love/hate relationship with federation, and I’ve worked for a decade trying to help sort things out in the space. On one hand, federation is important for operators who need to provide services larger than their own infrastructure footprint. On the other, federation might level the playing field, creating more competitors by helping them combine to offer broader-scope services. There’s also the problem of how to ensure that federation doesn’t create a kind of link into their infrastructure for others to exploit, by seeing traffic and capacity or by competing with their own services.
Facilitating service federation doesn’t address these issues automatically, and I don’t think that the MEF takes substantive steps to do that either. However, there is value to facilitation, and in particular for the ability to federate higher-layer features and to integrate technology domains within a single operator. Thus, I think we can say that MEF 3.0 is at least useful in this area.
The second question is whether the MEF goes far enough in supporting its own notion of the “third network”, the use of carrier Ethernet as a platform for building services at Level 3 (IP). I have the launch presentation for the MEF’s Third Network, and the key slide says that Carrier Ethernet lacks agility and the Internet lacks service assurance (it’s best-efforts). Thus, the Third Network has to be agile and deterministic. Certainly, Carrier Ethernet can be deterministic, but for agility you’d have to be able to deliver IP services and harmonize with other VPN and even Internet technologies.
While the basic documents on MEF 3.0 don’t do much to validate the Third Network beyond claims, the MEF wiki does have an example of what would almost have to be the approach—SD-WAN. The MEF concept is to use an orchestrated, centrally controlled, implementation of SD-WAN, and they do define (by name at least) the associated APIs. I think more detail in laying out those APIs would be helpful, though. The MEF Legato, Presto, and Adagio reference points are called out in the SD-WAN material, but Adagio isn’t being worked on by the MEF, and as a non-member I’ve not been able to pull the specs for the other two. Thus, it’s not clear to me that the interfaces are defined enough in SD-WAN terms.
Here again, though, the MEF does something that’s at least useful. We’re used to seeing SD-WAN as a pure third-party or customer overlay, and usually only on IP. The MEF extends the SD-WAN model both to different technologies (Ethernet and theoretically SDN, but also involving NFV-deployed higher-layer features), and to a carrier-deployed model. Another “useful” rating.
The final point is the business-case issue. Here, I think it’s clear that the MEF has focused (as both SDN and NFV did) on exposing service assets to operations rather than on defining any operations automation or SLMA. I don’t think you can knock them for doing what everyone else has done, but I do think that if I’ve declared SDN and NFV to have missed an opportunity in SLMA, I have to do the same for the MEF 3.0 stuff.
Where this leaves us is hard to say, but the bottom line is that we still have a business-case dependency on SLMA and still don’t have what operators consider to be a solution. Would the MEF 3.0 and Third Network approach work, functionally speaking? Yes. So would SDN and NFV. Can we see an easy path to adoption, defined and controlled by the MEF itself? Not yet. I understand that this sort of thing takes time, but I also have to judge the situation as it is and not how people think it will develop. We have waited from 2012 to today, five years, for a new approach. If we can’t justify a candidate approach at the business level after five years, it’s time to admit something was missed.
There may be good news on the horizon. According to a Light Reading story, Verizon is betting on a wholesale SD-WAN model that would exploit the MEF 3.0 approach, and presumably wrap it in some additional elements that would make it more automated. I say “presumably” because I don’t see a specific framework for the Verizon service, but I can’t see how they’d believe a wholesale model could be profitable to Verizon and the Verizon partner, and still be priced within market tolerance, unless the costs were wrung out.
We also have news from SDxCentral that Charter is looking at Nuage SD-WAN as a means of extending Ethernet services rather than of creating IP over Ethernet. That would be an enhanced value proposition for the Third Network vision, and it would also establish that SD-WAN is really protocol-independent at the service interface level, not just in the support for underlayment transport options. This is the second cable company (after Comcast) to define a non-MPLS VPN service, and it might mean that this will be a differentiator between telco and cableco VPNs.
How much the MEF vision alone could change carrier fortunes is an issue for carriers and for vendors as well. Carrier Ethernet is about an $80 billion global market by the most optimistic estimates, and that is a very small piece of what’s estimated to be a $2.3 trillion communications services market globally. Given that, the MEF’s vision can succeed only if somehow Ethernet breaks out of being a “service” and takes a broader role in all services. There’s still work needed to support that goal.
