VNF Manager is at middle layer and most important for Middle-box Appliance Vendors. Service providers need this to compose and decompose and dis-aggregate functions while still continuing to use legacy middle boxes to reach its End of Life. Thus it will be fine for standards as well Open Source offerings of VNF to evolve with different VNFM, before vendors can build better offers. Current thinking is, it would be good for MANO stacks offered by several upstream including OPEN-O, OSM, Tacker, JuJu etc. to sort out how both VNFM and NFVO interact to support Or-Vi and V-VNfm interfaces and associated functionality and APIs to minimize gaps. Some of the OPNFV projects like Modeling, VES , Domino, SFC, VNFFG , Doctor are potential candidates who can help build the ecosystem through commonly agreed way to manage VNF starting formats, packaging, on-boarding to meet standards VNF life cycle management. Eventually apply those best practices in current use case executions like L3VPN, SFC, IPv6 and future like dis-aggregated network functions at the edge , core and mobile IMS etc. Service Providers acceptance of OPNFV efforts to provide inter-operability of VNF, will be key to success and is a continuously evolving process.
Thus this will deal with Interfaces 4,5,6 and associated APIs besides VNF FCAPS,REL events and telemetry aspects.
Targets?Virtualized applications & network functions Life Cycle Management
Business Goal? VNF/VNFD On boarding, VNF Instance LC /Resource management.
VNF Deployment/On-boarding/Scaling/Fault-recovery using VIM & supporting NFVO