...

• Show how it works for a particular use cases.  the vCPE use cases is a good approach.
• Cover the following:
  • Model representation (Cover E2E service, NS, xNF): 
    • Onboard and defined model
    • Dynamic model in AAI 
  • Onboarding
  • Distribution from SDC to the rest
  • Service instantiation 

Option A: information

Assumptions:

...

1. Management of the application-specific functionality of a VNF is envisioned by ETSI NFV as being handled by OSS/BSS that are considered as SM/NM/EM, and outside of the scope of ETSI NFVO and VNFM functionality.  ETSI NFV is currently silent about how such application level management is to be performed for a given VNF.  This can be seen by the lack of specification of the EM to VNF interactions in Fig 5-1 below, as well as in the delegation of application configuration to the EM in the highlighted portions of the figure labeled B.3.2.2 below.  (Figures taken from ETSI GS NFV-MAN 001 V1.1.1, 2014-12). 

...

Image Added

Image Added

In other words, it seems that the ETSI NFV community took the perspective that there were already well-established systems, precedence and standards around the BSS/OSS tools (e.g., SM/NM/EM) needed to manage traditional Network Functions (i.e., PNFs), and the job of ETSI NFV therefore was to put standards around that which was new: how to instantiate and managed "Virtualized" Network Functions to the point that they can look to the established systems (SM/NM/EM) indistinguishable from "traditional Network Functions".

Image Removed

Image Removed

...

1. Therefore, in the context of Figure B.3.2.2 above, "deployment specific parameters" should be understood as that subset of VNF configuration data that must be applied in the VNF in order to make it an endpoint capable of being managed by the non-ETSI NFV OSS/BSS/SM/NM/EM. 

...

1. Thus, an ETSI Network Function Descriptor (VNF or PNF)

...

1. would be expected to formally capture only those management requirements for the "deployment aspects" of that Network Function, and not the "application aspects".
2. Similarly, an ETSI Network Service Descriptor would be expected to formally capture only those management requirements for the "deployment aspects" of that Network Service, and not the "application aspects".
3. Certain Service Providers may already have the necessary SM/NM/EM systems in place to manage the "application aspects" of an ETSI NS and associated NFs, and look to ONAP to manage the "deployment aspects" of such a NS and NFs.  Such Service Providers should have the option to have ONAP perform the equivalent functionality that would have been performed by an NFVO/VNFM given that same NSD/NFD collection.  Through the principle of "least astonishment", such a Service Provider would expect to elicit such behavior from ONAP by onboarding the corresponding NDS/NFD collection into SDC without any substantial changes/enhancements made.
4. However, other Service Providers may not have or want to use additional SM/NM/EM systems, but rather look to ONAP to manage the "application aspects" of VNFs and Services.  These Service Providers should have this option as ONAP was envisioned to be able to do just this, such as perform application level configuration of VNFs within the context of their Services, and to perform control loop functionality on application level telemetry.
5. Therefore, if such a Service Provider were to onboard an into ONAP (along with corresponding Network Function Descriptors), and

The ETSI NSD describes a Network Service that is comprised of one or more Network Functions.  E.g., if one were to represent the ONAP vCPE Residential Broadband Use Case, the associated NFs would be the

...