Date

Attendees

Goals

Discussion items

5 minsAdministrative
  • Next F2F TAPI meeting: Virtual Meeting to be planned
  • Andrea Mazzini not available June 20 - July 5

20 mins

Check consolidation of TR-5XX.1-TAPI v2.1.3 Reference Implementation_v0.11.docx

Arturo Mayoral considers the 0.11 version consolidated from technical perspective. Now there are the following last things:

  1. Consolidation of 2.1.3 version (see below the dedicated item)
  2. Formalization of TR-xxx delivery in ONF, agreed that:
    1. The Reference Implementation Agreement (RIA) can be published immediately as "info" at https://www.opennetworking.org/software-defined-standards/informational/ (no need for ONF Board approval)
    2. TR (and not TS) is our target (see https://www.opennetworking.org/software-defined-standards/overview/), it is then necessary the ONF Board approval
10 mins

Nigel Davis recalls that TR-5XX.Y-TAPI_v2.1.3_ReferenceImplementation-Streaming_v0.1.docx has been distributed on June 4.

  • Considering that the scope is 2.1.3 version, we need to review it as soon as possible.
  • Nigel Davis will commit TapiStreaming to correct some typos found in UML comments (UML plus YANG, TREE and OAS).
60 mins

Review of 2.1.3 RC2 enhancements (#486)

Andrea Mazzinishows the Papyrus diagram of Photonic model (ServiceSpec), updated according to the agreements of 2020-05-04 / 08 TAPI Virtual Meeting Agenda and Notes, Wed 6/P3:

  • Summary of agreements:
    1. MediaChannelConfigPac, set spectrum attribute as optional [0..1]
    2. MediaChannelConfigPac, keep the [1..*] with MediaChannelAConnectivityServiceEndPointSpec to allow the configuration of power properties (PowerManagementConfigPac) even in case of no spectrum specified, i.e. "empty" MediaChannelConfigPac.
    3. Agreed that 2.1.3 will support either input MC/OTSiMC bandwidth/capacity or spectrum for the MCA/OTSiMCA (*) ConnectivityService provisioning.
    4. Update the Reference Implementation, indicating the deprecated classes (OtsiConnectivityServiceEndPointSpec, MediaChannelConnectivityServiceEndPointSpec) and adding the new ones (OtsiAConnectivityServiceEndPointSpec, MediaChannelAConnectivityServiceEndPointSpec)
    5. Track the agreed descriptions in the UML comments of OTSi/MC classes/attributes (e.g. the "full delegation" case)
    6. Solve the abstraction name clash by renaming the "old" abstraction Csep-OtsiConnectivityServiceEndPointSpec. This will not break the backward compatibility.
    7. Select option 1, i.e. for the provisioning of OTSiMCA ConnectivityService reuse the MediaChannelAConnectivityServiceEndPointSpec, leveraging the Layer Protocol Qualifier of CSEP (*) and the CSEPHasServerCSEP recursive association in case of combined provisioning:

(*) Arturo Mayoral recalls the agreement that assembly related Layer Protocol Qualifiers (OTSiA, MCA, OTSiMCA) are not used, as the assembly is modeled through associations between objects.

  • Andrea Mazzinito perform agreed modifications to 2.1.3, produce YANG and TREE modules including them in the Github commit
  • Arturo Mayoral to help for OAS (OpenAPI Specifications) generation
  • Arturo Mayoral to update the RIA
10 minsReview of 2.3/NMR enhancements (#487)

Andrea Mazziniprovides a summary of #487 request:

  1. TapiOdu: OduOamService augments OamService, to provision MEG level
  2. TapiOdu: added ODU CSEP StrictComposite stereotype
  3. TapiConnectivity: Alignment to 2.1.3 - new ResilienceRoutePac class, with attributes:
    • priority (integer)
    • routeState (yes/no/unknown)
  4. TapiConnectivity: Removed Layer Protocol Name from ConnectivityService
  5. TapiConnectivity/Oam/Topology/PathComputation/VirtualNetwork: Restored inheritance to global class
15 mins

Discuss work plan with TAPI, in particular for T35 and T41

(see OIMT Virtual Face to Face Week of April 13)

T35: introduction of LTP port (not backward compatible)

  • Karthik Sethuraman asks whether the port to port relationship (e.g. Link port with LTP port) is similar to an association class.
    • TMF is using the association class concept in its defined OAS.
  • Nigel Davis when the ports are not linked they are anyway present to model their potential for binding.
  • Karthik Sethuraman and¬†Nigel Davis agree that the port can be modeled as a specification class, considering that e.g. the port role must be extensible.

Agreed that more discussion is necessary but currently no impacts are expected on TAPI.

T41: Identity Model (not backward compatible)

  • Nigel Davis we need to agree an identification strategy
    • In TAPI we have both UUID and Local Id, further discussion is necessary.