Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
    • Agenda for next TAPI virtual meeting
  • MEP/MIP model vs. direct inclusion of OAM parameters in the CEP
  • Review of TapiAlarm model
  • Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx
    • New use cases: 0d, 1g, 1h, 2a, 2b, 2c, 3d, 3e, 3f, 5d, 11a, 11b, 13b, 13c, 16a, 16b.
      • NEP/SIP Capability model
      • Link model, agree a general rule
  • Clean up of “Experimental” stereotypes

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 (blocking, 2)
  5. Path Computation Use Cases (blocking, 3)

TAPI 2.3 and RIA 1.2

  1. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (blocking, 1)
    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

20 minsAdministrative

All



Next TAPI virtual meeting. candidate week is

  • 12-23 April - consider 2+1 days/5 hours - focus on limited number of items.

Virtual meeting preliminary agenda:

  1. Path Computation
  2. 3R
  3. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU
  4. Physical Route and Physical impairments (GNPy as main reference)
    • GNPy is likely becoming the de facto open source standard for the physical model of optical networks.


Nigel Davis will set up a separate call for clarification regarding TR-548 scope.

  • Karthik Sethuraman suggests to involve Jack Pugaczewski, who is active in MEF and TMF on streaming subject.

Ramon Casellas plans to provide an updated RIA 1.1 draft by the virtual meeting.


 TAPI Call: 2 hours

Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx

  • New use cases: 0d, 1g, 1h, 2a, 2b, 2c, 3d, 3e, 3f, 5d, 11a, 11b, 13b, 13c, 16a, 16b.
  • MEP/MIP model vs. direct inclusion of OAM parameters in the CEP
  • Link model, agree a general rule.
80 mins

MEP/MIP model vs. direct inclusion of OAM parameters in the CEP

All

Andrea Mazzini presents the TapiOdu model updated with MEP/MIP directly composed into ODU Connection End Point:

The model structure is agreed.

  • Check whether any attribute of generic Mep and Mip classes is necessary.
  • Check OduMip oduCurrentNumberOfTributarySlots. Which relationship with tributarySlotList? Is this last updated at each successful resizing?

Discussion on TCM, agreed that:

  • For NCM the MEP is more strongly related to the CEP - hence the above proposed augmentation of CEP.
  • For TCM the MEP is more strongly related to the MEG - hence better to keep MEP/MIP instances for TCM model.
    • TCM does not necessarily align with connectivity, while NCM does.
  • Andrea Mazzinibuild a draft use case for NCM and TCM provisioning and resource model.
5 mins

Streaming

Nigel Davis

Nigel Davis has updated the Streaming model for 2.3 version.

  • Andrea Mazzinito check whether other previous modifications could be overwritten.
20 mins

Review of TapiAlarm model

All

Andrea Mazzini presents the new TapiAlarm module:

60 mins

Link model, agree a general rule

All

General discussion on the meaning and usage of TAPI Link object.

  • Links are redundant with respect to supporting Trails (modeled by TAPI Connections).
    • A Link is not redundant only if supporting Trail is not represented by the management interface.
    • Links are useful to describe the topology at each layer network. Concept of "useful redundancy".
    • The Client Controller can locally build the virtual topologies, e.g. for Path Computation applications.
  • The Link represents a capacity, the Connection/ConnectivityService represent a connectivity.
    • The Link intent is a Capacity Service.
  • Proposed rule: all Links shall be represented.
    • Pros: rule is simple.
    • Cons: high number of object instances.
  • Asymmetric scenarios, how to represent the "single ended Link"?
  • In TAPI, the Links are essentially connecting Nodes.
  • TE-Link is a further abstraction of the TAPI Link.