Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • Review the minutes of 2020Q3 TAPI Virtual Meeting Agenda and Notes Oct. 19/20/21 and Nov. 09/10/11
  • Assign the priority to the following major key issues:
    1. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP
    2. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning
    3. 3R
    4. OTS and OMS model
    5. Lifecycle management of ConnectivityService at every layer
    6. Alarm/TCA model
  • Update the scope of versions 2.1.4 and Edge/develop 2.3

Discussion items

10 minsAdministrative

 TAPI Call: 2 hours

  • 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 the schedule of an additional weekly call on Wed, 5-7pm CET, 11am-1pm ET

90 mins

Review the minutes of 2020Q3 TAPI Virtual Meeting Agenda and Notes Oct. 19/20/21 and Nov. 09/10/11

All
  • TAPI OAS
    • Agreed that the depth/fields usage avoids the issue YANG to OAS tool does not generate GET with potentially multiple replies (#497)
      • Nevertheless the generated OAS is not Restconf compliant.
    • Arturo Mayoral considers the depth/fields solution satisfactory concerning documentation, but still not ideal concerning implementation.
    • Arturo Mayoral reminds that the fields filtering does not reduce the number of replied objects/containers, rather selects which of the attributes are reported.
    • Arturo Mayoral indicates that the generated .YAML modules correctly include the whole tree, filtering is to be considered on top of it.
      • Arturo Mayoralwill update the RIA, adding to the "Table 3: Minimum subset required of TAPI RESTCONF Data API" the required depth/fields filterings.
        • Note that the information about depth and fields is already present in the RIA workflow diagrams, see example below:

  • Karthik Sethuraman asks whether we intend to publish the TAPI OAS as normative.
    • After some discussion, considering that the yang2oas tool is still not producing a fully Restconf compliant OAS and to facilitate implementers work (less necessary to read the documentation), it is agreed to split the delivered OAS into two parts:
      1. Normative OAS, the subset of generated OAS which is in the scope of the TR-547 RIA,
      2. Non normative OAS, the whole generated OAS, which could be anyway useful as reference for implementations not following RIA.
  • Confirmed that the two currently open issues do not allow the generation of fully Restconf compliant OAS:
    1. YANG to OAS tool does not generate GET with potentially multiple replies (#497)
    2. Use namespaces ONLY when the parent node is in different module (or is the "first" node) - from RFC 8040 3.5.3 (#32)
  • With reference to Connectivity Service lifecycle (see Virtual Meeting Notes, Tue 20, P2), agreed to rephrase the requirement, below a proposal:
    • The ConnectivityService (CS) provisioning can cause the creation of Top Connections at the server layer(s), aka top-down scenario. A ConnectivityService must be created per each server Top Connection, to allow the editing of all automatically provisioned network layers.
  • All other items of last Virtual Meeting were quickly reviewed, output being the todo list below.
20 mins

The plan

All



  • 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.
    • Agreed to dedicate a weekly call per each item, sequence according to assigned priority.
    • Agreed to schedule an additional, optional call on Wed, in case the Tue discussion needs follow up.
  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)