Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

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

10 minsAdministrative

All



Nigel Davis will set up an additional separate call for clarification regarding TR-548 scope, involving Jack Pugaczewski (MEF and TMF).

  • Nigel Davis had a chat with Jack, who confirmed that TR-548 (on Kafka) is used as reference, for further discussion the level of alignment, also including PM.


TAPI Call: canceled (OFC Conference)

 2 hours

10 mins

2.3 RC1 - Diagram style sheets

Andrea Mazzini

Andrea Mazzini has a persistency issue with diagram style sheets.

  • Nigel Davis quickly checked and the issue does not occur in his Eclipse environment. Hence is something local to Andrea, will check.
10 mins

2.3 RC1 - Streaming and FM

All

Ramon Casellas asks whether the Streaming and Alarm models are aligned in version 2.3 RC1. Nigel Davis no, the Streaming model is not importing TapiFm.

  • Karthik Sethuraman points out that people considers FM/PM as the main applications for streaming.
  • Nigel Davis we can plan the alignment for 2.3 final release. Andrea Mazzini if the effort is relevant we may delay to 2.4 version.
    • Nigel Davis evaluate the effort for the Streaming and FM/PM integration.
  • TR-547 1.1, agreed to refer to TR-548 for streaming implementation. Notification and streaming will still coexist in future.
30 mins

Delivering RIA 1.1 (TR-547-TAPI Reference Implementation Agreement_v1.1_RCAS.docx)

All

Nigel Davis recalls that in general the RIA is not preventing alternative models, a (limited) degree of flexibility shall be considered. E.g. a given Use Case may constrain the model, but such constraining is not absolute, i.e. in a new Use Case the model can be constrained/relaxed in a different way.

Ramon Casellas Discussion on Use case 1a: Unconstrained DSR Service Provisioning single wavelength (=<100G).

  • This Use Case has been used as a reference for all the other CS provisioning UCs, but there are some ambiguities in the tables 17 to 28, it is unclear their application to UC 1a.
    • Agreed that the tables and other explanations shall be moved outside UC 1a, in a new section "Generic framework of Connectivity Service provisioning".
    • Ramon Casellas will provide an updated RIA version, then we can organize dedicated calls to speed up the overall review process.
70 mins

Delivering RIA 1.1 (TR-547-TAPI Reference Implementation Agreement_v1.1_RCAS.docx)

  • Continue review of “asymmetric” provisioning UC
All

UC 1h: Unconstrained asymmetric DSR Service Provisioning, UNI DSR E-NNI OTUk grey interface needs some clarifications.

  • Which layer protocol qualifier on CSEPs?
  • How to represent Top Connections which are not terminated in the managed domain?
  • Consider that UC 1h shall be supported by TAPI 2.1.3 version.

Nigel Davis edited the above picture to show the possible "symmetric transit scenario with client monitoring":


Confirmed agreements on the following rules in case of access and transit scenarios:

  1. Access scenario, the "semi-terminated" Top Connection lists the CEP where the Connection is terminated (UNI side) and the available server layer CEP at ENNI side ("end point projection") where the connection is delivered within a server container.
    • Doing so the Top Connection provides the best topological information. The ENNI CEP is intended as the point in the topology where the Connection is delivered to the external domain.
      • In other words, the ENNI CEP, e.g. the ODU4 CEP, is the one which supports the Connection bandwidth (ODU2 time slot).
  2. Transit scenario, the Connectivity Service (and its CSEPs) could be specified at any layer protocol name/qualifier, as this is the intent specification.
    • In other words, the CS represents the intent for a connection between SIPs, the CSEPs the intent for the amount and type of bandwidth on these SIPs.
    • The only relationship between actual-local SIP/NEP capabilities and CS/CSEPs layer protocol name/qualifier is the known rule of technology stack (e.g. a 10G DSR can be potentially supported by an ODU4 container, the reverse case not). The server controller will allocate the appropriate resources at same and/or server layers.
      • In other words, considering the 3rd picture above, the DSR CS can be provisioned even if the result does NOT include any DSR CEP/Connection, e.g. because transparently delivered by an ODU2 container.
  3. Transit scenario, the "unterminated" Top Connection shall be represented if there is at least one monitoring point in the transit managed domain (see 2nd and 3rd pictures above).
    • E.g. in case the 10G DSR is transparently delivered by an ODU2 container, then the DSR (Top) Connection will not be represented, but only the ODU2 (Top) Connection (3rd picture above).

Preliminary agreements:

  1. The ENNI CSEP could indicate the DSR layer qualifier, because CSEP is just providing intent information regarding the portion of (DSR) bandwidth that the ENNI SIP/NEP shall support.
    • The server controller will provide the supporting Connections at the layer protocol which is actually managed in the domain.
    • ODU related information (e.g. preferred time slot) can be provisioned as server layer constraint.
  2. The CSEP to CEP reference can be deprecated as could be difficult to be represented / maintaned in complex scenarios. The CSEP indicates the intent for a bandwidth portion of a SIP.
    • The service-to-connection relationship is modeled by the CEPs of the Connections which support the ConnectivityService.