1. Pages
2. …
3. Open Transport Configuration and Control Home
4. OTCC
5. OTCC Meeting Notes

2020-05-04 / 08 TAPI Virtual Meeting Agenda and Notes

Andrea Mazzini presents commented version TR-5XX.1-TAPI v2.1.3 Reference Implementation_v0.9_am.docx

1) INVENTORY_ID format, after long and detailed discussion agreed to

1. remove the hierarchy shelf/sub-shelf from INVENTORY_ID examples in UC4b - hence aligning to chapter "4.2 Inventory considerations"
   • in general, simplify the representation of the position of an equipment
2. remove "s_sh" key, or anyway indicate that there are not use cases requiring sub-shelf key
3. clarify that the INVENTORY_ID scope is a single Device instance, "multi-NE" / "NE cluster" cases are not considered
4. centralize all descriptions of INVENTORY_ID

Arturo Mayoral will provide an updated version of Reference Implementation for final review on Thursday

2)  qianjia asks to clarify the Topology Initial State

1. Arturo Mayoralcomposes the picture where
   
   1. photonic side, it is expected that photonic NEP (and the Links between them), client CEP, client MC NEP are initially made available by server controller (together with MC SIPs when applicable)
   2. electrical side, it is expected that DSR NEPs and related SIPs are initially made available by server controller
2. Also agreed that DSR XC may or may not be represented by server controller, the client controller shall manage both cases.
   
   

3) qianjia asks to clarify the Multi-OTSi Use Case, after some discussion agreed the picture composed byArturo Mayoral where

1. two distinct photonic Links connect the transponder to the ROADM
2. in the ROADM, the two MC CEPs on add/drop side are cross-connected to a single MC CEP on degree side, to represent the organization of the two OTSi into a contiguous portion of spectrum (modeled by the MC Top Connection)
3. on ROADM add/drop side, there is one SIP per each MC NEP. For further discussion a single SIP per many NEPs.
   1. Side effect is that the OTSiA ConnectivityService is ended by four OTSi SIPs/CSEPs.
   2. Side effect is that it is necessary to add LayerProtocol input parameter to ConnectivityService creation see Wed P3 notes (as already done in TAPI NMR/edge), because the ConnectivityService is OTSiA while SIPs are OTSi.

4) Resiliency, UC5a: Arturo Mayoralasks clarification concerning the OMS Top Connection "protected", i.e. spanning the protection scheme, as it may seem redundant with respect to main OMS Top Connection.

1. Agreed that the scenario can be simplified, at the condition we find a clear rule to apply
   1. proposed rule: in case the resiliency of a Top Connection is implemented by a unique protection scheme (i.e. no sequence / no nesting of protection schemes), then the "Protected Connection" is redundant.
   2. the main and spare routes will include the Top Connection end points, despite they are not involved in the Switch.

from:

Nigel Davis presents otcc2020.ND.013_Tapi-NotesOn2.1.4.pptx

• General agreement on the presented list of items
  1. Extension mechanisms, conditional augmentation, expressing capabilities, vendor extensions
  2. Global/Local class, need to review the decisions, local id vs. global UUID
  3. Documentation enhancements
  4. Multiple contexts - future
  5. Refinement of intent - future
  6. Generalization of task model - future
     • Nigel Davisto reorganize the list highlighting the use case/problem to be solved
       
       

Andrea Mazzini presents the TAPI ODU OAM model currently defined in TAPI Next Major Release / Develop branch.

• Discussion on the application of MEG/MEP/MIP paradigm to OTN technology.
  • Pros:
    • Same management pattern for more technologies (see TAPI Ethernet OAM model)
    • ODU Tandem Connection provisioning fits with OAM Job concept
  • Cons:
    • More object instances
    • ODU path monitoring does not necessarily need an OAM Job
    • Alarms are raised on MEP/MIP rather than on CEP
• Temporary agreement that MEG/MEP/MIP paradigm is still preferable, the cons can be easily overcome (e.g. adding CEP reference to alarm notification)
• Agreed to remove the OduDefectPac and OduPmPac
• Discussion will be resumed tomorrow with input by Arturo Mayoral

Nigel Davis presents otcc2020.ND.009_TAPI-ModelRefactoring.pptx

• Karthik Sethuraman suggests to consider Stephane St-Laurent related presentation otcc2019.SSL.001.TAPI and RFC8345 Network Topologies.pptx
• There is agreement that slide four is the best solution draft, to be further developed
  • Nigel Davis to develop dry run on a number of formats to verify consistency with YANG constraints.
• In general, TAPI shall maintain its topology model structure, adding/extending specific items to become compatible with IETF. Also recalled that there can be only one tree on YANG side.

  Nigel Davis presents otcc2020.ND.016_TAPI-EquipmentScheme.pptx

• The presentation includes a number of scenarios highlighting the possible relationships between Equpment and Control.
• Conceps can be reused for the INVENTORY_ID format.
• Andrea Mazzini and Karthik Sethuraman recall that MEF is currently working with TMF on location/geographic/place model.

Nigel Davis presents otcc2020.ND.010_TAPI-ConnectivityServiceComputationService.pptx

• The TAPI Path Computation model needs some amendments, together with a clarification on purpose/application.
• Relax the p2p constraint, allow that a Link is shared by more Paths
• The Path is currently defined as an ordered set of Links
  • Andrea Mazzini maybe explore Link bundling, i.e. because equivalent for forwarding (e.g. between same Nodes)
• Paths can be used as routing constraint, but Path(Computation)Service cannot be. It would seem more appropriate to at least allow Path(Computation)Service as that was calculated as a collection with some purpose (e.g., to leverage disjointness between the paths when provisioning a protected or restorable ConnectivityService).
  • Explored the PathSet class, Karthik Sethuraman recalls that TAPI already allows to specify ConnectivityServices as routing constraint, hence it may be not strictly necessary to add PathSet class.

• Dajiang Wang, question concerning applicability to VPN services, agreed that the VPN provisioning use case does not foresee a detailed knowledge of the network topology, hence constraints are specified in more general terms like delay, resilience level, diversity maximization etc.
• Andrea Mazzini proposes to skip SIP and refer to NEP, to allow more flexibility, e.g. compute Paths "internal" to the network.
• Brief discussion on the need of an intermediate level between ConnectivityService and Connection, e.g. to allow time-related activation of different Connection, or for pre-planning, etc. Subject is "Connection Control".
  • Nigel Davisto develop "Connection Control" in Core IM scope.
    
• Note: Reuse orphan connection is already in 2.1.3 (see otcc2020.ND.005_TAPI-VariousRefinements.pptx slide 10). We may want to discuss various uses and documentation of these uses.

Andrea Mazzini presents otcc2019.AM.006_TAPI_ConnectivityConstraints.pptx

Arturo Mayoral presents otcc2020.AMLL.001_TAPI-v2.1.4 new use cases proposal.pptx

Andrea Mazzini presents otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx

• No objections to the presented provisioning attributes (slide 30..36)
• Long discussion on OTSiA and OTSi Layer Protocol Qualifiers, summary of agreements:
  • No need to add layer protocol name/qualifier to ConnectivityService
    • Andrea Mazziniremove it from TAPI NMR (refer to https://github.com/OpenNetworkingFoundation/TAPI/issues/434)
      
  • Likely not useful the OTSiA, MCA, OTSiMCA layer protocol qualifiers, as the assembly is modeled through associations between objects.
  • OtsiConnectivityServiceEndPointSpec class, add "numberOfOTSi" property (integer).
  • OtsiCsepHasOtsiConfigPac association, move from 1–1 to 1-*, i.e. allowing more OtsiTerminationConfigPac instances per OTSi CSEP
    
    • This allows to move from "one OTSi CSEP instance per OTSi signal" to "one OTSi CSEP instance including the information related to zero (full delegation), 1 or more (constrained provisioning) OTSi signals".
  • OtsiTerminationConfigPac class, make all properties as optional (0..1)
    
    • This allows delegation or specification of selected properties
  • Similar modification for Media Channel:
    • MediaChannelConnectivityServiceEndPointSpec class, add "capacity" property, type is to be defined as photonic extension of CapacityValue/CapacityUnit.
    • SmcCsepHasMcConfigPac association, move from 1–1 to 1-*
    • MediaChannelConfigPac class, make all properties as optional (0..1)

Andrea Mazzini presents otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx

Agreed the four combinations of OTSi cases, see slides 24-27. Below the case with one OTSiA Service with two OTSi, two photonic links 

Andrea presents TAPI213vsNMR.docx

• Purpose of this document is to list the differences between YANG modules automatically generated from TAPI 2.1.3 and TAPI Next Major Release version.

• Summary of agreements:
  • NMR: found broken inheritance of GlobalClass
    • Andrea Mazzinito resume inheritance
      
  • Keep ExtendedComposite stereotype in 2.1.3 and StrictComposite stereotype in NMR
  • Agreed that using data types or classes is equivalent to model "packages"
    • package-as-a-class, multiplicity "star": inherit LocalClass (which brings LocalId attribute)
    • package-as-a-datatype, multiplicity "star": identify at least one attribute "partOfObjectKey"
  • 2.1.3 and NMR: set sistematically as "Is read only" all resource attributes
  • Yang statement "mandatory", the tool currently does not translate correctly the multiplicity [1], i.e. in the Yang tree the attribute is marked as optional "?".  We should either fix the bug or manually edit the Yang modules...
    • Note that for multiplicity [1..*] the tool works correctly.
      
  • NMR: ideally remove all RPCs
  • Agreed to proceed immediately to review and align as necessary 2.1.3/2.1.4 and NMR

• Andrea Mazzini , Nigel Davis review Common and Connectivity
• Karthik Sethuraman review Topology

Andrea Mazzini presents

• otcc2019.AM.002-Multilayer_Scenarios.pptx, slides 3, 26..39 and
• otcc2020.AM.002_TAPI_2.1.3_Enhancements.pptx, slides 33..39
• Agreed to explore hierarchy of "specification classes" which describe the transmission capabilities per each relevant layer protocol, as outlined on the right side of the slide below.
• Arturo Mayoral suggests the case outlined on the left side, where more photonic interfaces can support a single electrical payload:

• Attributes shown above need further revision.

• Andrea Mazzinito refine model proposal, considering the Use Cases of Reference Implementation.
  

• Agreed that the description of transmission capabilities shall be available on the NEP nearest to physical, i.e. the NEP which refers to AccessPort.

• Nigel Davis the transmission capabilities should not be necessarily replicated in all NEP/SIP instances, but centralized in a number of "profiles/templates". This does not apply to the description of "current availability", to be explored the description of rules.
• NEP Pool, there could be the following criteria:
  • transmission capabilities
  • forwarding properties (equivalence for forwarding)
  • inverse multiplexing
• Agreed to postpone the NEP pool model analysis.
• Nigel Davis the "multiplexing capabilities" describes the leaf. We may also need to describe the capabilities of intermediate, terminated layers. E.g. which OAM features are supported by an ODU4 Trail Termination.

Nigel Davis presents otcc2020.ND.017_TAPI-SpecModel.pptx

• Concept of "invariant properties", read-only, to be referenced "by name"
  • while current TAPI augmentations are "by value", i.e. the augmented class is instantiated together with / inside augmenting class.
• These invariant properties can be organized in a number of distinct classes which are referenced by base class.