Agreed to dedicate one week / 4 days / two hours per day for the review of TR-547: July 5,6,7,9 10-12 CEsT
Next TAPI weeky call - 2 hours
|5 mins||TR-548 delivery||Nigel Davis|
Nigel Davis will set up an additional separate call for clarification regarding TR-548 scope, involving Jack Pugaczewski (MEF and TMF).
Nigel Davis is still working on TR-548, considering also possible developments related to the integration with Fault Management.
|15 mins||Some considerations on TIP MUST|
Arturo Mayoral indicates that TIP discussions continued, MUST will focus on next definition cycle of NBI, specially for:
MUST is evaluating the usage of different standard management interfaces (IETF, ONF, OpenConfig).
Also recalled that MUST is restricted to operators:
Andrea Mazzini in the context of GNPy, have MUST defined Use Cases related to optical path computation?
|10 mins||Some considerations on OTSiA provisioning use cases||Ramon Casellas|
Clarified that TAPI 2.1.3 does not foeresee OTU layer, hence the OTSi/A related use cases do not mention any "digital" provisioning.
For further evaluation if and how update the RIA 1.1 with the "transponder" provisioning scenarios agreed for TAPI 2.3, e.g.
Technical discussion on Integration of Streaming and Fault Management
Nigel Davis presents some alternative solutions for TapiFm data types (AlarmInfo and TcaInfo) to augment TapiStreaming ConditionDetector or LogRecordBody objects.
Nigel Davis shall build a detailed proposal in one week.
Karthik Sethuraman highest priority is adoption. Hence the solution shall not be too much disruptive with respect to TAPI 2.1.3 and in general with respect to consolidated/legacy terminology/concepts.
“asymmetric” provisioning UC – DSR NEP and “OTU” NEP
Andrea Mazzini shows this picture concerning OTU NNI
Agreed that RIA 1.1 - for TAPI 2.1.3 - will not change the current picture (below), as far as TAPI 2.1.3 does not foresee OTUk layer protocol qualifier.
Post meeting note: we agreed that the CSEP of OTN SIP shall be modeled as DSR CSEP.
Use Case 0d – clarification on SAPI/DAPI vs. TxTI/ExT
Andrea Mazzini shows current RIA specification:
We need to clarify the SAPI+DAPI relationship with OTN TxTI and ExTI (see G.798 184.108.40.206 dTIM at the OTS-O, OTSiG-O, OTU, ODUT and ODUP layer).
There are two alternative assumptions:
In the first case, an example would be:
In the second case, an example would be:
In this second case it is necessary to add to the NEP of Domain 1 and to the NEP of Domain 2 the respective remote sapi/dapi info:
We could abandon the SAPI/DAPI terminology and model the NEP PlugId attribute as:
Considering OTN technology: