Skip to end of metadata
Go to start of metadata




  • Admin
  • Pre-release v2.3.1
    • Resolution of pyang errors
      • the path for connection-uuid is config but refers to a non-config leaf
      • cannot augment with mandatory node
  • 2.4 delivery

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

20 minsAdministrative


Review of TR-547 1.1: scheduling of 2 hours call for Nov. 3, then week 45 no calls to allow Editor to consolidate the draft for publication.
Calls will tentatively restart on week 46 to start the review of RIA version for TAPI 2.3.x

  • Invited Ramon, Nigel, Ronald, Pedro, Arturo. Please others interested to contact Andrea.
  • The revision process has included some Use Cases (e.g. Notification ones) which were never discussed in TAPI calls.
    • To save time, some decisions are taken during the review (specifically the relationship between Restconf and TAPI notification features).

  • Nigel Davis and Andrea Mazzini to check the procedure for the publication of:
    • TR-547 1.1 (RIA)
    • TR-548 1.0 (RIA for Streaming)
    • TR-512 v1.5 (Core IM)

TAPI weeky call

Preliminary agenda:

  • Consolidation of TAPI 2.3.1 release
  • Physical Route
  • Continue discussion on ExtendedComposite vs. StrictComposite, 2.1.3 CS / RoutingConstraint is extended, 2.3 is strict.
  • Continue the “GNPy/CCAMP – TAPI alignment” activity
50 min

Availability of TAPI pre-release v2.3.1

Andrea Mazzini 

Andrea Mazzini shows the TAPI v2.3.1 pyang errors.

  • the path for connection-uuid is config but refers to a non-config leaf
    • Agreed that using the require-instance statement is a workaround to avoid the error message. The conceptual error is not solved, further analysis with YANG experts is needed.
    • For TAPI 2.3.1 version, agreed to use the require-instance statement with a clarifying comment:
    grouping connection-ref {
        leaf connection-uuid {
            type leafref {
                path '/tapi-common:context/tapi-connectivity:connectivity-context/tapi-connectivity:connection/tapi-connectivity:uuid';
                require-instance false;
            description "The require-instance statement is used as a workaround to enable write operation on a data node that refers to a read only list item";
        description "none";

  • cannot augment with mandatory node
    • Agreed that using derived-from-or-self statement (first example below) is better than the direct expression (second example below), considering RFC 8407 section 4.6.2
    augment "/tapi-streaming:stream-record/tapi-streaming:log-record/tapi-streaming:log-record-body" {
        when 'derived-from-or-self(tapi-streaming:record-content, "CONNECTIVITY_OBJECT_TYPE_SWITCH")';
        container switch {
            uses switch;
            description "none";
        description "none";

    augment "/tapi-streaming:stream-record/tapi-streaming:log-record/tapi-streaming:log-record-body" {
        when "tapi-streaming:record-content='CONDITION_DETECTOR'";
        if-feature tapi-streaming;
        container condition-detector {
            uses condition-detector;
            description "none";
        description "none";
  • Agreed that the when statement shall be used not only to avoid pyang errors, but also to strengthen control, e.g. declaring that an ODU specific class can augment only a CEP instance with layer ODU.
  • Agreed to add the notification type also to EventNotification signal.
    • Post meeting note: in version 2.3.1 the NotificationType is an identity, while in 2.1.3 is an enum. In 2.3.1 it is so possible to augment the NotificationType from TapiFm, with the Alarm and TCA entries.
  • Nigel Davis suggests to check the TREE modules generated with require-instance and derived-from-or-self statements.
  • For future consideration to further abstract the notification / stream types, defining create, modify and delete macro types, applicable to both object notification/streaming and event notification/streaming.