Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

Agreed Items & Priority

  • Below the list of the agreed items and related priority.
  • An item is blocking when its resolution is necessary precondition for the delivery.

TAPI 2.1.3 and RIA 1.1

  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (solved)
  2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs (solved)
  3. Alarm / TCA notification (solved - work ongoing on probable cause list)
    1. Subscription
    2. Notification contents
      • Probable Causes / Elementary alarms (e.g. ITU-T cZZZ fault causes), including TCA PM Parameters
  4. OTS and OMS model (solved)
  5. Path Computation Use Cases (blocking)

TAPI 2.3/2.4 and RIA 1.2

  1. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (solved)
    1. ODU OAM
    2. Photonic OAM
    3. TCA provisioning
  2. Physical impairments (not blocking)
    • OFC is augmenting TAPI Link, others the AbstractStrand.
    • Type of amplifier, fibre attenuation, etc.
  3. Photonic model capability (not blocking)
  4. Lifecycle management of ConnectivityService at every layer, necessary to identify UCs (not blocking)
    • Lifecycle management of single ConnectivityService, necessary to identify UCs
  5. 3R (not blocking)
  6. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU (not blocking)
  7. RESTCONF Response codes for use cases (not blocking)
  8. TAPI OAS, action points to be assigned (not blocking)
  9. Routing Constraints (not blocking)
  10. Physical Route (not blocking)

Discussion items

5 minsAdministrative

All



Review of TR-547 1.1: Tentative scheduling of 2 hours calls for Oct. 4, 6, 7.

  • Invited Ramon, Nigel, Ronald, Pedro, Arturo. Please others interested to contact Andrea.


TAPI weeky call

Preliminary agenda:

  • Continue the review of TAPI 2.3.1 pre-release (Check the upgrades agreed last week)
  • Jonathan Sadler: selection of security suites candidate for TAPI RIA
  • AccessPort/connectorPin is read-only, check whether the object keys of ConnectorPinAddress are necessary
  • Continue the “GNPy/CCAMP – TAPI alignment” activity
10 minsLeafref usageRamon Casellas 

Ramon Casellas informs that there are complaints concerning the TAPI usage of UUID references instead of leafref.

  • Karthik Sethuraman clarifies that - through manual editing - we are adding all leafref statement not automatically generated by the uml2yang tool.
  • Andrea Mazzini will check TapiPathComputation TopologyConstraint object, which still have include/excludePath with UUID type.
60 mins

Update on TAPI 2.3.1 Pre-release

All

Andrea Mazzini shows the TAPI models updated according to the the agreements of last week:

  • TapiStreaming is moved at the core of the model, like TapiNotification.
  • TapiStreaming has been disaggregated: Each technology agnostic module now specifies its own augments to Streaming (and Notification), e.g. TapiTopology:

Ramon Casellas suggests to clarify in the comments that AlarmTca and AlarmInfo (TapiFm) has been deprecated in favor of DetectedCondition augment.

  • In general, a deprecated item shall include in its comment the deprecation rationale and possible replacement.

Andrea Mazzini shows the tapi-topology and tapi-connectivity TREE modules.

  • Discussion on notification/streaming of local classes, i.e. "TAPI entities that are ancillary of first class entities, i.e. their ID is not expected to be globally unique", e.g. the CSEPs of a ConnectivityService.
  • Agreed that the EventNotification signal shall include two additional attributes:
    • targetLocalIdentifier
    • targetLocalObjectType
  • To allow unambiguous identification of local classes. For example, in case of a notification regarding a CSEP instance, the EventNotification attributes will specify:
    • targetObjectType = ConnectivityService
    • targetObjectIdentifier = UUID of the ConnectivityService instance, parent of the CSEP
    • targetLocalObjectType = CSEP
    • targetLocalIdentifier = local ID of the CSEP
  • Agreed that only global classes and their first level local classes can be independently notified/streamed.
  • Agreed that the depth of the information included in the notification/streaming is an implementation agreement. The model foresees full depth.
10 mins2.4 delivery, priority of work itemsRamon Casellas 

Ramon Casellas proposes to prioritize the following items for TAPI 2.4:

  • Physical Route management
  • Additional Use Cases regarding optical characteristics of UNI/Client (DSR) NEPs.
    • Unwrap the TAPI stack for optical layer characteristics, e.g. ingress/egress power levels.
    • Only monitoring, no provisioning.
10 mins

Presentation of otcc2020.ND.013_Tapi-NotesOn2.4.pptx

Nigel Davis 

Nigel Davis briefly presents otcc2020.ND.013_Tapi-NotesOn2.4.pptx contribution, where most of the items are already solved.

20 mins

Loopback Use case 17e Loopback Provisioning.docx

Ronald Zabaleta

Ronald presents Use case 17e Loopback Provisioning.docx

  • Facility and Terminal Loopback on Connection End Points, technology agnostic.
  • After a brief discussion the contribution is agreed, Andrea Mazzini will update TAPI 2.3.1 accordingly.
    • The provisioning of loopback on NEPs ("port" loopback) is postponed.
15 mins“GNPy/CCAMP – TAPI alignment” activity

Andrea Mazzini shows some updated slides from otcc2021.AM.001_TAPI-GNPy-extensions.pptx (not yet published).

  • Agreed to review the optical impairment parameters, to distinguish the:
    • Parameters describing capability
    • Parameters describing actual values
    • Parameters which can be centralized in profiles
  • Brief discussion on generic profile mechanism, agreed that the generic Profile object will be a composition of TapiContext.
  • Avoid breaking backward compatibility in 2.4 - i.e. the profile usage will be an additional alternative feature.