...

1. SO will decompose the "outer" Service into its component VNFs and nested Services (including our "inner Service") 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.  For a nested Service that is managed by ONAP itself (i.e., not delegated to an external manager), OOF could be responsible performing homing on the VNFs comprising that nested service in a recursive manner (see Modular Orchestration and Homing of Complex Services and Allotted Resources for more information).  For a nested Service that is managed by an external manager (as is our "inner Service") and hence "opaque" to ONAP, OOF would likely be responsible only for determining the desired location of the "Service Access Point" for that delegated Service.
3. SO will perform the following steps for each VNF and nested Service, performing cross-VNF/nested Service orchestration in the proper sequence based on the relationships between the VNFs/nested Services in that ("outer") Service's topology template: SO processing continues,
1. For each component VNF now homed,
SO will orchestrate in the proper sequence
1. the "outer" Service level flow will spawn a VNF level sub-flow to perform the "assign", "create" and "configure" of that VNF as described above.
2. For each component
 
1. SO will call a Controller which will make any needed network assignments for that VNF
2. SO can either:
SO will decompose
1. "nested" Service that is managed by ONAP itself (as opposed to an external manager), the "outer" Service
(i.e., the translated NS) into its component VNFs which must be instantiated
4. SO will call OOF, which will perform "homing" to determine cloud instance locations for each such VNF to be instantiated
For each such VNF, SO will orchestrate the following in the proper sequence based on the relationships between the VNFs in that Service's/NS's topology template: 
5. SO will call a Controller which will make any needed network assignments for that VNF
SO can either:
1. level flow will spawn a separate Service level sub-flow to orchestrate that "nested" Service, passing in the appropriate modular structure within the homing solution returned by OOF.  This is a recursive pattern in that processing of this Service level sub-flow is another thread clone of that of the "outer" Service, with the exception that decomposition and homing need not be repeated due to the presence of the homing solution provided.  See Modular Orchestration and Homing of Complex Services and Allotted Resources for more information.
2. For each component "nested" (Network) Service that is managed by an external manager, specifically for our "inner" Service, the "outer" Service level flow will spawn a separate sub-flow that will do the following:
1. SO will call a Controller which will make any needed network assignments for that "inner" Service as an opaque structure.  I.e., the Controller will see only that which is externally visible from the inner Service, such as its external connection points.
2. SO will call the SOL005 Adaptor, passing in the corresponding input data values (i.e., either data values mapped from the input parameters received in the "outer" Service's service instantiation request, or mapped from the output of the Controller network assignments interaction).

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.

Option B: information

References

...