Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • TAPI v3/v2.3 Connectivity Constraints Enhancements (Andrea)

Discussion items

20 minsAdministrative

WelcomeJose Maranhao!

Next TAPI Call: 

  • Agenda 
    • Nigel DavisStreaming update to model & general discussion on principles
    • 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 (from 3 Dec. minutes):
    • TAPI Roadmap 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!
70 minsConnectivityService enhancements

  • 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 SubordinateConnectivityService class allows to select a layer protocol (also at server layers) and ending NEPs / Nodes (through SubordinateCsep class), 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.
  • This model is backward compatible with current definition.
  • In the slide below is shown the parallelism between ConnectivityService and SubordinateConnectivityService, and between CSEP and SubordinateCsep. Considering the original proposal by Stephane St-Laurent (otcc2019.SSL.002.TAPI ConnectivityMediaModel.pptx) where ConnectivityService is recursively reused to provide "connection" constraints, the key point regards the availability of Service Interface Points. In other words, it is possible to specify more detailed constraints reusing ConnectivityService if SIPs are available also in "the middle" of the network - i.e. the server provides the information of all available "points of service" (for connectivity, OAM, resiliency, etc.). Traditionally the SIPs are available at the UNI or ENNI demarcation points, which are more related to geographical/administrative boundaries. In the otcc2019.AM.002-Multilayer_Scenarios.pptx has been proposed "internal" SIPs for infrastructure trails, to allow the provisioning - through ConnectivityService - of the network infrastructure (e.g. ODU4 trails).
  • Two possible options:
    1. everything as a service: SIPs are supplied for any possible management feature
      • could be unpractical, e.g. OAM could be available on vast majority of "points" in the network
      • could apply to protection schemes supported by specific/costly hardware
    2. constraints can be provisioned on available "resources", e.g. Nodes, NEPs.
      • easier but less clean, model is nearly duplicated:


  • Nigel Davis to be specified the lifecycle of "subordinate connectivity services", e.g. is the supporting trail(s) removed when supported service is removed?
  • Malcolm Betts recalls that TAPI is designed for application at different levels of management, hence is reasonable to include both "opaque view" and "detailed constraining" modes of operation.
  • Jonathan Sadler it is possible to provision a ConnectivityService in "opaque view" mode, i.e. just end points, layer, capacity, but in a subsequent time update it to modify the route, specifying detailed constraints.
  • Hing-Kam Lam shall the pointers to routing/resilience/topology constraints remain in ConnectivityService class? Andrea Mazzini agree that may be redundant (but backward compatible). If all these pointers are moved to SubordinateConnectivityService, then this object must always be included in case such constraints are specified - even at ConnectivityService level only. In this light, the SubordinateConnectivityService class could be renamed, e.g. LayeredConstraints.

Action items

  •