Skip to end of metadata
Go to start of metadata




  • Administrative

  • Multi-Layer use case and reference example (Victor/Arturo)

  • Multi-layer model enhancements (Andrea)

Discussion items

10 minsAdministrative
  • Next TAPI Call: Next week
  • TAPI 2.2 Release update

    • Released on April 8, 2019
      • Included items:
        • OAM, Notification Framework updates
          • OAM Job structure refactoring and renaming
          • OAM/Threshold profile
            • Threshold/PM parameter
          • Alarm/TCA linkage to Threshold/PM parameter
        • Equipment inventory model (new feature)
        • Resilience & Routing Constraints fixes/updates
        • Topology Model update
          • Added TopologyAggregatesNEP association
            • The NodeAggregatesNEP association which is supposed to be replaced by above will be kept as deprecated in this release v2.2 and removed in v3.0
        • ETH Technology model updates
          • mainly OAM based on MEF NRM-OAM requirements, review and feedback
        • Photonic model updates
          • mainly power control management & photonic-layer-qualifier labels
        • LLDP defferred to v2.3 or later
      • Includes UML, YANG, Tree files only.
      • OpenAPI & RI will be included in RC2 (not normative)
    • RC2 target May 10th
    • RC3 target May 24th
    • Release target June 7th (2 weeks after RC3)
30mins Multi-Layer use case and reference example
  •  Telefonica contributing their TAPI reference guide that describes use cases and some examples of Topology abstractions and Connectivity implementations.

  • Flat Topology with layer-specific abstracted Nodes

  • Alternate Approach (Layered Topology approach)
60minsMulti-layer model enhancements
  • To be continued next week.....

  • why is it not possible to attach SIPs to NNI NEPPools ?
  • Note: CapacityPac: The CapacityUnit already has photonic-related units (MHz, GHz) to specify bandwidth in terms of spectrum.

  • Supported transitions represents all possible transitions within the Node between the pair of NEPPools

  • These "intermediate" layer NEPs will be needed to support asymmetric cases where some Nodes in the network may not be able to process all the lower layers, especially to support switching at different layers - else the presence/absence of a NEP on a given Node, will be dictated by the capability on the adjacent Node (which might be few hops away when considering the lowest Topology layer)

  • Layer/Rate Transitions between the Nodes is abstracted into a Transitional link

  • Assymetric Connection handoff at the network interfaces - in above case ODU2 at one end and ODU4 at other

  • In above case, If SIPs may to the NEPPool, how to specify which physical port/NEP to use for connectivity?
    • NEPPool should be used only when the selection of physical port can be delegated to controller (there is equivalence between the NEPs in a pool)

To be continued next week.....

Action items