Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • Technical discussion on Integration of Streaming and Fault Management
  • 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 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




Agreed to dedicate one week / 4 days / two hours per day for the review of TR-547: July 5,6,7,9 10-12 CEsT

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

Post meeting notes:

TAPI weeky call - canceled (Andrea is not available)

TAPI weeky call - likely canceled (Andrea @ MEF)

5 minsTIP MUST updateArturo

Arturo informs that MUST team will consider only the RIA 1.1 Use Cases with a "good" maturity level.

Ramon Casellas plan is to deliver in 2/3 weeks - before end of July.

20 mins

Technical discussion on Integration of Streaming and Fault Management

Agreed that the AlarmInfo and TcaInfo are deprecated, their content is modeled by the DetectedCondition class.

Agreed that for TAPI 2.3 the Object Creation model will still be different for Notification and Streaming. Postpone to TAPI 2.4 further discussion.

  • Streaming (example):


Notification:

TapiNotification33333344.png

Ramon Casellas regarding Attribute Value Change, we can encode the string of the yang node path in the attribute "name".

Agreed that TAPI 2.3 type is correct:

In TAPI 2.1.3 the optional attribute is valueName, which seems wrong.

150 mins

Presented the outcomes of

2021-07-05..09 Review week of TR-547 - Meeting Notes

All
  1. Agreed the "empty list" rule. Do not introduce "presence" statement. Agreed that also the container does not exist if is "empty", i.e. it includes only empty list(s).
  2. Karthik Sethuraman clarifies original semantic of NetworkTopologyService class: it was intended for the provisioning of topology (Client builds the network, in line with general SDN concept - ahead of the time...). Agreed that we are not yet there, so far the contributions are focused on connectivity/OAM management. TAPI is currently a mid way between more abstract Core IM and more explicit network management (e.g. defining a specific TopLevelTopology class).
  3. Agreed that current comment of NetworkTopologyService class is appropriate.
  4. TapiPhotonicMedia, PowerManagementCapabilityPac, all attributes from RW to RO (TAPI 2.3)
  5. Agreed to keep Admin State of SIP as RW, for future Use Cases
    • Karthik Sethuraman recalls that it was a MEF requirement to drive resource activation to support service provisioning.
  6. Agreed to move SIP direction from RW to RO (TAPI 2.3)
  7. UC 0b - Topology discovery (synchronous mode), agreed the note "This use case does not exclude that an implementation MAY additionally provide a GET operation retrieving a whole topology object."
  8. Long discussion on UC 0d - Multi-domain OTN interdomain links discovery (Plug-id based on OTN TTI)
    • Reached an agreement, Ramon Casellas will provide the text in the RIA
    • The principle is to consider only SAPI 16 bytes for the OTN implementation. Noted that ExTI is not specified by G,798, rather ExSAPI and ExDAPI (MI_ExSAPI/DAPI).