Closed pavellikin closed 7 years ago
Sorry for making a mistake in the previous comment. There are resource model and operations of Path.
Could you please describe in more detail what do you mean? How Path model and operations can help to improve the behavior?
I want to comment your previous message. The behavior will depends from transport controller implementation. It is possible to imagine 2 scenarios:
The path life cycle will depends from transport controller implementation too. Previously calculated paths can be removed automatically every hour for example. Also it looks strange why user can postpone ConnectivityService provisioning after optimal path has been calculated? @RodLU what do you think?
Please keep in mind that Path Computation will not be exercised. As I understand, path is only a history of requested PCRequests and their PCResponse.
@rvilalta Could you please describe in more details what do you mean?
Path Computation will not be exercised
From my understanding the function of path is not the only provide a history of path calculation requests, but also provide a support mechanism for service provisioning. I can assume that PUT/POST/DELETE _pathCompService/{uuid} will trigger _path/{uuid} create/update/delete operation. So, we can manipulate with path and retrieve it. For me it looks logical that we will have a possibility to reference it from ConnectivityService.
@karthik-sethuraman please join :-)
Service provisioning is trigger with ConnectivityService. Path is only for path computation without service provisioning.
From purely ConnectivityService perspective, the include/exclude path parameters can either be computed by the TAPI client based on the Topology exposed by the TAPI provider or could be requested from the TAPI provider via Path Computation API. To support both use cases, we chose to use an LocalClass construct (TeLink) that effectively contains the output of the path computation process (whether computed at the provider or at the client). We could consider adding additional attributes that contain direct reference to the paths computed at the provider/server in the ConnectivityConstraint, but we would still need to support the current attributes (for client computed path)
Fixed by #173
Hi,
I have a question regarding mentioned issue support in TAPI. From current perspective the user should send a path calculation request towards TAPI server firstly. Then, if calculated path satisfy user needs he should send ConnectivityService request towards TAPI server with ConnectivityConstraint.includePath equals to PathComputationService.path. Could you please confirm my understanding is correct?
Why user can`t use previously calculated path Id in ConnectivityService create request?