Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2021-05-25 TAPI Meeting Notes

Versions Compared

Old Version 2

changes.mady.by.user Andrea Mazzini

Saved on

compared with

New Version Current

changes.mady.by.user Andrea Mazzini

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

20 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.


Arturo Mayoral, now Program Manager for TIP OOPT, restarts to follow - maybe not continuosly - the TAPI calls.

  • In OOPT MUST (Mandatory Use Case Requirements for SDN for Transport) the specification of Use Cases is based on TAPI RIA 1.1
  • Arturo is evaluating new Use Cases of RIA 1.1 and checking the plan for 2.3 and 2.4 deliveries, specifically regarding OAM, FM and Streaming features.
  • TIP OOPT MUST is considering TAPI as best candidate for Optical Domain management.
  • Andrea Mazzini input UCs from TIP are of course welcome.
  • Nigel Davis, considering that MUST also includes IP technology, which is the bridge between IP and Optical network management?
    • Arturo replies that the UC from IP to Optical Management is currently under study. Output of this study could be a white paper on hierarchical controller stream.

Nigel Davis mentions O-RAN where the issues regarding Performance Monitoring big amount of data are under study.

  • Protobuf encoding technique is very efficient.

Ramon Casellas recalls that TIP OOPT CANDI is integrating GNPy in the disaggregated scenario.

Ramon Casellas is reviewing TR-548, editorial comments provided to Nigel Davis

Ramon Casellas recalls the issue of connection-ref and path-ref, which cannot be used because the connection and path yang nodes are read-only hence cannot be referred by a read-write list.


TAPI Call: 2 hours

30 mins

Delivering 2.3 RC1

All

Andrea Mazzini presents the latest commits to #510.

  • Pull request approved

Plan:

  1. Nigel Davis will amend and commit the TapiStreaming.yang with correct augment statements.
  2. Andrea Mazzini will generate .tree and .yaml with the updated TapiStreaming.yang
  3. Andrea Mazzini will create 2.3 RC1 release (see draft text here)
70 mins

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

  • Review of “asymmetric” provisioning UC
All

Ramon Casellas points out that 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.

After some discussion there is a preliminary agreement on this picture (access scenario):

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

Preliminary 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 "unterminated" Top Connection shall be represented if there is at least one monitoring point in the transit managed domain (second picture above).
    • Pure "trunking" or "tunneling" is intended when the transit management domain has no access to any management information regarding transported connection. In this case the Top Connection is not represented.
  3. The ENNI CSEP could indicate ODU2 layer qualifier.
    • To be considered the usage of DSR layer qualifier also at ENNI CSEP - as 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.
  4. In general, the ConnectivityService and CSEP layer rate could be independent from SIP/NEP supported capabilities.
    • E.g. in the second picture above, the two edge NEPs are NOT listing DSR/OUD2 capabilities. It is the network which provides DSR/ODU2 switching/forwarding/OAM capabilities, rather than the edge devices.
  5. 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.

Ramon Casellas recalls a note mentioned in a previous call: “TR-547 shall include the description of the "DIGITAL_OTN ENNI", reusable for all asymmetric connectivity use cases. MEF 64 Operator Layer 1 Services could be the reference standard.”

  • For further evaluation.

...