Child pages
  • 2020-05-04 / 08 TAPI Virtual Meeting Agenda and Notes
Skip to end of metadata
Go to start of metadata

Date

to  

Zoom

See bottom of the page

Attendees


Agenda plan of May 4 - 8, 2020 ONF OTCC TAPI Meeting

CST 8pm - 2am
CEST 2pm - 8pm
BST 1pm - 7pm
EDT 8am - 2pm
PDT 5am - 11am

EDT SlotsCEST slots

P1 (08:00 – 09:45)

P1 (14:00 – 15:45)

P2 (10:00 – 11:45)

P2 (16:00 – 17:45)

P3 (12:00 – 14:00)

P3 (18:00 – 20:00)

Discussion items

DayPeriodTopic & ContributionsDiscussionNotes
Mon 4P1.1Intro, Agenda reviewReview of agenda, general agreement on discussion items
P1.2Review of TR-5XX.1-TAPI v2.1.3 Reference Implementation_v0.9.docx

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:

  

to:



5) Xiang YUN asks to update to "2.1.3" TAPI version mentioned in the document, agreed.

6) Some other minor adjustments, tracked by "solved" comments

Note that we could potentially also recap on equipment addressing schemes using otcc2020.ND.016_TAPI-EquipmentScheme.pptx.

Applicable to TAPI 2.1.3 bug fixing in case

P2Continued
P3Continued
Tue 5P1

TAPI Release Plan, alignment with Core IM Release Plan (e.g. IETF alignment for topology)


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


P2.1

ODU OAM


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
Applicable to TAPI 2.1.4
P2.2

Alignment to IETF RFC 8345 - Topology Model

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


P3.1

TAPI Release Plan

TAPI Roadmap, reorganized according to the recent decisions on TAPI development streams (see 2020-03-31 TAPI Meeting notes).
P3.2Equipment Addressing scheme

  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.



Wed 6P1

Connectivity Service Computation Services

otcc2020.ND.010_TAPI-ConnectivityServiceComputationService.pptx

Reuse orphan connection

Routing Constraints

otcc2019.AM.006_TAPI_ConnectivityConstraints.pptx

otcc2020.ND.012_TAPI-RoutingConstraints.pptx

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

  • Add recursive relationship to ConnectivityConstraints.
  • Agreed that slide 5 below is the best solution for near term, because is not disrupting the model
    • with the possible need to explicitly create SIPs for the purpose

  • While slide 7 below introduces new modeling item which nearly duplicates ConnectivityService and CSEP. Karthik Sethuraman thinks that in the longer term we shall reconsider the SIP role, e.g. removing the dedicated class and adding some UNI/ENNI/INNI type to NEP.

  • Another option could be to introduce "Connection Intent" class, to decouple ConnectivityService from detailed Connection control.
  • Dajiang Wang, also performance related constraints are necessary, e.g. OSNR, BER, etc.
    • Agreed that we need to review all currently defined properties of constraint classes, adding technology specific extensions. Contributions are welcome.

Applicable to TAPI 2.1.4

P2ODU OAM continue discussion on Use Cases
  • This presentation introduces Use Cases for the next version of Reference Implementation.
  • Reviewed the Use Cases related to OAM (FM, PM)
  • General agreement on presented Use Cases, next step is the detailed review of TAPI available definitions to identify necessary amendments/enhancements to fulfil the Use Cases.
    • UC 13b reporting policy
    • UC 13c threshold value provisioning (currently not available on OTSi CEP)
    • UC 16a alarm notification
    • UC 16b TCA notification
    • UC 16c active and historic alarms
      • Agreed to split in two distinct Use Cases, one for Active alarm retrieval, the other one for history management.
      • History, agreed that it is necessary to start from a well defined baseline - initial state info.
      • Buffering to solve temporary loss of connection between controllers.
      • Considered technologies are L1 and Photonic.
      • Malcolm Betts in photonic, most metrics are gauges.
      • To be evaluated if OAM Service / OAM Job approach is suitable for these technologies.

Post meeting note: allow to list more layerProtocolName values in the Notification parameters. E.g. for multi-layer Nodes.

Nigel Davis we may need to add Photonic Probable Causes, for further investigation what is currently defined in ITU-T.


P3

Photonic Model attributes

otcc2020.AM.001_TAPI_Photonic_Model_Evolution.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
    • 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)
Applicable to TAPI 2.1.4
Thu 7P1

Continue review of TR-5XX.1-TAPI v2.1.3 Reference Implementation_v0.9.docx

POSTPONED TO NEXT WEEK TAPI CALL

Note: we should discuss addition of streaming documentation to TR-5XX.1. See oimt.2019.ND.017.00-TapiStreaming.mht (as well as oimt.2019.ND.016.00-StreamingDiscussion.pptxoimt.2019.ND.018.00-StreamingSummary.pptx and oimt2020.ND.005-Streaming.pptx)Applicable to TAPI 2.1.3 bug fixing in case
P1Continue discussion on Photonic Model

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 

  • Agreed that MC SIPs are related to MC NEPs:

  • Andrea Mazziniadd scenario with OTSiMC service provisioning which drives also MC provisioning
  • Agreed that OTSiA, OTSiMCA, MCA values of Layer Protocol Qualifier are not necessary for the scenarios/Use Cases identified so far.
  • With reference to the agreed modifications on Wed P3, agreed to add new OtsiAConnectivityServiceEndPointSpec and MediaChannelAssemblyConnectivityServiceEndPointSpec. This to save backward compatibility.

P2+P3

Selection of Next Major Release features to be replicated in 2.1.4

otcc2020.AM.002_TAPI_2.1.3_Enhancements.pptx

(some additional notes otcc2020.ND.013_Tapi-NotesOn2.1.4.pptx)

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
    • 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

Applicable to TAPI 2.1.4


Fri 8P1, P2

Multi-Layer Capabilities / Node Rule Group

otcc2019.AM.002-Multilayer_Scenarios.pptx

otcc2020.ND.011_TAPI-MultiLayerRules.pptx

(also see otcc2020.ND.007_TAPI-onf2016.296_MwdFdCapability.pptx for background on constraint model)

Andrea Mazzini presents

  • 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.
Applicable to Next Major Release (NMR)
P2.1

Build the Contexts

  • Maybe based on same “resources”
  • Slicing features
  • Recursive

otcc2020.ND.014_TAPI-BuildContext.pptx

Discussion deferred to next TAPI calls.

Applicable to TAPI 2.1.4


P2.2

Control Model

otcc2020.ND.015_TAPI-RepresentingControl.pptx

Discussion deferred to next TAPI calls.
P3

Spec Model

otcc2020.ND.017_TAPI-SpecModel.pptx

(and for background oimt2020.ND.008-Spec.pptx and TR-512.7, TR-512.A.10 (and TR-512.5 and TR-512.6 for some spec sketches) at https://www.opennetworking.org/wp-content/uploads/2018/12/TR-512_v1.4_OnfCoreIm-info.zip)

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.

  • Karthik Sethuraman, the SIP should be the entry point for planning, i.e. the provisioning of transmission capabilities which will drive the equipment configuration (and consequently the logical resource view, e.g. the supported NEPs). In other words the description of "transmission capabilities" may be
    • driven by existing equipment (as commonly assumed in traditional management interfaces like TMF MTNM and current TAPI)
    • demand driven - planning
  • Nigel Davisprovide an example of equipment specification.

Thanks to all attendees and to Michelle Roth for providing Zoom rooms for the week.