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

 

Hi Ian,

 

 

I would say that our biggest disadvantage today in the NFVO space has to do with add to NSO + ESC  (+ RO ) a generic assurance solution with a single UI to access all of this. I do not believe we could offer generic NMS for vendor-specific technologies. The only place where I have seen it proposed is the packet core.

 

 

If we do include this, on boarding for the assurance piece could be automated via the same process as we discussed before.

 

 

Regards,

 

Roque

 

khgrant
Cisco Employee
Cisco Employee

 

Makes sense.

 

Do you also see resource monitoring and VNF placement as a gap?  This is a function that traditional NMSs (for PNFs) didn’t have to provide, so it would be something that the NEVs would have to add.  I am wondering if they’ve done it.

 

khgrant
Cisco Employee
Cisco Employee

 

Interesting development.

 

 

In the vDNS RFI for KPN we had the chance to ask questions. All questions and all answers are returned to all participants.

 

 

The question below was asked by one of our competitors (i.e. not us). And it reconfirms the fact that KPN is looking for a dedicated VNF-M.

 

And apparently this is also a topic that at least one of our competitors is trying to understand better.

 

 

 

  1. 10. In sec 2.5 it is stated that “KPN expects the DNS solution to come with a VNF manager for the whole DNS portfolio of Supplier.”. Does this mean that KPN prefers to have a dedicated VNFM for the DNS solution that is offered together with the DNS solution?

 

Yes, KPN wants a dedicated VNFM for the DNS solution. Probably still with some API which could be used possibly by some other BSS or OSS.

 



Unfortunately I don't know which competitor asked the question.

 

 



Met vriendelijke groet / With kind regard,
Dirk-Jan van Helmond

khgrant
Cisco Employee
Cisco Employee

 

Given that most EMS/NMS's are dealing with 'ported' appliance code that happens to boot on OpenStack, the typical EMS/NMS expects to always see the entity it's management.  The whole notion of things magically appearing (scale out) and disappearing (scale down) means the EMS/NMS has to ALSO be rewritten to accommodate this type of behavior.

Operations teams hate to see things go RED for a down state when the managed object is supposed to be down.  This really is a new paradigm for the EMS/NMS as well.  Case in point:  The FirePower Management Center will see FirePower Threat Defense systems call in; however, the FMC needs to be provisioned such that the end-point is registered.  You can't magically accept new FTD into the system.  Likewise, if an FTD disappears, you will get an alarm.  There is no notion of 'elastic' scale out/in in FMC.  They will need to code that into the FMC.


Scott

 

</