Date

Attendees

Goals

Agreed Items & Priority

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: Scheduled 2 hours calls for Sept 3, 6, 9.

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


TAPI weeky call

15 mins

Liaison between TIP and ONF?

Arturo

Arturo clarifies that a liaison between ONF and TIP is already in place.

  • Question is whether we can reuse this broad liaison for more specific work items.
  • Arturo asks about contacts on ONF side, Nigel Davis answers that the issue seems more on TIP side, considering that ONF (and hence OTCC/TAPI) is open to anybody, while TIP is restricted to SPs.
  • Ramon Casellas adds that TIP is organized in working groups and participation fees are foreseen. How to access to TIP MUST minutes, discussions, contributions?
  • Arturo points out that TIP MUST target is to publish specification, Nigel Davis underlines that sometimes being involved in the process is better than relying only on the process conclusions. Arturo replies that so far there is no intention to publish the minutes.
  • Reached a preliminary agreement that TIP could inform ONF about feature priorities, e.g. relying on TR-547 RIA Use Cases.
100 mins

Some notes on v2.3 release

Andrea Mazzini

Andrea Mazzini shows some bugs found in the 2.3 release:

  1. TapiConnectivity: two associations are still in the diagrams
  2. TapiCommon (YANG): missing base CONDITION_NAME from identity PM_PARAMETER_NAME
  3. TapiFm (YANG):  missing base CONDITION_NAME from identity ALARM_CONDITION_NAME
  4. TapiOdu: OtuCsepTtpPac/otuType and OduCsepCommonPac/oduType are redundant wrt the layer protocol qualifier of the augmented CSEP. To be deprecated. OduCommonPac/oduType and OtuTtpPac/otuType are redundant wrt the layer protocol qualifier of the augmented CEP. To be deprecated.
  5. TapiFm: DetectedConditionAugmentsNotification, missing the Specify target reference.
  6. TapiFm: DetectedConditionAugmentsConditionDetector augment is missing.
  7. TapiFm: SimpleDetector, DetectorInfo and PmMetricInfo augment DetectedCondition but target references are missing.
    • Post meeting note: SimpleDetector, DetectorInfo and PmMetricInfo can become conditional packages (composition) of DetectedCondition, to avoid multi-stage augments.
  8. TapiNotification: ObjectNotificationAugmentsEventNotification, missing the Specify target reference.
    • Found post meeting
  9. TapiOam (YANG): grouping oam-job, wrong "min-elements 1" of the "list oam-service-point" (UML is 0..*)
  10. TapiOam: Multiplicities must be changed from 1 to * for OamJobRelatedToCS, OamJobHasCep, CurrentDataOfCep, CurrentDataOfMep, CurrentDataOfMip. Add a comment specifying that at least and exclusively one of CurrentDataOfCep, CurrentDataOfMep, CurrentDataOfMip must be referred by the CurrentData instance.
  11. TapiOam, consider NEP to MEP/MIP relationship, for the monitoring e.g. of NEP to NEP reachability.

Discussion on the specification of complex constraints, like the "an instance of CurrentData must refer to exclusively one of a CEP or MEP or MIP instance. Agreed that formal expressions have a real added value only of related code is automatically generated. Otherwise a comment in natural language is likely easier to be understood.

Agreed to define a TAPI 2.3.1 Pre-release to fix the above listed bugs.

  • Plan is to consolidate a TAPI 2.3.1 Release before end of the month.

Post meeting note: Andrea Mazzini found how to instruct Gendoc to dump also abstractions/augments, see below snapshot. This capability allows a more sistematic review...