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 as being 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, but the assumption seems to be that it will be performed by OSS/BSS (e.g., SM/NM) or EM.  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, it seems that the ETSI NFV community took the perspective that there were already well-established systems, precedence and standards around the tools (e.g., BSS/OSS/SM/NM/EM) needed to manage traditional Network Functions (i.e., PNFs), and the need of ETSI NFV 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".

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. 
2. Thus, an ETSI Network Function Descriptor (VNF or PNF) would be expected to formally capture only those management requirements for the "deployment aspects" of that Network Function, and not the "application aspects".
3. 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 management aspects".
4. Certain Service Providers may already have the necessary BSS/OSS/SM/NM/EM systems in place to manage the "application aspects" of an ETSI NS and associated NFs, and look to ONAP only to manage the "deployment aspects" of such a NS and NFs.  Such Service Providers should have the option to have ONAP perform only the equivalent functionality that would be 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 extensions to that information content needing to be entered into SDC.
5. However, other Service Providers may not have or want to leverage BSS/OSS/SM/NM/EM systems for this purpose, 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.  However, because the ETSI Descriptors as currently defined would not be expected to formally contain information as to the application management needs of the NS/NFs, a Service Provider that onboarded such descriptors into SDC would reasonably expect to have to provide substantial additional information content to SDC regarding the "application management aspects" of the "extended" Service and Network Functions.
6. ONAP should support the ETSI construct of "nested Services", such that one ServiceA is composed of another "inner" ServiceB.  ONAP should support this construct irrespective of whether the Service Provider chose to have ONAP manage the "application aspects" of both the "inner" and "outer" Service, just one of the same, or neither.  This affords the Service Provider with maximum flexibility.
7. In addition to this, ONAP should support the ability to support Service nesting patterns such that management of an "inner" Service is delegated to an external manager.  ONAP should support various external manager types, including patterns where the external manager is another ONAP instance (e.g., from a partner Service Provider) or an ETSI NFVO.
8. In order to maintain separation of concerns in such a delegation pattern, ONAP would view an "inner" nested Service as being opaque, delegating all aspects of internal management to the external manager.  For example, ONAP would understand how to interact with the peer external manager to request an instance of such a delegated "inner" Service, and ONAP would know what input parameters must be supplied to the external manager as part of this request.  However, ONAP should not understand whether those input parameters are considered by the external
9. In the case whereby ONAP delegates an "inner" Service to an NFVO,

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