Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2020-12-15 TAPI Meeting Notes
Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • Some clarifications on Restconf/depth and Restconf notification expected contents
  • Issue 501
  • Continue discussion on OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning, (blocking, 1)
    • Review TAPI/pull/503 for OTU/OTSiA and MCA/OTSiMCA model 
    • 3R
    • ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UC

Agred 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

Andrea Mazzini



TAPI Call: 2 hours - tentative considering that we enter in vacation period for many attendees. To be checked the day before.

  • Issue 501
  • 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

Call canceled

Tentative, depends on attendee availability to be checked the day before.

10 minsAnnouncementArturo Mayoral

Arturo Mayoral announces that his collaboration to the TAPI team will end with this year end.

Victor Lopez confirms that Telefonica will continue to contribute to the TAPI project, no change in our priorities.

Ramon Casellas will continue his collaboration in the TAPI project.

All the team is really sorry for Arturo leaving, recognising his fundamental contribution to TAPI development and consolidation.

Thanks to Arturo Mayoral the TAPI project has been successfully developed above and beyond the conceptual model. TR-547 is a milestone which enables really interoperable implementations.

20 minsNew version of TR-547Arturo Mayoral

Arturo Mayoral presents the draft of the new version of TR-547

  • New Use Cases, mainly independent from existing ones.
    • Biggest one is the Alarm Use Case.
  • "Minimum subset required of TAPI RESTCONF Data API" updated with depth filtering requirements.

which are not generated by the tool, see YANG to OAS tool does not generate GET with potentially multiple replies (#497), considering that same result is achievable leveraging field and depth based filtering (e.g. /tapi-common:context/tapi-connectivity:connectivity-context/ shall include in the reply all ConnectivityServices and their CSEPs).

  • Added the Error Codes applicable to the Restoconf responses, to be filled the TAPI error-app-tag column.
  • Underlined that the specification of ConnectivityService lifecycle is essential.
10 minsSome clarifications on Restconf/depthAndrea Mazzini

Andrea Mazzini confirms that the depth filtering can be sistematically applied to any API, but considering that in case of complex data types it may be necessary a full depth to get all values.

  • Ramon Casellas points out that the depth is relative to the node addressed by the query.
20 mins

Restconf Issue 501

All

Andrea Mazzini shows the results of some tests.

module: tapi-common
  +--rw context
     +--rw service-interface-point* [uuid]
  • With “presence”:
module: tapi-common
  +--rw context!
     +--rw service-interface-point* [uuid]
  • Arturo Mayoral to be Restconf compliant, the TAPI client must retrieve the context to validate the "presence" statement. This is an issue in case no filterings are implemented, hence all the TAPI database is retrieved! The client may avoid to get nodes which are positioned high in the tree, but this could nevertheless be an issue if e.g. an attribute is added to the context container.
  • Karthik Sethuraman in TAPI we agreed that for elementary exchange the context instance must be present. The key requirement is that the context must be created by the TAPI server, not by the TAPI client. We may agree to move the "presence" statement from Yang to just documentation. We can document that the context needs to exist and must not be created by the TAPI client.
    • Andrea Mazziniin general we should as much as possible reduce the manual editing of Yang modules.
    • Karthik Sethuraman reminds that we need to manage the "mandatory" statements (specified through OpenModelAttribute/support stereotype). Currently the UML optionality is managed through attribute cardinality [0..1], with no effect on generated Yang.
      • Karthik Sethuramanto review the following text to be added as further comment to issue 501
        • "In TAPI we agreed that for elementary exchange the context instance must be present. The key requirement is that the context instance must be created by the TAPI server, not by the TAPI client. As far as filtering (depth/fields) is anyway necessary for implementation, it seems unclear why all the tree shall be retrieved to fulfil Restconf compliance."
50 mins

Continue discussion on OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning

Andrea Mazzini

Andrea Mazzini presents the updated UML in develop/edge branch, TAPI/pull/503:

  • No objections to the presented model.
  • Nigel Davis, Malcolm Betts confirm that MCA and OTSiMCA shall be replaced resp. by MCG and OTSiMCG, because
    1. ITU-T defines MCA as the monitoring capability only for the OTS and OMS spans/trails.
    2. A Media Channel can be point to multipoint or multipoint to multipoint, hence inherently impossible to associate any OAM feature.
  • Nigel Davis presents a figure with an example of MC "cross connections" within ROADM node which support a variety of MC "top connections".
    1. Agreed that it is a more accurate representation of ROADM filter configuration / bandwidth management.
    2. Agreed that we need to relax the UML recursive association ConnectionHasLowerLevelConnections.
    3. Agreed that in case of unique PCE, the ROADM could be unaware of e2e OTSi routing information, while in case of multiple independent PCEs the ROADM could store the routing info.
    4. Confirmed that the OTSiMC represents the bandwidth portion where an OTSi is expected.