1. Pages
2. …
3. Open Transport Configuration and Control Home
4. TAPI
5. TAPI Call-in Details and Notes

2021-11-02 TAPI Meeting Notes

All

• 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)
    

09 Nov 2021 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

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.