cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

App specific VNF-M development

khgrant
Cisco Employee
Cisco Employee

 

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

27 REPLIES 27

khgrant
Cisco Employee
Cisco Employee

 

 

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.

 

khgrant
Cisco Employee
Cisco Employee

 

It looks like your customers want the entire FCAPS functionality for a VNF, similar to a vendor-specific NMS/EMS in the physical world.  

 

 

If this is true, the scope is beyond customising ESC.

 

 

Thanks and regards,

 

Ravi

 

khgrant
Cisco Employee
Cisco Employee

 

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.

 

 

 

Br,

 

Dirk

 

khgrant
Cisco Employee
Cisco Employee

 

About de-risking services engagements it was mentioned before that as a minimum all Cisco VNF’s should be tested against NSO before going GA.

 

Regards,

 

Tony

 

khgrant