Path to retrieve _connection from _connectivityService is missing in TapiConnectivity.swagger file

[pavellikin]

According to TAPI, Connection object is a part of ConnectivityService. Here is the ConnectivityService swagger description:

  ConnectivityService:
    description: >-
      The ForwardingConstruct (FC) object class models enabled potential for
      forwarding between two or more LTPs and like the LTP supports any
      transport protocol including all circuit and packet forms.

      At the lowest level of recursion, a FC represents a cross-connection
      within an NE.
    allOf:
      - $ref: '#/definitions/ServiceSpec'
      - properties:
          _connection:
            items:
              type: string
              description: none
              x-path: '/Tapi:Context/Tapi:_connection/Tapi:uuid'
            type: array
          _servicePort:
            items:
              $ref: '#/definitions/ConnectivityServicePort'
            type: array
            description: none
            x-key: localId
          direction:
            enum:
              - BIDIRECTIONAL
              - UNIDIRECTIONAL
              - UNDEFINED_OR_UNKNOWN
            type: string
            description: none
          layerProtocolName:
            enum:
              - OCH
              - ODU
              - ETH
              - MPLS_TP
            type: string
            description: none
          _schedule:
            description: none
            $ref: '#/definitions/TimeRange'
          _state:
            description: none
            $ref: '#/definitions/AdminStatePac'
          _connConstraint:
            description: none
            $ref: '#/definitions/ConnectivityConstraint'

The RPC object GetConnectionDetailsRPCInputSchema has a possibility to request a Connection related to a specific ConnectivityService:

  GetConnectionDetailsRPCInputSchema:
    properties:
      connectionIdOrName:
        type: string
        description: none
      serviceIdOrName:
        type: string
        description: none

Unfortunately the such mechanism is missing in Restconf HTTP paths. It is only possible to collect Connection details independently from ConnectivityService. Could you please add missing HTTP paths to relate Connection and ConnectivityService?

[RodLU]

As far as I know, ConnectivityService and Connection are parallel under Context in T-API. The _connection of ConnectivityService is ref by uuid.

[NikolayKolyada]

As far as I know, ConnectivityService and Connection are parallel under Context in T-API. The _connection of ConnectivityService is ref by uuid.

We see that connection and connectivityService contained in different URL: /config/Context/_connection/{uuid}/ /config/Context/_connectivityService/{uuid}/

And _connection not under _connectivityService. It violates integrity and the uniqueness of requests.

Of course we can get connection uuid from ConnectivityService:

    _connection:
            items:
              type: string
              description: none
              x-path: '/Tapi:Context/Tapi:_connection/Tapi:uuid'
            type: array

and for get connection detail need send request to /config/Context/_connection/{uuid}/ , but we think that it is not correct.

What do you think about it?

[pavellikin]

@RodLU As you may know the only way to create a Connection is to create a ConnectivityService. In other words ConnectivityService produces Connections that represent underlying connectivity. I had a discussion with @karthik-sethuraman regarding this issue and we considered the behavior is a bug. However, the /config/Context/_connection URLs could be kept. According to swagger file all _connection URLs are to be available only through HTTP GET method (read only).

[RodLU]

@burnout171 Agree. But I am afraid that this modification may break the conformance with information model. This issue may not be able to be solved by simplely adding a HTTP path.

[rvilalta]

I am not able to understand the problem. A connectivity service request triggers the creation of a connection, as agreed.

[NikolayKolyada]

@rvilalta , We think that it needs to change HTTP URL for improving the integrity and completeness. We think that it needs to move _connection under _connectivityService. 1) New URL for get Connections: /config/Context/_connectivityService/{service-uuid}/_connection/ 2) New URL for get Connection detail: /config/Context/_connectivityService/{service-uuid}/_connection/{connection-uuid}/

[pavellikin]

@rvilalta The original issue is to add missing URLs to retrieve _connection through its _connectivityService. @NikolayKolyada already give an example of missing URLs.

[karthik-sethuraman]

All,

Apologize for any misinformation from past discussions. The current implementation is consitent as per the containment hierarchy that was discussed/agreed by the TAPI design team during the TAPI IM design few months back.

At a high level TAPI Context holds 2 types of GlobalClass instances (first-class objects identified by uuid): Services and Resources. In general TAPI clients can create Service, delete Service, update Service and retrieve Service. Service represents what a TAPI client has requested from the TAPI provider. In response TAPI provider provisions/creates Resources and allows them to be retrieved by TAPI client.

Now while its certainly possible to scope every Resource (Topology, Path, Connection, Notification) within its corresponding Service, it was decided to decouple them for few reasons (as per my memory):

• Support use cases where applications do not care about resources and are satisfied with service view only
• Support direct access to Resources (e.g. Topology, Notifications, etc) independent of the corresponding Service (e.g. VirtualNetworkService, NotificationService, etc) for resource group queries/filters, etc
• Flatter addressing (global/direct paths) to Resources (e.g. Topology, Notification, Path, Connection, ServiceEndPoint) which allows for specifying inter-resource dependencies/associations without having to specify the triggering Service
• Support easier implementation of augmentation/specification pattern
• Side effect of YANG/RESTConf mapping of the (PassedByValue v/s PassedByReference) discussion

It is certainly possible to counter argue the above points, but since it requires more discussion and group decision and is a major impact change, we should consider this in major TAPI revision only.

[karthik-sethuraman]

Related Issue #132

[karthik-sethuraman]

This issue will be tracked as part of #151 discussion

[amazzini]

This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.