Skip to end of metadata
Go to start of metadata


15 January 2019



  • Administrative
  • LLDP Support
  • 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
30 minsLLDP SupportBernd Zeuner

Agreed - for the time being - to go forward with Proposal 3 and check how MEF has modelled LLDP.

Andrea: note that Proposal 3 implies the separate provisioning of MEG and MEP/MIPs, for further analysis.

30 minsResilience UpdatesAndrea Mazzini
    • 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.
30 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.
20 minsPhotonic Model

Nigel Davis

Stephane St-Laurent

Italo Busi

  • Not discussed.
  • 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
  • Continue the discussion on modelling of the MediaChannelAssembly (Group) and MediaChannel (Part) entities (NEP, CEP & Connection)

Action Items