Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
    • TAPI 2.3 Release – Integration of Streaming and Fault Management
    • Any update on liaison between TIP and ONF?
    • Brief update on tooling @ O-RAN
  • Review of last updates for version 2.3 delivery
  • Delivering RIA 1.1 (ONF TAPI RIA)
    • Selection of UCs which review is necessary for RIA 1.1 delivery, e.g.
      • 0d – clarification on SAPI/DAPI vs. TxTI/ExT
      • 3d - Constrained Provisioning diversity based on SRG / Diverse Routing in SRG failure
      • 5d - Asymmetric service provisioning with 1+1 Protection with Diverse Service Provisioning (eSNCP)
      • ASON related UCs
      • 12a: Pre-calculation of the optimum path
      • 12b: Simultaneous pre-calculation of two disjoint paths
  • Server constraints vs. multiple augment of (distinct) technology specific packages

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 (blocking, 1)
    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, 2)

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: Wed 28, 10:00-12:00 pm CEsT (and tentatively also 29 and 30)

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


TAPI weeky call

10 minsONAP UpdateKarthik Sethuraman

Karthik Sethuraman informs that ONAP side are looking at TAPI for topology model, it it worth that TAPI team tries to attend ONAP.

10 minsO-RAN UpdateNigel Davis

Nigel Davis informs that O-RAN specifications are centered on Papyrus/UML and they are considering Eagle tool for the automatic translation to Yang.

90 mins

Technical discussion on Integration of Streaming and Fault Management

Andrea Mazzini presents current state of TapiNotification, TapiStreaming and TapiFM models.

Agreed a simplification, only one object, ObjectNotification, augments the new EventNotification, which is replacing the old Notification signal:

  • Confirmed that for TAPI 2.3 the "object creation" model will still be different for Notification and Streaming. 
    • Agreed that backward compatibility is assured by keeping the "deprecated" Notification signal.
    • Agreed to explore a more generic data type than name-value pair (which seems less interoperable) for the new object creation notification - this to allow any dump of contents, possibly aligned to Streaming augmentations (see diagram below).
    • Post meeting note, leaving the UML type as "undefined", the uml2yang translates to Yang:
leaf-list object-content {
  type string;
description "The object content, e.g. all the attributes of a newly created object. The mapping is not specified.";
  • Preliminary agreement that TAPI 2.4 object notification will fully align to Streaming augments:


   A JSON Patch document is a JSON [RFC4627] document that represents an
   array of objects.  Each object represents a single operation to be
   applied to the target JSON document.

   The following is an example JSON Patch document, transferred in an
   HTTP PATCH request:

   PATCH /my/data HTTP/1.1
   Host: example.org
   Content-Length: 326
   Content-Type: application/json-patch+json
   If-Match: "abc123"

   [
     { "op": "test", "path": "/a/b/c", "value": "foo" },
     { "op": "remove", "path": "/a/b/c" },
     { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
     { "op": "replace", "path": "/a/b/c", "value": 42 },
     { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
     { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
   ]

7.10.  The "anydata" Statement

   The "anydata" statement defines an interior node in the schema tree.
   It takes one argument, which is an identifier, followed by a block of
   substatements that holds detailed anydata information.

   The "anydata" statement is used to represent an unknown set of nodes
   that can be modeled with YANG, except anyxml, but for which the data
   model is not known at module design time.  It is possible, though not
   required, for the data model for anydata content to become known
   through protocol signaling or other means that are outside the scope
   of this document.

   An example of where anydata can be useful is a list of received
   notifications where the specific notifications are not known at
   design time.