Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • Pre-release v2.3.1
    • Review of last pull request 518
  • 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

All



Review of TR-547 1.1: scheduling of 1 hour call for Nov. 10, and 2.5 hours for Nov 11.
Calls will tentatively restart on December 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)
      • Plan is delivery on early December.
    • TR-548 1.0 (RIA for Streaming)
      • Nigel Davis will send a copy to Arturo for final approval.
    • TR-512 v1.5 (Core IM)


TAPI weeky call

Preliminary agenda:

  • Consolidation of TAPI 2.3.1 release
  • Continue the “GNPy/CCAMP – TAPI alignment” activity
40 min

Review of last pull request 518

All

Andrea Mazzini shows the updates of pull request 518

  • Discussion on Attribute Value Change notification
    • Ramon Casellas shows RFC 8072 - YANG Patch Media Type
      • Abstract: This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language.

    • Agreed that is an interesting specification of a YANG meta-model for HTTP Patch implementation, but further analysis is necessary to understand whether applicable also to the notification of "changes".
    • Confirmed the RIA 1.1 specification of attribute value change format, based on JSON object reflecting the changes of the target object as per JSON-PATCH RFC6902.
    • Agreed the following updates to the TapiNotification model:
      1. ObjectNotification class, delete the objectContent attribute, because 1) for bkw compatibility the 2.1.3 Notification model is still available in 2.3.x, 2) the content of the object is formally modeled by the augmentations of EventNotification and streaming LogRecordBody.
      2. ObjectNotification class, change the type of changedAttributes attribute to simple string (for which the JSON-PATCH RFC6902 format is prescribed by the RIA 1.1)
        • All, please check the encoding of JSON-PATCH into a YANG string (escape sequences, etc.)
        • Post meeting note: Ramon Casellas clarified that the JSON object with the JSON-PATCH MUST be escaped for the " becoming \"
      3. Rename ObjectNotification class into AttributeValueChange class.
    • For further analysis:
      • The translation of UML "Cond" stereotype of abstractions into YANG "when" statement of augments.
      • How to specify more complex "when" expressions, e.g. the AND of two values.
  • require-instance statement (see 2021-11-02 TAPI Meeting Notes) a possible comment could be:
    • "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. Furthermore a referenced instance of a Connection may be deleted by the TAPI Server, leaving a dangling reference. Implementations shall deal with this case."


15ExtendedComposite vs. StrictComposite

Andrea Mazzini shows the list of all ExtendedComposite stereotypes. In all cases are related to "packages":

  • capacity pac
  • state pac
  • termination pac
  • cost pac
  • risk pac
  • timing pac
  • integrity pac
  • transition pac
  • validation pac

but in one case, the ControlHasParameters, where SwitchControl includes the ResilienceConstraint class:

Agreed to change only this association to StrictComposite, similarly to the association between ConnectivityService and ResilienceConstraint.

30

Review of Physical Route draft model

All

Andrea Mazzini shows the TapiEquipment model updates:

The model is agreed.

  • Agreed that a PhysicalRoute may be composed by only one AccessPort. Ramon Casellas at this early stage it is preferable to avoid stricter constraints. The model may be further refined once the related RIA UC will be designed.
  • Nigel Davis clarifies that the PhysicalRoute is a description of the physical route of the Connection. More Connections may share the same list of AccessPoints.