Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2019-12-03 TAPI Meeting notes
Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • TAPI Reference Implementation (Arturo)

  • TAPI v3 ConnectivityService enhancements (Stephane, Andrea)

    If time allows:

  • TAPI v3 Resilience & Connectivity Constraints Enhancements (Andrea)

Discussion items

40 minsAdministrative

Andrea Mazzini

Nigel Davis

Next TAPI Call: 

  • Agenda not discussed - will continue on same items as today
  • Next F2F Meeting Plan - not discussed. Current plan is: 
    • Week of 
      • Should we schedule it earlier? In April time-frame?
    • Location: Telefonica, Madrid
  • Nigel Davis TAPI roadmap:
    • TAPI Roadmap 2023 updated including a new version 2.3 which purpose is to anticipate a selection of 3.0 features. Selection is made on less impacting features, specially considering backward compatibility.
  • Andrea Mazzini, Karthik Sethuraman to provide more details on Ethernet (L2) feature.
  • Nigel Davis to provide more details on ETSI NFV feature, as it seems more related to Core IM than TAPI.
  • Action to ALL, please check the roadmap and enhance feature descriptions!
40 minsTAPI Reference Implementation
Arturo Mayoral
30 minsConnectivityService enhancements

Andrea Mazzini

  • Andrea Mazzini proposes this model to enhance the constraining capabilities of a ConnectivityService
    • with respect to potential Connections
    • and their resiliency schemes
    • and their resiliency routes
  • The idea is to reuse existing constraint classes (Topology/ Routing/ Resilience Constraint) for Connection level, and further reuse only TopologyConstraints for Route level. The ConnectionService class allows to select a layer protocol (also at server layers) and ending NEPs / Nodes, to delimitate the potential scope of a resulting Connection. It is so possible to specify a full range of constraints, for any number of potential Connections at any layer. Similarly for Routes, where the unique delimiting scope is their priority.
    • Post meeting note: ConnectionService needs NEP/Node 1) direction, 2) role, 3) protectionRole. More in general, a structure similar to CSEP...
  • This model is backward compatible with current definition.
  • Jonathan Sadler notes that the displayed model seems a mix of service definition and service instance management items. General agreement, the current model of ConnectivityService would need a deep reorganization, but this is somehow in conflict with backward compatibility requirements (several implementations are already ongoing) and available resources.
  • Malcolm Betts points out that we need Service Templates. Agreed.


Action items

  •