search

Open-Network-Models-and-Interfaces-ONMI / TAPI

LF ONMI Transport API Repository (TAPI)
https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI/wiki
Apache License 2.0
95 stars 80 forks source link

ConnectivityService provisioning with Path Computation API #141

Closed pavellikin closed 7 years ago

pavellikin commented 7 years ago

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?

RodLU commented 7 years ago

Sorry for making a mistake in the previous comment. There are resource model and operations of Path.

pavellikin commented 7 years ago

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:

  1. The previously calculated Path will be added to create ConnectivityService request as set of Links in ConnectivityConstraint.includePath. In this case we should validate all path links on existence and check that all these links create a full path (addition path computation is not needed).
  2. The previously calculated Path id will be added to create ConnectivityService request. The only check we need to perform that Path is still alive in Transport controller. If Path is removed then error message will be sent to user.

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?

RodLU commented 7 years ago
  1. If you look into the TapiPathComputation.yang file, you will find that the PathComputationService and Path objects are under Context. And there is operation deleteP2PPath to delete a specific Path instance. Which means the computed Paths will be resotred in transport controller certainly and there is a operation can delete them.
  2. Then look into the structure of Path object, will find that Path is mainly comprise by TeLink. And the ConnectivityConstraint.includePath is also Telink. Which means ConnectivityConstraint.includePath equals to Path.Telink. I think these two points make the Path id way possible. But I find it a little diffcult to deal with the interface. Hope @karthik-sethuraman can help.
rvilalta commented 7 years ago

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.

pavellikin commented 7 years ago

@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.

rvilalta commented 7 years ago

@karthik-sethuraman please join :-)

Service provisioning is trigger with ConnectivityService. Path is only for path computation without service provisioning.

karthik-sethuraman commented 7 years ago

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)

karthik-sethuraman commented 7 years ago

Fixed by #173