| Time | Item | Who | Notes |
|---|
| 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
- https://github.com/OpenNetworkingFoundation/TAPI/pull/379
- 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 | - https://github.com/OpenNetworkingFoundation/TAPI/pull/383
- 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.
|
1 Comment
Italo Busi
As outlined in my comments to the January 8 calls, option 3 implies managing OTSiA like SDH VCONC which is known from past experience to be quite complex: 2019-01-08 TAPI Meeting Notes
This complexity was unavoidable with SDH VCONC but can be avoided with OTSiA, as outlined by option 1
I have asked for explanation of some advantages of option 3 and have got any
My understanding is that the meeting has agreed to adopt the most complex solution just for complexity sake with no technical reasons/advantages