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: 2 hours

30 mins

Admin - TR 548 status

All

Nigel Davis indicates that TR-548-TAPI_v2.1.3_ReferenceImplementation-Streaming_v1.0-seventh-draft.zip could be ready for publication.

  • Reviewed by Hing-Kam Lam and Arturo Mayoral.
  • Andrea Mazzini asks whether the document has a similar level of description as TR-547 - i.e. can guide an implementation. Answer is positive.
  • Ramon Casellas will review the document, there is an increasing interest on the subject.
  • Ramon Casellas considers that TR-547 focus is on Consumer side, while TR-548 on Provider side.
  • Andrea Mazzini TR-547 is based on RESTCONF. Nigel Davis TR-548 Candidate protocols include “websockets” [RFC6455] and “sse” [W3C SSE].
    • Nigel Davis and Ramon Casellas agree that Kafka could be a possible back end solution, no need to make Kafka visible at TAPI i/f. Direct Kafka option is not enforced. TR-548 is more compact wrt Kafka.
    • Separation between:
      • Back end / storage
      • Transport
      • Model
10 mins

Review of

Streaming aligned with 2.1.3 #509

All

After some brief clarifications, the pull request has been merged.

80 mins

Review of

Several Modifications - 2.3 delivery candidate #510

All

Karthik Sethuraman shows the modified Yang modules.

  • TapiCommon, agreed the only change (added OTS_OMS layer qualifier to PhotonicLayerQualifier).
  • TapiTopology, agreed modifications:
    • added to the NEP:
      • supportedMuxSequences: MultiplexingSequence [1..*]
      • availableMuxSequences: MultiplexingSequence [1..*]
      • baseLayerProtocolQualifier: LayerProtocolQualifier [1]
      • InterDomainPlugInPac (technology agnostic plug-in, could be based on OTN TTI)
    • Agreed that supportedMuxSequences shall be centralized in a specification class. For future consideration.
  • TapiConnectivity, agreed modifications:
    • layerProtocolName and Qualifier added to ConnectivityService.

    • Keep the cepRole attribute of CEP and added it to the CSEP (csepRole - ConnectivityServiceSpecReference).

  • TapiConnectivity, not agreed modifications:
    • grouping connectivity-constraint, remove commented list connection-inclusion/exclusion, leaving just UUID as before.
  • TapiPathComputation, remove redundant attributes from topology-constraint grouping.
    • Discussion on the manual editing of generated Yang modules, currently the
leaf-list connection-end-point {
type leafref {
path '/tapi-common:context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/
                  tapi-connectivity:connection-end-point/tapi-connectivity:uuid';}
  • is redefined as:
list connection-end-point {
uses connection-end-point-ref;
key 'topology-uuid node-uuid node-edge-point-uuid connection-end-point-uuid';

Discussion on module names. Agreed that the date can be removed from the module names.

  • The revision argument is checked only if the argument is replicated in the module name, not in the reverse case, i.e. we can keep the revision statement in the modules while simplifying module names.
  • Add 2.3 revision statement, which shall mention also 2.1.3, as 2.3 is merging both 2.2 and 2.1.3 evolutions.