cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
533
Views
1
Helpful
27
Replies

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
Cisco Employee
Cisco Employee

 

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?

 

 

Regards

 

 

Khay Kid

 

khgrant
Cisco Employee
Cisco Employee

 

Makes a lot of sense.

 

 

Regards

 

 

Khay Kid

 

khgrant
Cisco Employee
Cisco Employee

 

Violently agreed. Would the TT be interested in driving such an effort?

 

khgrant
Cisco Employee
Cisco Employee

 

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….

 

 

Thanks

 

Stefan

 

khgrant
Cisco Employee
Cisco Employee

 

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.

 

 

Scott

 

khgrant
Cisco Employee
Cisco Employee

 

Hi Scott,

 

 

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

 

 

Regards,

 

Roque

 

 

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)

 

 

 

Roque Gagliano

 

khgrant
Cisco Employee
Cisco Employee

 

You have to address the items in order.  The vWAAS cannot even be booted in Openstack.

 

 

Many BU creating VNF don't care about Openstack

 

 

Reality.  Sad

 

 

Scott

 

khgrant
Cisco Employee
Cisco Employee

 

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).

 

khgrant
Cisco Employee
Cisco Employee

 

Agreed. How much details do we have about alu, ericsson, etc actual fcaps for vnfs?

 

khgrant
Cisco Employee
Cisco Employee

 

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.

 

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: