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

Logistic: 

https://global.gotomeeting.com/join/740965653

Date

Attendees

Goals

Discussion items

TimeItemWhoNotes
30 minsAdministrative & Logistics

Karthik Sethuraman

Nigel Davis

Session 1: 09:00 AM - 10:30 AM US Pacific time

Session 2: 11:00 AM - 12:30 PM US Pacific time

Session 3: 01:00 PM - 03:00 PM US Pacific time

Session 4: 03:30 PM - 05:00 PM US Pacific time

30 minsRecap of TAPI 2.x Topology & ConnectivityKarthik Sethuraman
 30 mins Resilience, Route State (nominal, working, standby, etc) & manual switch control via TAPI

Arturo Mayoral

Andrea Mazzini

  • Nigel Davis : AI : Recover slide packs on resilience and protection.
  • Nigel noted that many of the resilience scenarios were summarized in TR-512.7.
  • Nigel Davis : AI: Identify sections in TR-512.7 that cover different scenarios.
60 minsConsolidation of TAPI 2.x Topology and Connectivity model

Karthik Sethuraman

Arturo Mayoral

  • Separation of concerns for applying Node-Topology partitioning hierarchy...
    • GUI Visualization - No, should not be imposing this on TAPI
    • Admin demarcation - Potentially??
      • Single controller with multiple vendor domains
    • Underlying control demarcation - key reason for exposure of Node/Topology divisions
    • Slicing - Not at this stage of evolution of TAPI
    • Administration of mapping/slicing - Not at this stage of evolution of TAPI
  • Considering underlying control demarcation, should we support:
    • Navigation at each level of topology (i.e., have real NEPs and CEPs at each level)
      • This is duplication of data
      • This would support changes in degree of exposure on the fly (initially just abstract and then more detail exposed)
        • Not clear why this would be relevant though for TAPI (smile) (would make sense for exposure of slices to end users where the contract allowed for upgrading of degree of exposure (although reparenting of the NEP may be a better solution))
    • Only navigation via lowest level resources (i.e., Links at all levels only reference NEPs at the lowest level)
      • This does not allow change of exposure detail on the fly (other than via reparenting)
  • Need to ensure we look at what should be exposed at different levels of a controller hierarchy (i.e., different instances of TAPI)
60 minsTopology / Abstraction for TAPI 3.xAndrea Mazzini
  • TAPI Topology & Connectivity Enhancements.pptx
  • otcc2019.AM.004.00-Partitioning_Abstraction.pptx
  • Agreed in principle with multiple alternative topology aggregations from "atomic" detail to most abstract single node view.
    • Noted split and merge of aggregation paths
    • Andrea Mazzini AI: Need a good example of different aggregation paths from detail to abstract. This should critically show a realistic and valid mapping of detailed resources to abstract view. Ideally this will be the detail behind the case already shown in the slides
  • Impact on TAPI 2.x Topology model
    • Allow multiple encapsulated topology for an Node (NodeEncapsulatesTopology) - change multiplicity of Topology-end from 0..1 to 0..*
    • Add new association NEPIsSupportedbyNEPExposedByEncapsulatedTopology with multiplicity 0..1
      • This allows for simple exposure of underlying NEP's information. Allowing multiplicity >1 will need further rationalization of possible mapping/cloning scenarios
60 minsConnectivity Service enhancements for TAPI 3.xStephane St-Laurent