1. Pages
2. …
3. Open Transport Configuration and Control Home
4. OTCC
5. OTCC Meeting Notes

2020-06-09 TAPI Meeting notes

Andrea Mazzini

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

• 16 Jun 2020 TAPI Call: 3 hours
  • Check 2.1.3 status - target is final delivery by June 19.
    
  • Review of TR-5XX.Y-TAPI_v2.1.3_ReferenceImplementation-Streaming_v0.1.docx
  • ODU OAM continue discussion on Use Cases otcc2020.AMLL.001_TAPI-v2.1.4 new use cases proposal.pptx

Arturo Mayoral

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)
      • Lyndon Ongto assign the proper document number
        
   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
      • Lyndon Ongand Nigel Davis to contact ONF to publish the RIA as TR.

Nigel Davis

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).

Andrea Mazzini

Arturo Mayoral

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

Andrea Mazzini

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

Nigel Davis

Karthik Sethuraman

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.