Thanks Srini. We are trying to identify where the ownership of Service Composition capability should lie during E2E Orchestration.
There are three options to choose from (all of them can be applicable on a case by case basis): 1. BSS Accountability: E2E Service Orchestration is performed at the BSS layer via Service Order Manager (SOM). 2. Shared Orchestration Accountability: A new layer, i.e. a composite service domain, above Network Domains to perform E2E Service Orchestration. 3. Network Domain Accountability: Based on the candidate composite service for a product, a Domain takes the role of “Lead Constructor” and perform E2E Service Orchestration. Both Service Creation and Lifecycle Management need to be covered through E2E Service Orchestration. For your option 1 below, I think we can consider the 3rd Party Operational Domain Manager Use case as an example. Regards, Atif From: [email protected] <[email protected]> On Behalf Of Srini Sent: Wednesday, 18 September 2019 2:18 AM To: [email protected]; Husain, Atif <[email protected]> Subject: Re: [onap-discuss] E2E Service Orchestration by ONAP [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. Hi Atif, As far as I know there are no principles defined. But, we did some study on how to integrate domain orchestrators such as “Multi K8S Cluster orchestration” along with other domain orchestrators and also resource orchestrators. There are two ways go about this. 1. A high level service with nested services where nested services handled by various domain orchestrators. 2. A service with resources where resources are handled by domain orchestrators. 3. Of course, combination of both. If you want domain orchestrator to be called from SO/MC, then (2) approach is needed in my view. On (1), I don’t know whether there are any examples. On (2), there are three examples - Multi-Cluster (k8s) orchestration (WIP), Azure Orchestration and AWS Orchestration (AWS is WIP ) In all three examples of (2), each VNF (VF) resource is treated as the self-contained entity. Within Azure/AWS/Multi-Cluster orchestration, they take care of deploying components of VNF in various locations supported by that domain. For example, Azure has lot of sites, but these are not known to the ONAP. Any VNF placement in Azure sties is the job of Azure domain orchestrator. In “Multi-Cluster Orchestration” too, our thinking is similar to Azure and AWS, where it acts domain orchestrator and takes care of placement decisions for workloads within VNF/VF. And let the ONAP (SO/OOF) do the placement decisions across VNFs (in a service). I hope it helps and request others to comment. Thanks Srini From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Husain, Atif Sent: Monday, September 16, 2019 11:03 PM To: [email protected]<mailto:[email protected]> Subject: [onap-discuss] E2E Service Orchestration by ONAP Hi, Are there any principles defined for ONAP related to its use for E2E Service Orchestration across multiple domains? Regards, Atif -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18987): https://lists.onap.org/g/onap-discuss/message/18987 Mute This Topic: https://lists.onap.org/mt/34173460/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
