Skip to end of metadata
Go to start of metadata




  • Administrative
  • Resilience Updates
  • OAM Updates
  • Photonic Model
  • Eqpt Model

Discussion items

5 minsGeneral Administrative & StatusKarthik 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 minsResilence UpdatesAndrea 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 minsOAM UpdatesAndrea 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.
    • 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 minsPhotonic 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.

Action items


1 Comment

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