cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
534
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

 

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

 

khgrant
Cisco Employee
Cisco Employee

 

To augment Scott’s message, we’d also want the thing that disappears or whatever controls the scaling tell the management or controller function that this thing is disappearing by intent (e.g. some sort of sign-off message) and not due to some problem (e.g. some dying-gasp indication or sudden silence condition).

 

 

So, it takes updates to both, the management or controller function to automate starting and stopping management of things and the proper triggers to differentiate between intentional and unintentional change.

 

 

Thanks!

 

Dieter.

 

khgrant
Cisco Employee
Cisco Employee

 

Good comments.  Those NMSs that have been extended to have VNF lifecycle management (e.g., Ericsson):  Does anybody know if they now recognize scaling events?

 

If not that would be a good piece of FUD.

 

khgrant
Cisco Employee
Cisco Employee

 

Interesting,  I could certainly see dedicating a VNF-M to a data center or maybe LoB building services on VIM in a DC, but I never considered the case of an VNF-M per service type.

sw

 

khgrant
Cisco Employee
Cisco Employee

 

Ian/Roque points are very much valid. What customer( either SP or SMB) would like to do is to provide “ Platform as s Service” which will provide the complete business solution.  We have to look at our competitor’s solution to match it.  Do we have any GAP analysis report ?

 

 

Regards,

 

Raja

 

khgrant
Cisco Employee
Cisco Employee

 

Hi Ian,

 

 

I would be careful with this FUD since our NFVO also doesn’t handle scaling events from ESC (yet).... Of course you can develop a service with NSO/ESC which does.

 

 

Regards,

 

Gabor

 

khgrant
Cisco Employee
Cisco Employee

 

 

Interesting take away after reading RFP requirements is that looks like industry made the whole circle on NFV

 

Fact, that they’re asking for embedded VNF manager is making me think that they’re willing to trade in potential vendor lock-in for the speed of deployment – which from business perspective make a lot of sense. Customers realized that open system provide a value when they come along with rich content – but if you need content – it means that you’re not willing to create it yourself. In such case there’s no different between proprietary and open solution. Then why bother? Just a thought

 

We’ll see SP’s who have very strong development workshops like AT&T (developing ECOMP) – but most of SP’s want just a solution. If they do not have relevant skillset & finding to leverage open platforms – they will buy at the end what comes with the content (even if that content may not be fully open) – even if they ask in RFP for “everything open, any-to-any, like-for-like”. After few cycles, they’re going to realize that it comes at a price and if you want to move fast – you need solution that delivers business outcome first place rather than kick-ass open architecture

 

 

Another thought is that Openstack is becoming more & more embedded system and there’s little room for Openstack “pure play”. And ask from that RFP for embedded VIM is good proof point.

 

 

Sebastian

 

 

khgrant
Cisco Employee
Cisco Employee

 

 

Yep, I think we're at a bifurcation point right now. Trouble for the single-vendor solution is that it misses the value proposition of NFV (capex, opex, agility) and maintains the SI-heavy and proprietary nature of current networks. So I'd even venture to say that this will significantly delay virtualization of networking assets in general.

 

khgrant
Cisco Employee
Cisco Employee

 

I think we should as well consider that many Operators are not ready to move to E2E NFV architecture, that’s why they will start slowly with this move. Sitting on the other side of the table we will see then that one of the major obstacles/ challenges that the operators have is the limited in-house know-how and expertise in this new technology and this is one of the reasons on why to hire one vendor for their needed NFV domain. Have seen this in a couple of the accounts.

 

 

Regards,

 

Mohammed

 

khgrant
Cisco Employee
Cisco Employee

 

Yep, I think we're at a bifurcation point right now. Trouble for the single-vendor solution is that it misses the value proposition of NFV (capex, opex, agility) and maintains the SI-heavy and proprietary nature of current networks.

 

 

  1. Indeed. Yet, the trend among mobile SPs is to go with virtualized mobility solutions from the same/single vendor that was majorly incumbent. Primarily due to migration risk and an “outcome” based migration commercial offer from the incumbents (as Jeff pointed out in another thread).

 



Cheers,

 

Rajiv Asati

 

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: