Problem Description.

There is an agreement to be able to:

1. Onboard a Network Service Descriptor as defined by ETSI-NFV.
2. To represent the Network service descriptor in the internal modelling.

The way to represent the network service descriptor is an ongoing discussion and there are two proposals.

Option A:  The network service descriptor is represented implicitily using the existing service descriptors.

Option B: The network service descriptor is represented explicity in the modelling.

Approach

Describe both options and cover the following information:

• 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).  In other words, the ETSI NFV community assumed that there were already standards around the BSS/OSS tools (e.g., SM/NM/EM) needed to manage non-virtualized network functions  Service Providers already the tools what was "new" with NFV was

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

An ETSI Network Function Descriptor (VNF or PNF) will capture management requirements only what ETSI refers to as "deployment data

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

2) The

High Level Proposal:  The onboarded ETSI NSD should be represented in ONAP via an existing ONAP object, ONAP object which would obtain for the Service Provider the desired runtime behavior in orchestrating the instantiation of that NS.   My understanding is that the Service Provider, for an NS, would want ONAP to decompose the NS into its component VNFs, home each of those VNFs to the proper cloud instance, and then orchestrate the instantiation of those VNFs in the proper sequence based on the relationships between the VNFs that appear in that NS’s topology template. 

The behavior I have captured above is driven in ONAP from a model of that which we refer to as an ONAP “Service”.   If the desired ONAP runtime behavior for an onboarded NS is something else, then I wish someone would articulate to me what that is and perhaps then we could have a practical as opposed to a philosophical discussion as to the proper mapping.

Option B: information

References

1.  Presentation on implicit representation of the NSD at the dublin architecture F2F: https://wiki.onap.org/download/attachments/41422290/Proposed%20ONAP%20Runtime%20Support%20for%20Network%20Service%20Onboarding%20v4.pptx?version=1&modificationDate=1540903774000&api=v2