cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
699
Views
0
Helpful
3
Replies

NED to instantiate 3rd party VNF

bokang
Cisco Employee
Cisco Employee

Hi Team

Could you kindly share your insight if we need NED when customer want to instantiate 3rd party mobility VNF ( MME, SGW, PGW) with NSO and ESC without automation of service configuration ?

customer is OK if they can access the VNF through ssh after VNF is boot up.

and if NED is still required, what's the role of NED to instantiate VNF?

Regards

Bo

1 Accepted Solution

Accepted Solutions

It is not mandatory to specify a NED; the device-type is a presence container.

So it's perfectly fine to skip device-type in the VNFD but please note: In this case you cannot set the "managed" flag in the VNF info/NS info.

View solution in original post

3 Replies 3

Bassamnabil371
Level 1
Level 1

Hello Bo,

The NED is required to enable NSO to communicate with VNFs after instantiation and manage it. Please have a look to "tailf-etsi-rel2-nfvo-esc.yang" and  you will notice that it's mandatory to specify the device-type (which is requiring a NED) during the instantiation

1.png

if you specify a different NED, I think the VNF will be instantiated given that you have all parameters correctly provided, but NSO won't be able to manage or control it.

Don't forget to provide the Day0 configuration to your instance that enable at least communication between VNF and ESC over management port, Otherwise you will have a loop in deployment.

Regards

Bassim

It is not mandatory to specify a NED; the device-type is a presence container.

So it's perfectly fine to skip device-type in the VNFD but please note: In this case you cannot set the "managed" flag in the VNF info/NS info.

I think what you propose maps exactly to the ETSI MANO definition of NFVO. The NFVO is responsible for day-0 configuration only, but not for day-1 or day-n. As Fredrik says, this mode of usage is supported in the NSO NFVO function pack. Of course you are then not taking advantage of NSO's ability to manage the end-to-end service configuration, and to have service configuration connected with your VNF orchestration. This in turn means that if there is a lifecycle event which means that the VNF restarts, then some other system needs to ensure that any day-1+ configuration is re-applied. The beauty of having NSO both as NFVO and as service configurator is that this is all taken care of for you.