March 20, 2018

Maturity of Projects, collaboration, cost constraints  and value add they bring together for NFV readiness has resulted in coming together of  different Network Projects with Architectural trade-offs. These are  ONAP, OPNFV OpenDaylight, FD.ioPNDA, and SNAS under the banner of Linux Foundation Networking (LFN).

The year long process starting folding of OPEN-O into AT&T opensource OpenECOMP to ONAP and ultimate consolidation into LFN along with sibling projects was like OPNFV was a lesson in consolidation and watching as insiders as well outsider teaches what to do or not to do as a player in the outcomes. Fortunately saner counsel have prevailed between Service Providers, Network Equipment vendors and complexity of Standards versus  Open Source baseline to addressed bumps on the road sufficiently enough to role the ball once again.

The challenge among service provider was what source to share besides requirements  as part of End User Advisory Group (EUAG) and who all want to work together (Resource and Skills Crunch). With Geographic, language, working time and jurisdiction constraints  the North America, EU and China were the three major contenders. ETSI with NFV, MEC and other IP had to make some of the standards public as Open Source was faster than they can ever deliver normative specifications. Product Engineering in Vendors were struggling with disruptions in their product line revenues, as delays in Service Provider decision results in lowering revenue trend. Overall pie does shrink while few players gain and later realize that baseline standards have moved. In-spite of great run from Openstack Cloud  as IaaS for most LF Networking Projects, the ability to support and VNFs for commercial deployment has been a work-in-progress. The Industry approach to go Top Down as well Bottom up has met resistance from community on both sides and ONAP and OPNFV were caught in the process to spell out Compliance verification beyond API level. The standards did no better as different forums like TMF, ETSI, IETF, MEF  and Service Providers listed their own process as way to go. Finally some semblance of agreement, to have a common process negotiated by TMF with ETSI adapting UML  and ONAP willing to use TOSCA besides YANG models for resource and service representation is good for the NFV rediness.

What to expect now is re-emergence of Next Generation  "Future Network Readiness" this has several angles from hardware, to software to full stack. COTS and Open Networking baseline  is there to stay. Yet High Performance Computing (HPC), Artificial Intelligence (AI), Machine Learning(ML), Deep Learning (DL) platforms are emerging from the ashes of NFV, SDN, Hadoop, and early feedback loop mechanisms to re-invigorate the same old same old "Network is Computing". The Management and Network Orchestration (MANO) is poised to handle the next generation Telemetry at the edge and device intelligence , discovery and Streaming traffic are waiting to leverage compute acceleration , NUMA and CPU pinning, Multi-core with SmartNIC and the list goes on to Element Management API top down as API for differentiated VNF and Network Service Bench Marking (NSB). The Software at other end are taking optimization path through Data Plane acceleration via P4, Path Computing Environment, SFC with  FPGA, SSD storage, SOC's to handle Security, Boot, latency and throughput statistics.

The realization that MANO is as good as it gets to rewrite OSS/BSS to exploit newer functional features to achieve better Reliability and Assurance for dis-aggregated, distributed, multi-site, multi-tenant  VNFs from base line Opensource to jump start commercial ones is the way and there is scope for innovation galore, yet minimize the gaps from  Standards. The platforms differences can be tolerated as long as they can support the VNF required by the Service Provider to offer multi-cloud inter-operable services.

Wish I have data points to elaborate the various hypotheses and claims made here, which are more subjective. But that is why the research firms exist to take cue and run with it to prove or disprove what one feels as part of the Open Source Eco system versus what facts are.

Welcome to the MANO-WG and look forward to changes in this forum over next few weeks based on LFN.

To keep abreast of fast moving MANO you can subscribe to OPNFV MANO WG.

Feb 1, 2017

MANO WG is gearing towards getting OPEN-O and OpenBaton  drive through their integration projects Opera and Orchestra in OPNFV helping build the bridge. These pilots are enabling NFVO Opensource projects to leverage on  OpenStack VIM and try align with ETSI using OPNFV. The OPNFV is striving toward  keeping VNFM and VIM to support build and deploy consistently across all NFVO. Thus if tomorrow OSM or OpenECOMP pursue there efforts to integrate over OpenStack, OPNFV has the ways and means to help verify their compliances based on some of the projects in NFV. Bottom line is we get some Best Practices to go by to automate the Integration and Orchestration of VNFs. We already have vIMS testing from OPNFV Brahmaputra release and its being updated for Danube release under FUNCTEST. Both Opera and Orchestra are attempting to use and trying to identify diferences and commonality. This helps bring to table different stake holders of the pieces. We have now debates in Infra Structure, Test and Mano Working Groups about what and how they would like to address the function of VNF catalog, On-boarding and configurations through Scenarios for different hardware (NFVi) , VIM and VNF. This also leads to validation and verification of these in OPNFV Platform testing. Adding to it usecases like vIMS has given real life OPNFV lab testing before one can move t to field. Meanwhile here were two OPNFV Plugfests based on Release B & C last year and likely to see one based on D release in Q2/Q3. ETSI meanwhile have their Plugtest running Jan23-Feb-3. The conclusions and details we will discuss in future blogs. To keep abreast of fast moving MANO you can subscribe to OPNFV MANO WG.


October 21, 2016

Year ends are always exciting as Holiday fever sets in. The slow and steady progress of OPNFV MANO WG is visible as it's  going to enter the 10th meeting next month. The challenges of collaboration are always in getting win-win situation for all collaborators. The same holds true for the MANO WG. Having got two upstream OPEN-O and Open Baton, with the ability to cover both fixed and mobile networks use cases to build on, OPNFV could not have asked for anything better. Although ETST NFV references in terms of Interfaces is still evolving, I believe OPNFV has the advantage of codes and best practices over beyond reference documents. The art of building stack is always challenging. OPEN-O has pegged on trying to modularize NFVO to run with different generic VNFMs. The early testing is planned using vIMS and thanks to existing tests in Clearwater(CW) which was tested earlier in Brahmaputra release ( This makes one path NFVO to VIM testing reusable to a larger extent. essentially refactoring for OPEN-O  as orchestrator. Meanwhile JuJu needs to be installed as gVNFM to help alternate path to test from NFVO to VNFM rather than direct to VIM. That need some time and should be taken up soon. By December first week OPNFV will have C 3.0 released and expect to see some exciting showcases at University of New Hampshire Plugfest event. (Plugfest - Colorado Release). Opera has taken off and Orchestra will follow as we have Models team working to get that streamlined for Release D. Look forward to collaboration to keep market innovating ahead of standards.


Aug 25, 2016

Lot has happened in two weeks from my last updates.

Congratulation to "Orchestra"  which plans to focus on vnf testing and deployment, was approved on Aug 16 TSC meeting. It will be interesting to see co-ordination on vnf onboarding between OPNFV Models, Orchestra and Functest and Yardstick in testing this feature through ETSI TST v1.1 APIs. The challenge here will be to document the gaps and workarounds this brings to table to help provide feedback to ETSI NFV MANO Standards.

The Hackfest on 24th Aug at Toronto was useful in generating ideas to streaming the usefulness of MANO WG through effective documentations of standards and gaps to focus on Policy based vnf onboarding as a baby step through participation in projects in OPNFV.

More work can be taken up provided we get more participation. Welcome to all new participants from different individuals from Vendors and Operators community. Refer to meetings link for summary.

Aug 10, 2016

We have two projects in upstream to OPNFV, OPEN-O and OpenBaton that are interested in using OPNFV VIM  and NFVi to integrate MANO stack top down using generic  NFVO and VNFM as part of interfaces for Integration Testing.

The first one named 'opera' from OPEN-O was approved yesterday in OPNFV TSC. This project is lead by Yingjun Li, who is coordinating between OPEN-O team and OPNFV team. Certainly a welcome news for OPNFV to  build ETSI NFV APIs as well use cases to establish a black box approach to testing the OPNFV Platform.

From MANO WG point of view we have several unanswered questions, that were asked and answered to some extent, here I just add the same for other OPNFV teams to help answer.

1) Parser in OPNFV and Heat Templates in OpenStack, have translations but OPEN-O uses Aria and currently aria ng is still under development. Possibility's are emerging to see if Domino can absorb Parser and provide "Template Parsing and Distribution Service"  but this is for project leads and OPNFV community to look at how to improve cross-project co-ordination, while maintaining the Project structures or allow them to transit.

2) Based on this Domino the template distribution currently is supporting option to select aria or heat translations and thus opera plans to use that.

3) Juju templates for configuration of VNF need to consider how they will comply with TOSCA compatibility or use JOID for OPNFV installation included as part of opera.

4) All installers are being requested to see how they can help support 'opera' in platform installation and test. This also means what Scenario in OPNFV they choose or add. Like in case of 'opera' the options are to use existing L3VPN or choose a new one say we call it 'vCPE' Scenario to be defined through help from Genesis/Installers team. Pharos team also need to help in this as labs are needed to test with standard network topology.

For now 'orchestra' the OpenBaton appears heading to test APIs offered based on ETSI and will thus help consolidate API based testing with Functest and Yardstick.

Look forward to see the approval of the same in next week or two based on the path 'orchestra' chooses to follow. Critical comments from OPNFV and other community is welcome.