...

Orchestration

As a control loop is modeled with TOSCA, it can be orchestrated by a TOSCA orchestrator with suitable support for control loop specific node types. It also can and should be included in a common orchestration hierarchy with the rest of the service. This enables also full ONAP service model including control loops, or just the control loop part, to be executed by a third-party orchestrator. This would be great as there are many non-ONAP orchestrators in the field but they could still share ONAP-style modeling. 

In terms of current ONAP architecture this would mean that the whole service can be instantiated using SO API which delegates control loop typed templates to CLAMP which further delegates policies to Policy and dcae entities to DCAE. This would allow fixing the current problem that services and their control loops do not have common LCM, so they need to be instantiated, terminated and everything separately. In this model for example adding a control loop to a running service will still be possible, but it will be done by creating a new version of the service model and upgrading to it. 

The example above shows control loops attached to the service level, but from TOSCA modeling or orchestration point of view it can as well be attached to VNF level, attach it to another control loop or anything as well. Actually figuring out the details of these less familiar cases will probably still take a long time, but having a place in them in the models enables smooth extension roadmap if/when those become valuable enough.