...

1. SO will decompose the Service (i.e., the translated NS) into its component VNFs which must be instantiated
2. SO will call OOF, which will perform "homing" to determine cloud instance locations for each such VNF to be instantiated
3. SO will perform the following steps for each VNF, performing cross-VNF orchestration in the proper sequence based on the relationships between the VNFs in that Service's/NS's topology template: 
   1. SO will call a Controller which will make any needed network assignments for that VNF
   2. SO can either:
      1. Call Multi-VIM to request instantiation of that VNF, passing in the corresponding "deployment data" values (i.e., either data values mapped from the input parameters received in the service instantiation request, or mapped from the output of the Controller network assignments interaction), or
      2. Call the SOL003 Adaptor, passing in the corresponding "deployment data" values, and requesting the subtending VNFM to instantiate that VNF.  (For details of this approach see ONAP – ETSI Alignment Proposals in Support of VNF Scaling and SO Plug-in Support for VNFM.)

2.2.2.2 Model

2.2.2.3 Implications/Impacts

2.2.3 ONAP Runtime Processing for an Onboarded Network Service Whereby ONAP Also Manages the "Application Aspects" of that Service

...

Alternative Text: SO will call the  SOL003 Adapter or Application Controller which will configure that VNF as appropriate.

2.2.3.2 Model

2.2.3.3 Implications/Impacts

2.2.4 ONAP Runtime Processing for an Onboarded and "Nested" Network Service the Management of Which is Delegated to an NFVO as an External Manager

...

Note that for the "inner" (Network) Service SO orchestrated only the "assign" and "create" functions, and not the (application level) "configure" of the VNFs that comprise the Network Service.  This is because to ONAP the (externally managed) Network Service is an opaque structure, and ONAP is not aware of the individual VNFs that comprise it.  Only the external manager (in this case the NFVO) is aware of the internal structure of the Network Service, the VNFs that comprise it.  If, however, the application level configuration of the Network Service could be accomplished without ONAP needing to be aware of the internal structure of the Network Service (e.g., if the collection of VNFs which comprise the NS can all be collectively configured through a single configuration API endpoint), then it is perhaps possible that ONAP (the Application Controller) could also perform the application layer configuration function.  Of course this would require that the appropriate model information would have been input into SDC, maintaining the proper abstractions.

2.2.4.2 Model

2.2.4.3 Implications/Impacts 

Alternative Option A: Alternative Option A

(Should this be removed??)

3 Option B: information

3.1 Assumptions

Can refer to above is necessary 

3.2 Proposal

3.2.1 Main proposal

3.2.2 Model

3.3.3 Implications/Impacts 

4 Analysis and comparison

...