2020-02-25 TAPI Meeting notes - Long Call - 4th part

Andrea Mazzini

Nigel Davis

Arturo Mayoral

• Next F2F TAPI meeting, hosted by Telefonica/Madrid:
  • 04 May 2020 - 08 May 2020 
    
    
• 03 Mar 2020 TAPI Call: 3 hours, start regular time (3pm-6pm CET), Agenda:
  
  • TAPI Security - Jonathan Sadler
  • Version 2.1.3 freeze: check all modifications
    • Andrea Mazzinicheck all previous meeting minutes to identify the agreed necessary modifications to TAPI 2.1.3 (and likely to 2.3 on)
      
  • Version 2.3 advancements: what to include very soon
  • Version 2.4: TAPI Documentation
  • Progress on Routing Constraints
    
    
• 10 Mar 2020 TAPI Call: 3 hours, start regular time (3pm-6pm CET)
  
  • Continue Review of TR-5XX.1-TAPI v2.1.2 Reference Implementation_v0.5.docx
  • OTSiMCA/MCA CSEP attributes
  • Multi-layer model / capabilities: at least in the scope of TR-5XX.1-TAPI v2.1.2 Reference Implementation
    
    
• 17 Mar 2020 
  • Preparation of May f2f agenda

Nigel Davis

Nigel Davis presents otcc2020.ND.005_TAPI-VariousRefinements.pptx

1. Extension mechanism
   • We need a complete description of TAPI extension mechanism including vendor extensions
     • Essentially Yang Augment (and the UML equivalent) is used for formal extensions
     • A challenge is that current augmentation does not deal with e.g. Vendor redefine of existing properties (smaller/wider value range, etc.)
     • Discussion to be continued as mechanism is a key feature
2. TAPI documentation structure
   • We need to discuss what structure we expect for the documentation of TAPI
   • We need a plan to ensure we deliver, viable from a resource perspective
3. TAPI Context build/modify
   • Negotiation leads to the offering of a context in which an enabled client can cause the building of Topology (a view)
   • Client provides Topology intent (create and update) in context
   • Current model of Virtual Network needs improvements
     • SIP is the bridge between abstract and real (e.g. a given region or building)
       
       
4. TAPI Path Computation
   • Terminology (Path is confusing in ITU-T environment, TE-Link is just TAPI Link)
   • Some of the constraints etc. do not appear to make sense for the construction of an ordered list of Links
   • A Path is a Link Chain to enable building of many co-routed ConnectivityServices
   • Below some proposals for change, see the otcc2020.ND.005_TAPI-VariousRefinements.pptx for more details:
     
     
     
     
     
     
5. TAPI ConnectivityServiceComputationService
   • Allows a PCE to provide a number of full definitions for a requested ConnectivityService with defined SIPs in terms of existing and potential
     • Connections
     • CEPs
     • NEPS
     • Links
     • Nodes
     • Topologies
   • Lifecycle state of PLANNED could be used but this seems to be a distortion of its purpose
     • So PREPLANNED or CANDIDATE may be necessary
     • We can’t use POTENTIAL as we have that for another purpose
   • A ConnectivityService can have many alternative Connections.
   • This is a generalization of both "pending" state and "potential" CTPs concepts of MTNM/MTOSI.
   • Bulk modification of the Connections supporting ConnectivityServices - consider the Core Model Task.
     
   • Distinguish between
     • multiple views of same resource
     • multiple usages of same resource - this case, i.e. the same ConnectivityService is supported by different (possibly overlap) combinations of resources, only one combination will be the "installed" one at a given time.
       
6. Additional routing constraint… existing Connection
   • In general it should be allowed for a ConnectivityService to use existing Connections ("orphan" / "discovered" / "pre-provisioned" Connections)
     
     
7. Some enum issues:
   1. CapacityPac
      • Capacity-unit enum should be identity
      • Capacity-value should be string
   2. Mapping type in the ODU should be identity

Andrea Mazzini shows otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx to help discussion.

• Summary of agreements:
  1. OTSiMC(A) and MC(A) layers are enough to model:
     • MCA Service, to prepare spectrum for future OTSiA provisioning

     • OTSiMCA Service, to configure the spectrum (of MCA) with more precise signal (OTSiA) provisioning: how the spectrum is organized to support a given signal pattern.

     • No "fat" OTSi / OTSiMCA, but only "fat" MC.
     • Super channel / spectrum optimization is represented only by having more OTSiMC Connections in an MC Connection. No need of further provisioning.
  2. Change TAPI 2.1.3 (and 2.3): PhotonicLayerQualifier, NMC/A becomes OTSiMC/A and SMC/A becomes MC/A.
  3. In the scenario when a common MC may be shared by two NMCGs across part of the media network (slide 14), agreed to represent two distinct e2e MC Connections, rather that a single 3-ended MC Connection.
  4. 3R model cannot avoid the representation of the termination of OTSiMC, MC and OTU.

Arturo Mayoral shows some pictures of OLP protection scheme.

• Summary of agreements:
  1. Clarified scope of NMC/OTSiMC Link (e2e)
  2. In the intermediate ROADMs, represent NMC/OTSiMC NEP, CEP and (cross) Connection when equipment supports any monitoring at that granularity, otherwise stop at MC CEP and (cross) Connection (deconstruction made visible for monitoring)
     • OTSiMC CEP is present for two purposes, forwarding and monitoring. In the photonic model is never relevant for forwarding (strict fate sharing with MC), but only for monitoring.
  3. UC where SMC/MC "orphan" Connection is already present, ready for usage by an OTSiMC Connectivity Service. Hence no provisioning of SMCA/MCA ConnectivityService. For further study the connectivity constraints.
  4. UC with explicit provisioning of SMCA/MCA ConnectivityService.
  5. UC with OTSiA ConnectivityService provisioning, creating OTSiA, OTSiMC and MC Connections.
  6. NMC/OTSiMC Top Connection is enough, making redundant the representation of NMC/OTSiMC Link.
  7. OMS is the PhotonicLayerQualifier of the Connection
• For further evaluation whether to allow skipping whole SMC/MC layer in case it is not relevant, e.g. "fixed grid" case. The other option is the creation of "same" MC as OTSiMC.
  

Arturo Mayoral shows otcc2020.AMLL.001_TAPI-3R Scenarios.pptx

• General agreement on the shown examples:

• Some considerations on fault management: for protection at NMC layer to work, the regenerator must "transparently" signal the server layer (photonic) impairments.