Hi TT people,
I'm hearing from more customers now that they expect an application specific VNF-M to be packaged with any of the VNFs that they plan on purchasing from us.
The way that TDC has phrased it in a recent RFP for vCE:
"Most of the VNFs are expected to be delivered with their own VNF management function that encapsulate the VNF Package (scripts etc. needed to lifecycle manage the VNF) and exposing this to the NVFO and VIM using the standard interface. "
The way that KPN has phrased it in a recent RFI for vDNS:
"KPN expects the DNS solution to come with a VNF manager for the whole DNS portfolio of Supplier. Supplier is asked to describe an overview of the VNF Manager, and a more detailed description on provisioning, configuration, logging, assurance, monitoring and scalability."
Are we seeing this request from other customers as well? If so, we might need to look into making application specific VNF-M packages, based on ESC with all the integration scripts for a certain service included in the package.
Met vriendelijke groet / With kind regard,
Dirk-Jan van Helmond
Excellent input. While we have some specific packaging for our mobility use cases (Nephelo), we don't have any additional plans for cisco-specific VNFM (copying Michael Y to keep it honest).
Quite the opposite actually, we believe in open standards and interfaces such that we can deliver on the promise of generic VNFMs.
I agree that VNF-Ms should be open as well from a technical point of view.
But with the new software pricing models that we're developing, I can imagine that with the virtualised Service we bundle an ESC instance where the usecase is limited to managing that particular v-service.
The product managers of the virtualised services (vIOS-XR, CSR, vDNS, etc) should be incentivised to create all these MANO related descriptions and scripts to run their virtual products in an NFV-I environment.
Things like the create, destroy, scale-in and scale-out scripts for ESC and the VNF-D (in YANG & TOSCA).
This lowers the integration work that needs to be done on the customer site, which can potentially de-risk the services engagement.
IMHO, we should do a better job of making sure each VNF has fully-feature supported VNF-M (e.g. ESC together with the right CVD steps and/or customs scripts) for out-of-box lifecycle management of that VNF. Today, I don’t think we have this, though we claim “someone” can always write what does not come out of the box.
We have not heard anyone wants an application-specific VNF-M, as in if they have N VNFs, they wanted N separate specific VNF-M to manage them. Could the below requirements be read as the customers requiring VNFs to also have their associated VNF-M rather than VNF-M that are specific to that VNF only?
I have had discussions with several security product PM’s around building the required interfaces and doing the required validation of the security NFV’s onto our own Tail-F offering – lets just say that their drive to assigning resources to deliver this is very low to none existing….their ROI for other features and capabilities is many times bigger then for NFV-I interfaces, tail-f integration, etc.. on their VNF’s…
I do believe that we need to have something like a CVD or VMS – HSS (security specific) alike solution that has a focus on integration of our VNF’s with VNF-I, Tail-F, etc offerings. Funding can be delivered by all relevant BU’s….
I have spoken to Colin K about getting 4 things from the BU:
1. Images that actually boot on OpenStack (without having to unpack the image, remap drivers like consoles, and boot drives)
2. Documentation and Day Zero configs that actually work and turn on NetConf and REST API properly. Stupid crap like version specific methods that change with image updates.
3. On boarding licensing methods that don't require CLI to cut and paste license
4. Native NetConf or NED
5. and sounds like we could use a VNFD that is released to facilitate life cycle management.
Seems common repository in DevNet is the right place to host as we don't want to be trolling through BU specific product pages.
Why not simply asking the VNF BUs to create an ETSI-compatible “VNF package”? I do not think that from NSO perspective a Cisco VNF should be different that any VNF. We have a work-item to create support for automatic “VNF package” onboard as part of the NFVO NSO package.
You can read more about ETSI VNF packages here: http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf
PS: VNF package does not cover day-2 via NETCONF, which of course would be preferred and where we are making progress inside Cisco (I would said security VNFs is today our biggest internal gap for automation)
To Ravi’s earlier point, managing a VNF goes beyond configuring it.
We need to be aware that we will be competing against VNFs from traditional NEVs, which are supported by their own NMS’s that provide full FCAPS.
We have a good C (configuration) implementation with NSO & ESC (and that spills over into F (fault) with auto scaling and healing), but our story of how we provide FCAPS for our own VNFs is muddled.
We are in the generic VNF camp, with a generic NFVM (ESC). So I agree with Roque that we need to push the benefits of ETSI compliance.
But we also need to understand that our weakness is in competing against a VNF that has a full NMS to manage it. (e.g., Ericsson, HP, ALU).
Here’s Ericsson as an example:
They have created virtualized versions of their PNFs (just as we have), and their PNFs are already managed by their NMS. They have also added VNF lifecycle management (VNFM functions) to their NMS. So they have a good FCAPS story for their own VNFs.
(They have also created a generic VNFM so that they also have a story for opaque/generic/multi-vendor VNFs.)
In the physical world, the customer expects to buy the devices and the matching NMS, from the same NEV. So it’s natural for them to want to do the same for VNFs, and our NEV competitors can support that approach.
I only have their marketing material, not the truth, but this is what they claim.
I’ll dig into our other competitors and see what I can find.