Connection Route creation/modification is not fully supported

[arthurMll]

Problem Statement We are currently assesing the feasibility of modification of a connectivity service's path after its creation, but the current models does not fully assess this use case, at least from the Data API model perspective.

Explanation In the current TAPI definition, the Route object within the Connection object is not writable object. Moreover, the Topology Constrains, within the Connectivity Service object, are all defined as non-writable in the model:

        list include-topology {
            uses tapi-topology:topology-ref;
            key 'topology-uuid';
            config false;
            description "none";
        }
        list avoid-topology {
            uses tapi-topology:topology-ref;
            key 'topology-uuid';
            config false;
            description "none";
        }
        list include-path {
            uses tapi-path-computation:path-ref;
            key 'path-uuid';
            config false;
            description "none";
        }
        list exclude-path {
            uses tapi-path-computation:path-ref;
            key 'path-uuid';
            config false;
            description "none";
        }
        list include-link {
            uses tapi-topology:link-ref;
            key 'topology-uuid link-uuid';
            config false;
            description "This is a loose constraint - that is it is unordered and could be a partial list ";
        }
        list exclude-link {
            uses tapi-topology:link-ref;
            key 'topology-uuid link-uuid';
            config false;
            description "none";
        }
        list include-node {
            uses tapi-topology:node-ref;
            key 'topology-uuid node-uuid';
            config false;
            description "This is a loose constraint - that is it is unordered and could be a partial list";
        }
        list exclude-node {
            uses tapi-topology:node-ref;
            key 'topology-uuid node-uuid';
            config false;
            description "none";
        }
        leaf-list preferred-transport-layer {
            type tapi-common:layer-protocol-name;
            config false;
            description "soft constraint requested by client to indicate the layer(s) of transport connection that it prefers to carry the service. This could be same as the service layer or one of the supported server layers";
        }
        description "none";
}

On the other hand, the rpc update-connectivity-service is defined and it allows the modification of all connectivity-service pararameters.

Questions

• Why connectivity-service's topology-constrains objects are not writable in the model?
• Does ONF T-API plans to allow connectivity-service modification only through the Operations API?
• How does the Use Case of defining of an explicit path for a given connectivity service is supported in TAPI?
• Is it through the exclude-path topology constrain? In such case, the planned workflow is to create paths through the Path-Computation API and the reference them when creating the connectivity-service?