Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx
    • New use cases: 0d, 1g, 1h, 2a, 2b, 2c, 3d, 3e, 3f, 5d, 11a, 11b, 13b, 13c, 16a, 16b.
      • Issue of yang2oas tool (POST body)

      • OTU/FEC and related PM Metrics

      • Review of 2.3 agreed modifications

      • Consolidation of Alarm/TCA

      • Link model, agree a general rule

      • Optical Impairments and Topology

Agreed Items & Priority

  • Below the list of the agreed items and related priority.
  • An item is blocking when its resolution is necessary precondition for the delivery.

TAPI 2.1.3 and RIA 1.1

  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (solved)
  2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs (solved)
  3. Alarm / TCA notification (blocking, 1)
    1. Subscription
    2. Notification contents
      • Probable Causes / Elementary alarms (e.g. ITU-T cZZZ fault causes), including TCA PM Parameters
  4. OTS and OMS model (solved)
  5. Path Computation Use Cases (blocking, 2)

TAPI 2.3 and RIA 1.2

  1. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (solved)
    1. ODU OAM
    2. Photonic OAM
    3. TCA provisioning
  2. Physical impairments (not blocking)
    • OFC is augmenting TAPI Link, others the AbstractStrand.
    • Type of amplifier, fibre attenuation, etc.
  3. Photonic model capability (not blocking)
  4. Lifecycle management of ConnectivityService at every layer, necessary to identify UCs (not blocking)
    • Lifecycle management of single ConnectivityService, necessary to identify UCs
  5. 3R (not blocking)
  6. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU (not blocking)
  7. RESTCONF Response codes for use cases (not blocking)
  8. TAPI OAS, action points to be assigned (not blocking)
  9. Routing Constraints (not blocking)
  10. Physical Route (not blocking)

Discussion items

10 minsAdministrative

All



Nigel Davis will set up an additional separate call for clarification regarding TR-548 scope, involving Jack Pugaczewski (MEF and TMF).

  • Nigel Davis had a chat with Jack, who confirmed that TR-548 (on Kafka) is used as reference, for further discussion the level of alignment, also including PM.


  • Delivery plan (State of RIA and 2.3)
    • Andrea Mazzini TAPI 2.3 RC1 - end of next week
    • Ramon Casellas RIA 1.1 - end of next week
      • How to include the alarm spreadsheet in the delivered TR-547 pdf file: by reference to a separate read-only Excel file. For further analysis.


TAPI Call: 2 hours

50 mins

Other Admin

All

Karthik Sethuraman and Nigel Davis are looking at O-RAN.

Karthik Sethuraman is involved in the O-RAN evaluation of TAPI Topology model. So far mostly admin discussion, e.g. how to adopt/formalize usage of TAPI.

  • O-RAN is considering topology not only regarding forwarding. In TAPI the focus is on forwarding and data plane model, while O-RAN is considering also Control Plane aspects.
  • At the bottom the technology is L2/VLAN switching, then the client is L3/IP.
  • In O-RAN seems missing the definition of an overarching architecture, many teams are developing distinct aspects.
  • Noted that O-RAN software is open, while O-RAN standard activity is closed.
  • Nigel Davis in Core IM the Control Node and Processing Construct can be reused for Control Plane aspects.
40 mins

Issue of yang2oas tool (POST body)

All

Andrea Mazzini  presents proposal_tapi_yaml_correction_post_body.docx

Agreed the proposed modification of TapiConnectivity Yaml module.

From:

           - in: "body"
        name: "tapi.connectivity.ConnectivityContext.body-param"
        description: "tapi.connectivity.ConnectivityContext to be added to list"
        required: false
        schema:
          $ref: "#/definitions/tapi.connectivity.ConnectivityContextWrapper"

to

      - in: "body"
        name: "tapi.connectivity.ConnectivityContext.body-param"
        description: "tapi.connectivity.ConnectivityContext to be added to list"
        required: false
        schema:
          $ref: "#/definitions/tapi.connectivity.ConnectivityContext"

Ramon Casellas mentions the name space, it should be:

  • "tapi-connectivity:connectivity-service": [

For further check, as in the Yaml modules the name space is present.

Discussion on the added value of TAPI OAS, recalled that - as stated in release notes:

  • The TAPI YANG models included in this TAPI release (vx.y) are a normative part of the TAPI SDK. 
  • TAPI OAS (OpenAPI Specifications) included in this TAPI release (vx.y) are an informative part of the TAPI SDK.

Ramon Casellas also recalls that the decision to remove "GET on lists" was justified by limits of XML encoding, while with JSON encoding there are no issues.

10 mins

OTU/FEC and related PM Metrics

Andrea Mazzini

Andrea Mazzini proposed to move FEC related parameters either to OTU CEP or OTU MEP.

  • Agreed the OTU MEP, hence the threshold values can be provisioned at Connectivity Service creation, through CSEP augmentation:
    • ConnectivityOamServicePoint - OduOamMepServicePoint - OtuMep

Hing-Kam Lam highlights that ES counter has been deprecated by ITU-T, according to contribution C605 (from Bernd Zeuner to the 3/2014 ITU-T SG15 meeting). The proposal was agreed by Q14/15 and led to the removal of near-end (nES) and far-end ES (fES) in G.874 since its Amendment 1 (8/2015).

  • ES at OTUk and OTUkV:

    • G.798 defines MI_pN/F_EBC for OTUk and OTUkV layers. It would be possible to calculate ES but it is rather likely that ES occurs every second and is therefore as meaningless as for ODUk.

10 mins

Review of 2.3 agreed modifications

Andrea Mazzini

Andrea Mazzini briefly presents TAPI2.3AgreedUpdates.docx

The document collects all agreed modifications to UML and RIA as tracked by TAPI call minutes since July 2020.