Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • Review TAPI/pull/503
  • Issue 501
  • Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx
    • Table 3: Minimum subset required of TAPI RESTCONF Data API
    • Minor correction on equipment-category.
    • Includes new use cases: 0d, 1g, 1h, 2a, 2b, 2c, 3d, 3e, 3f, 5d, 11a, 11b, 13b, 13c. 16a. 16b
  • Continue on OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning, (blocking, 1)
    • 3R
    • ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UC

Agreed Items & Priority

  • Below the list of the agreed items and related priority for the next TAPI & RIA versions.
    • An item is blocking when its resolution is necessary precondition for the next delivery.
  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (blocking, 1)
    1. 3R
    2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs.
  2. OTS and OMS model (blocking, 2)
  3. Lifecycle management of ConnectivityService at every layer, necessary to identify UCs (blocking, 3)
    1. Lifecycle management of single ConnectivityService, necessary to identify UCs
  4. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (blocking, 4)
    1. ODU OAM
    2. Photonic OAM
    3. TCA provisioning
  5. Elementary alarm (e.g. ITU-T cZZZ fault causes), including TCA related notif), current and history (blocking, 5)
  6. Photonic model capability (blocking, 6)
  7. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU (not blocking)
  8. RESTCONF Response codes for use cases (not blocking)
  9. TAPI OAS, action points to be assigned (not blocking)
  10. Routing Constraints (not blocking)
  11. Physical Route (not blocking)

Discussion items

10 minsAdministrative

TAPI Call: canceled due to MEF 1Q21 meeting

 TAPI Call: 2 hours

  • Review TAPI/pull/503
  • Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx
    • Minor correction on equipment-category.
    • Includes new use cases: 0d, 1g, 1h, 2a, 2b, 2c, 3d, 3e, 3f, 5d, 11a, 11b, 13b, 13c. 16a. 16b
  • Continue on OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning, (blocking, 1)
    • 3R
    • ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UC
5 mins

Review TAPI/pull/503

Karthik Sethuraman

Karthik Sethuraman needs more time, review postponed.

  •  Andrea Mazzini informs that all comments of TapiCommon, TapiTopology, TapiConnectivity, TapiOam, TapiPathComputation and TapiNotification have been propagated to Yang modules. Not yet committed to avoid the overloading of TAPI/pull/503.
90 mins

Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx

  • Table 3: Minimum subset required of TAPI RESTCONF Data API

Long discussion on the pending decision whether YANG list object retrieval will be enforced or not, see also 2020-12-15 TAPI Meeting Notes.

  • Ramon Casellas points out that in Restconf environment the GET on lists is a common, expected capability.
  • Karthik Sethuraman clarifies that if we allow the
    • GET tapi-common:context/service-interface-point/ then becomes necessary to add also the
    • GET /tapi-common:context/service-interface-point?fields=uuid which result is essentially same as
    • GET /tapi-common:context?fields=service-interface-point(uuid)
  • With reference to YANG to OAS tool does not generate GET with potentially multiple replies (#497), Karthik Sethuraman clarifies that these APIs are not generated by choice, because:
    1. In case of XML encoding, a dedicated container is necessary for the multiple replies (GET to retrieve multiple elements are allowed if the encoding is based on JSON).
    2. Possible performance issues, because the whole subtree content is systematically replied.
    3. Same result is obtained by the GET on the parent node, e.g. instead of retrieving the list of NEPs, retrieve the Node with filter on node-edge-point UUID.
  • Andrea Mazzini as a general rule, a Reference Implementation shall avoid any unnecessary variation, to facilitate interoperability. The RIA is anyway not forbidding the implementation of GET list.
  • Ramon Casellas recalls that the GET list is anyway very common.

Eventually agreed to remove from RIA Table 3: Minimum subset required of TAPI RESTCONF Data API the following GET APIs:

  1. /data/tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service/
  2. /data/tapi-common:context/service-interface-point/
  3. /tapi-common:context/tapi-path-computation:path-computation-context/path-comp-service/
  4. /tapi-common:context/tapi-common:context/tapi-notification:notification-context/notif-subscription/
  • Ramon Casellasto add a clarification note in the RIA, explaining the rationale of this choice.
5 mins

Issue 501

Considering the further comments, agreed to remove the "presence" statement from YANG module.