Skip to end of metadata
Go to start of metadata




  • Proceed on 2.1.3 version freeze, tentative target March 20: review of modifications and open issues
  • OTSiMCA/MCA CSEP attributes
  • Multi-layer model / capabilities: at least in the scope of TR-5XX.1-TAPI v2.1.2 Reference Implementation
  • Preparation of May f2f agenda

Discussion items

5 minsAdministrative
  • Next F2F TAPI meeting, hosted by Telefonica/Madrid:
    • -  
    • This will be very likely a virtual meeting, agreed to reserve anyway the week.

  • Call slot assignment: last week we were preempted by another ONF meeting overlapping last scheduled hour
    • ONF TAPI Call is scheduled by ONF admin from 3pm to 5pm CET
    • easonably we can ask to extend to four hours - with option for two additional hours "on demand".
    • Issue is temporary solved by ODTN project moving its call to Monday

  • TAPI Call: 3 hours, note that US is in daylight saving time, call will start at 2pm CET 
    • Proceed on 2.1.3 version freeze, tentative target March end: review of modifications and open issues
    • Bulk retrieval
    • Multi-layer model / capabilities: at least in the scope of TR-5XX.1-TAPI v2.1.2 Reference Implementation
    • OTSiMCA/MCA CSEP attributes
    • Preparation of May f2f agenda
20 mins

Node Rule Group

Nigel Davis

Nigel Davis presents otcc2020.ND.007_TAPI-onf2016.296_MwdFdCapability.ppt

  • This document includes extracts from onf2016.296 as well as newer material
    • The material from .296 is on ONF format slides and the new material on blank background slides
  • Much of the material from .296 was incorporated in TR-512.7 and TR-512.A.10 V1.4
  • Observation: Several key properties, recognised as necessary to describe common cases in .296, are missing from the TAPI Node Rule
  • Proposal: That these properties be added to TAPI 2.3
  • Note: At the time .296 was produced some of the properties in the FD spec model had not been finalized, however, by the time V1.4 had been released most of those properties had full type definition

Below the modification proposal, in green font the added items:

  • ConnectionSpec: an example could be the "drop and continue" connection and similar macro-connections for complex protection schemes (ring interworking).

  • Nigel Davis will check currently defined port role of CEP to verify if and what could be reused.

Example of forwarding rules (Core IM TR-512.A.10 V1.4):

20 minsTAPI Versions

TAPI versions, agreed the following scheme (otcc2020.AMLL.001_tapi-version-evolution.pptx by Arturo Mayoral):

  • Two maintenance streams, where feature parity will be assured:
    • 2.1.x, with 2.1.3 (end of March) and 2.1.4 for OAM (and bug fixing). Ideally 2.1.4 will close the 2.1.x stream.
    • Edge, leading to 3.0
  • Note: 3.0 is essentially 2.3 plus the alignment to IETF Topology (RFC 8345), which is required by ODTN/GMPY project.
150 minsTAPI 2.1.3 modifications

Andrea Mazzini presents otcc2020.AM.002_TAPI_2.1.3_Enhancements.pptx

  • Summary of agreements (see the presentation for further details):
    1. Agreed to add new qualifiers OTSiMC/A, MC/A and tag as deprecate existing NMC/A, SMC/A qualifiers
      • Malcolm Betts clarifies that ITU-T NMC is different wrt TAPI OTSiMC, i.e.
        • NMC defines the slot exactly occupied by signal, while OTSiMC could be wider
        • NMC can end within an equipment (O/E/O), OTSiMC always ends on a connector.
    2. Agreed to add ONE_PLUS_ONE_PROTECTION_WITH_PRE_COMPUTED_RESTORATION to 2.1.3 ProtectionType

    3. Agreed clarifications to the comment of PortDirection type
    4. Agreed enhancements on ConnectorPinAddress type
    5. OduCommonPac:
      • oduRate is specified in Kbits/s
      • oduRateTolerance is the positive value (100 for ±100 ppm)
    6. RoutingConstraint class, add:
      1. maxAllowedCost {value or priority}
      2. maxAllowedHops {value or priority}
      3. maxAllowedDelay {value or priority}
    7. Resiliency, add new ResilienceRoutePac class, with attributes:
      1. priority (integer)
      2. isCurrent (yes/no/unknown)
    8. Resiliency, consider ordering of CEPs in Route, at least in case of simple p2p routes.
  • Items postponed to next call:
    1. Equipment model enhancements regarding slot/sub-slot description
    2. Multi-Layer Capabilities
  • Other notes:
    • Clarified that a Connection can support more Links, in case there is separation of layer qualifiers (e.g. SDH VC3 and VC12 Links supported by a VC4 trail)
    • TR-5XX.1-TAPI v2.1.2 Reference Implementation_v0.5.docx  introduces INVENTORY_ID:
      • Confirmed that is a short term solution for functional to physical mappings, complementary wrt Equipment model.
      • Agreed that the distribution of otherwise centralized information leads to issues like several notifications in case of NE name change, one event per each NEP referring to the NE.
      • Agreed that INVENTORY_ID can be deprecated once Equipment model is well integrated in the systems.