The MEF has been doing a kind of reboot, transitioning to something other than pure carrier Ethernet. One effort, the “Third Network” apparently confused a lot of people (what, they wondered, were the first two), and so the current efforts are titled more conventionally, as MEF 3.0. It’s more explicit about its vision, and in particular more explicit about support for SD-WAN. Is there enough substance here, or is this just another industry body seeking a sustaining vision? To find out, we’ll need to look at the problems the MEF is trying to solve.
The original notion of the Third Network was based on the presumption that a service network could be built over a combination of networks, some (obviously) based on Ethernet. Rather than assuming everything had to be over IP, the MEF vision presumed any combination of technologies could be used. It also supported pan-provider federation. Finally, it introduced the notion of Lifecycle Service Orchestration (LSO), which has become a specific centerpiece of the MEF 3.0 vision. The Third Network was, as I’ve noted, implicitly linked to an end-to-end service model but it didn’t really describe the model in a full sense. That’s an issue that I think is still a problem with MEF 3.0, though (as we’ll see below) it’s less one than it was before.
That defines the MEF side, what about the high-level vision? Services are what buyers purchase, so that’s what frames the goal of MEF 3.0. The idea is to create a service network that can ride on arbitrary operator networks. That service network will almost surely involve CPE, and it may also involve gateway elements that join the operator networks to create universal connectivity. Service networks that are independent of underlying transport infrastructure really have to be based on an overlay technology.
Overlay networks build connectivity on top of other connectivity, using a higher-layer header representing the higher-layer service. User traffic is injected into the service network, usually via CPE but perhaps also through virtual CPE (vCPE) and cloud-hosted software elements. Based on the service-network addressing of the packet, it’s assigned to both an exit interface (a network trunk connection) and an address on that network. If there are multiple networks utilized (SD-WAN often supports both MPLS VPNs and the Internet to reach all the users’ sites), then at least some sites have to have connectivity to all the transport networks used, or there has to be a network gateway available to pass between the available networks. We can call this the edge-connected transport or the gateway transport options.
The mapping between service network and transport network(s) can take a number of different forms. One is that the service network simply maintains its own addresses in an independent and perhaps proprietary way, and maps the addresses of all the service-level packets to the appropriate transport network destination. The other is that there is a formal tunneling protocol used, something that defines a virtual LAN, virtual or pseudowires, or another form of connectivity. The service-level data is injected into the tunnels based on address associations, which take it to the right destination.
I think a perhaps-more-scholarly-sounding presentation of these points would have benefitted the MEF from day one of the Third Network, and would still benefit them today. This illustrates the important things that MEF 3.0 has to contend with. First and foremost, it has to either define or identify the overall tunnel model(s) to be used. Is there only one, would any serve, etc.? That links to the second thing, which is the functionality of the gateway. You could in theory have different tunneling on either side of a gateway. Is that supported? Does the over-arching service protocol have to be a tunnel that then gets translated, or is it something that lives in a tunnel, and thus is the business of the end elements?
Whatever the answers to these points might be, there are three distinct layers to be considered. At the bottom, there are the actual operator networks, which realistically are probably either Ethernet or IP. In the middle are optional tunnel networks that provide segmented connectivity and transport across those networks, and at the top there’s the service overlay network that actually frames what the user sees as the connectivity service, and potentially provides other service-related features.
The purpose of MEF 3.0 is to define a set of APIs (LSO) that allow operators to deploy and manage the physical-network underlayment for a service network overlay, and to provide some (mostly future) limited management of the overlay framework. Control has to be exercised in three dimensions. First, you need to control the service relationship to the tunnel network, the interface and the SLA that is provided. This is probably a CPE/CLE function. Second, you have to control the tunnel network relationship to the transport underlayment(s), third the NNI between the different underlay networks. Both the latter are gateway functions.
You can contrast this with today’s basic SD-WAN or overlay SDN model, which I believe is the de facto standard for service overlay networking. The presumption is that you have an IP underlayment and that whatever connectivity is needed between/across the various types of IP or network operator administrative domains is provided by one or more of the endpoints. These have a connection to several networks/domains, and so can bridge traffic between them. If there is any deployment or management needed for the underlayment, it’s independent of the SD-WAN/SDN service. That’s a simple model of service that can be used by the operator, a third-party player like an MSP, or even directly by the user.
This, finally, brings us to an assessment of the MEF 3.0 model. That model is clearly not particularly simple. It can provide a level of service management and SLAs that isn’t available to traditional SD-WAN, and a means of harmonizing connectivity across multiple operators with a seamless service. Are the benefits enough to justify the complexity? In the short term, I’d have to say they are not. In the longer term? Perhaps.
The problem I see with the MEF approach is that it presumes a goal of pan-provider services using homogeneous infrastructure, and operators aren’t generally telling me that’s their goal. Some operators see SD-WAN simply as a way to extend their VPNs to places where they don’t provide MPLS or where customers can’t justify the cost—small, remote, locations. Other operators see SD-WAN as a means of providing service-layer isolation within their own footprint. In Europe, there is some interest in pan-provider networking, but it seems to me that most of it is satisfied by MPLS interconnect.
The differentiating features of SD-WAN, again in my personal view, have to be directed at the future, virtualized-infrastructure-and-cloud model. Pan-provider connectivity is more credible if you assume that cloud providers are part of the mix, but are cloud providers going to federate their network connectivity in a more traditional sense, offering connectivity in general and not just connectivity within and to/from their cloud hosting? If they don’t then the cloud and virtualization drive a need for formalized logical networking, which the MEF 3.0 specs don’t target at all.
Services aren’t sold to customers based on APIs they never see, but based on features that improve the value of the network to its users. I continue to believe that logical networking is the feature set that will drive overlay networks, and the success of any implementation of overlay networking will depend on the services created not on the way the infrastructure it tweaked.
I think all of this relates to the need for the MEF to have defined a high-level service model, including the primary missions for the service. They could then dissect the mission into features and map the features to their pan-provider architecture. SD-WAN is at least mentioned in MEF 3.0, and so you could presume it is a service mission, but the service-level features of SD-WAN seem to be considered out of scope, and without that it’s not clear whether the model of SD-WAN that the MEF will define will actually fit with the market’s requirements.
Why not? Because like most of the “networking bodies”, including formal standards groups, industry groups, and even open-source groups, the MEF is focused on the “how” more than the “what”. You cannot develop a useful standard for doing something you’ve not ensured is useful. The features of overlay services including SD-WAN that will define utility to the buyer are higher up on the technology stack, and the MEF continues to look too low. Yes, they define how operators could field an overlay solution, but not how the operator solution could be differentiable and valuable.
MEF 3.0 is very close to being useful, but it’s not there yet. The problem is not that the work they’ve done doesn’t have technical value, but that there’s a significant risk it won’t have market relevance. Given that network operator interest in SD-WAN and the general overlay service model is exploding, and given that we already have two players (VMware with NSX/VeloCloud and Nokia with Nuage) that offer a carrier-targeted overlay service architecture, the MEF needs to step up and get their story optimized, before it’s overtaken by market events. There’s still time, because neither of the carrier-overlay-network leaders has a complete logical networking story, and that’s the feature set that will pull through the SD-WAN model that will define the future.