Date

Attendees

Goals

Discussion items

5 minsAdministrative
  • Next F2F TAPI meeting, Virtual Meeting:
    • -  

  • TAPI Call: 2 hours
    • 2.1.3 version - status update
    • Continue preparation of May Virtual Meeting agenda
15 minsObjectType enumeration

Nigel Davis shows that version v2.1.x and Next Major Release have different models of ObjectType enumeration.

Summary of agreements:

  • v2.1.x:
    • Keep distinct enumerations in TapiStreaming and TapiNotification models.
    • ObjectType of TapiNotification, remove the "EQUIPMENT_OBJECT_TYPE_" prefix from the entries added for equipment classes.
  • For further analysis if and how enhance Next Major Release
15 minsEnumeration vs. Identity

Nigel Davis in case Enumeration type is not extensible without breaking backward compatibility, we need to move to Indentity type, which is a complex one.

Karthik Sethuraman moving Enums to Identities is not backward compatible.

After some checks, Karthik Sethuraman confirms that in Yang 1.1 the Enumeration can be extended without breaking backward compatibility, at the condition of not changing the order of Enumeration entries, because each entry is associated to an integer reflecting the position.

Hence an Enumeration can be extended without breaking backward compatibility by appending new entries at the end.

20 minsOTSiMC and MC

Arturo Mayoral presents some slides with the purpose to clarify which will be the focus of photonic service management.

Agreed that "real" provisioning of filters etc. is a consequence of Media Channel (MC) Service provisioning, while OTSiMC adds details regarding the spectrum portion where the OTSi is expected. Hence it is agreed that in case of simplified scenario, only MC "layer" will be explicitly modeled (below slide was not presented during the call):

In this way the model is simplified while allowing future introduction of the OTSi/MC/A specific monitoring constructs.

70 minsOLP/OMS/3R model clarifications

Arturo Mayoral highlights some slides of otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx



After long discussion agreed that:

  • The above shown model is still the most correct for the representation of transmission functions.
  • Aggregated scenario: agreed that there will be an e2e (transponder to transponder) OTSiA ConnectivityService, which will drive the creation of the various OTSi/OTSiMC Connections.
  • Disaggregated scenario: agreed that there will be an e2e (OLS UNI to UNI) OTSiMCA ConnectivityService (*), which will drive the creation of the various OTSiMC Connections.
    • Additional "client related" parameters are necessary to correctly drive the regeneration function(s) - in analogy with "deep packet inspection":
      • OTSi parameters (there could also be cases of frequency interchange, OT-λ1-3R-λ2-3R-λ1-OT)
      • OTU / HO ODU parameters (monitoring purposes)
    • Jonathan Sadler, this opens the discussion whether the OLS "service" is still OTSiMC, and not OTSi or even an OTU/ODU service.
    • Agreed to postpone the use case combining OLP and 3R.


Agreed the following scenario (*):


(*) in case of simplified scenario, the only layer is MC rather than OTSiMC, see previously discussed item.

10 mins

2.1.3 version freeze


Andrea Mazzini presents the updates to TapiOdu model:

  1. Added "effectiveTimeSlotList" to ODU(Cn) CEP TTP pac
  2. Add “n” of ODUCn ("numberOfOduC") to ODU CEP and CSEP Common pacs

TapiOdu updates agreed and ready to commit (see also related agreements on 2020-03-31 TAPI Meeting notes)

Last commits before 2.1.3 freeze are TapiOdu and TapiStreaming byNigel Davis