MEF today made two major announcements that are very different but build on the common theme of using collaboration among standards and open source groups to solve specific virtualization problems.
The first and easiest to understand is a new set of certifications and testing developing collaboratively by MEF , European Telecommunications Standards Institute (ETSI) and the Linux Foundation that are intended to help network operators in training (and retraining) operations staff to understand and be ready for network functions virtualization and software-defined networking.
More complicated are the two new orchestration specifications announced today for MEF 3.0, but these were also built to align with other standards groups, including TM Forum and Open Network Automation Platform (ONAP) , and to automate key back-office processes both within and between network operators to make services easier to deliver. (See MEF Unveils 2 New MEF 3.0 Specs and SDOs Collaborate on Certification Standards.)
The new specs, a Network Resource Management: Information Model, also known as MEF 59, and Network Resource Provisioning: Interface Profile Specification, AKA MEF 60, are part of the ongoing work within the MEF Lifecycle Service Orchestration (LSO) Reference Architecture. Unlike MEF specs of yesterday, these involve actual code development that is being used in open source groups such as OpenDaylight, notes MEF CTO Pascal Menezes.
More specifically, MEF 50 and MEF 60 help define the LSO Presto API which provides a key abstraction of underlying network technologies and their diverse programming languages, to enable automation of service delivery without having to manually configure each service every time, he says.
A wide variety of vendors contributed to both specs, with CenturyLink Inc. (NYSE: CTL) as the service provider involved in both and Jack Pugaczewski, distinguished architect at that operator, credited as the editor of MEF 60. In an interview, he says this step "can defuse long-running debate of information model versus data model."
"And what I mean by that is, through the tool chaining we can have and can get together the information model which has other benefits -- you can bring developers together, you can bring architects, domain experts and it becomes a common mechanism through sequence diagrams, through use cases, state machines, for everyone to talk together in a common language," Pugaczewski says.
That tool-chaining process which is defined in the spec allows network operators to understand and operate at a high-level language without having to also understand that low-level languages operating underneath that abstraction for every single individual service, Menezes explains. The tool-chaining can automatically generate the necessary network-based application programming interfaces (APIs) to provision a service, based on object models that define connectivity, endpoints, etc., for that service.
"The bottom line is that we have to get to APIs in a more automated tool-chaining way than hand-crafted," he says. "And when we specify what we want out of an API in a high-level language that most applications developers understand, they get it. They can read the specs, get it, then any application has the actual model, runs the model through the tool chaining and out comes the API in their language and that's really what they care about, everything is automated and they don't have to handcraft."
All of this is moving in the direction of intent-based networking, says Pugaczewski, or "telling you what I need, not how to do it." Menezes admits, however, that there is much work to be done to actually get to that stage.
MEF is moving much faster in that direction than in the past, however, having done the significant work on the Sonata and Presto interfaces for LSO in a little more than a year, and now working in three-month sprints to push forward, he adds.
What's also significant is that the work being done doesn't just apply to Carrier Ethernet services but to optical transport networks, SD-WAN and more, Pugaczewski notes.
The new testing and certification process builds on MEF's strength (and revenues) in that arena, but also represents first-time collaboration on these efforts between MEF and ETSI, which pioneered NFV, and the Linux Foundation, now home to the bulk of open source networking projects.
"We have always pulled in people from different organizations to help validate our tests and certification process but this is a more formal recognition of the relationship," says Rick Bauer, director of certification for MEF. "It has been a fantastic collaboration, just sitting in the room and letting all of this take shape so that the final blueprint has the scope and currency the industry needs."
Having that scope and currency is becoming more urgent as network operators move forward with NFV-SDN deployment plans even as a major shift takes place within their organization, he says.
"Three-fifths of current network engineers will be retiring as the baby boom generation starts moving away," Bauer says. "How do you validate the millennials that are going to come in and step into their places?"
The new testing and certification process includes a basic-level test, aimed at anyone in an organization including marketing and sales folks who need to understand NFV and SDN, up to the professional and expert levels.
— Carol Wilson, Editor-at-Large, Light Reading