|5 mins||General Administrative & Status||Karthik Sethuraman|
- Next TAPI call: Next week
- Jan 29 - MEF Q1, but we will have the call
| 15 mins|| Equipment Model|
- Nigel to get a pruned version of the Core Eqpt model for TAPI and commit it into Github
- Will use Martin's tool to migrate to latest eclipse (2018-09)
- use OpenModelProfile 0.2.14
|5 mins||Resilence Updates||Andrea Mazzini|
- Resilience Notes from previous call
- All changes agreed.
- Agreed that ResilienceConstraint class needs a review, as some attributes appear "states" rather than "config" ones.
- Stephane proposes to collect all changes in a dedicated contribution. Andrea will consider this, including more items for discussion at next f2f meeting.
- OK for now, for the task to be marked complete, needs additional use cases (from IETF-CCAMP & OIF) and everything to be documented properly
|15 mins||OAM Updates||Andrea Mazzini|
- TAPI OAM: OamServicePoint, new boolean attribute "isMip"
- TAPI Ethernet: Defined Ethernet specific extensions of OamService and OamServicePoint
- TAPI Ethernet: Removed "Pm" prefix from both Current and History Data classes.
- Started discussion on how to model the results of on-demand jobs and FM jobs (Link Trace, Loopback, Test). Today TAPI reuses for all the Current and History Data. Discussion not completed due to end of the time.
- MEP UP/DOWN
- limited conversation due to lack of ITU-T folks on the call due to an SG15-Q14 F2F
- No comments on Andrea's justification
|15 mins||Photonic Model|
- From previous meeting notes
- Option 1: Only model MCAssembly NEP, CEP & Connection
- The individual MC properties are modeled as locally composed ListElements
- Option 2: Only model the MC NEP, CEP & Connection
- The fact that NEPs/CEPs/Connections are part of an MCAssembly is captured via an groupId property such that entities belonging to the same assembly will have the same groupId
- Option 3: Model both MCAssembly & MC NEPs/CEPs/Connections as first class entities (with their own UUIDs) - current TAPI 2.1 approach
- An MCAssembly NEP/CEP/Connection aggregates references (pointers) to the MC NEPs/CEPs/Connections
- In case of an MCAssembly of one MC, explicitly providing MCAssembly NEP/CEP/Connection is optional since the MCAssembly NEP/CEP/Connection currently have no explicitly defined photonic properties (other than aggregation of part-references).
- This can change if we do define some useful photonic properties in MCAssembly NEP/CEP/Connection
- Agreed to keep option 3 with following modification
- Change the relationship between MediaChannelAssembly (Group) and MediaChannel (Part) entities (NEP, CEP & Connection) to composition from the current aggregation
- this would be keeping in line with the stronger lifecycle dependency between the Group and Part.