Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.

Date

27 February 2018

Attendees

Goals

Discuss OIF Interop Issues 

Agenda

·         Administrative

·         TAPI SDK 2.0.1 Release Overview

·         External TAPI-related activities: ODTN, OIF, MEF

  • Joint OIF Interop Call  - discuss OIF Interop spec issues including (but not limited to)
    • Representation of ODU channelization info in SIP/CSEP
    • Notification enhancements
      • Subscription to specific attribute changes
      • Representation of change-delta for deep/complex attribute data-types
  • Review of TAPI RI example(s) and desired enhancements
  • Recap TAPI 2.0 Refactoring items
    • Ownership of ConnectionEndPoint - Connection or Node/NEP

·         TAPI 2.0 Documentation and Use Cases

·         Termination Model (SIP, SEP, NEP, CEP)

·         Multi-layer, Multi-domain Connectivity

·         Resiliency, Protection & Restoration

·         OAM, Performance and Monitoring

·         TAPI Spec Model

·         OTSi Spec Model review

·         ODU Spec Model review

·         TAPI 2.0 SDK Items (contributions-driven)

·         Github Issues

Discussion Items

TimeItemWhoNotes
5 mins

General Administrative

Karthik Sethuraman
  • Next week - agenda TBD
15 mins

TAPI SDK 2.0.1 Release

Karthik Sethuraman
  • TAPI 2.0.0 released on snowmass github
    • Issues/comments on the RC3 version were posted on snowmass github
    • Issues were prioritized and some were addressed. Rest were deferred to 2.x.
  • TAPI 2.0.1 Items - target date mid-Feb
    • Most function item and bug fixes are committed into snowmass
    • The list can be found below in this notes
  • Decision made in OTCC Call to rename the github Snowmass repository to tapi
  • TAPI Yang modules will listed in Yang catalog
10 mins

TAPI-related external activities:

  • OIF 2018 TAPI Interop
  • ONOS ODTN
  • MEF NRP

Lyndon Ong 

  • OIF Interop Spec development in-progress
  • ODTN is using TAPI as NBI, phase 1 will use only the DSR layer and future phases will include full optical
    • phase 1.5 will use a intermediate mediator/line-system controller, TAPI as one of the choices for NBI of line-system-controller (other is OpenConfig)
  • MEF NRP - MEF released MEF 59/60 (NRM/NRP), in process of releasing the NRP SDK r2 (based on TAPI 2.0.1)
    • target date for publish is end of next month
    • this involves ODL uni-manager updates

60 mins

OIF Interop IssuesLyndon Ong

Documents: https://wiki.opennetworking.org/download/attachments/259719184/otcc2018.LYO.001-MDML_Example_Feb02.pptm?api=v2

  • Description of Option B in TAPI FRD
  • G.7715.1(2004), Appendix 1 describes the different scenarios for identifying/placing the interface points
  • How to characterize the ODU SIPs at the (E/I) NNIs
    • Enhance SIP with ODU tributary and timeslot information
  • How to handle multistage multiplexing (e.g. ODU0 over ODU4)
    • 2 options discussed in TAPI:
      • From MD controller setup ODU4 ConnectivityService first and then ODU0 ConnectivityService
      • From MD Controller setup a single ODU ConnectivityService, specifying both ODU0 & ODU4 information
  • OMS Layers/Link representation - use OTSi Link to represent the OMS capacity information - rest of OMS/OTS would be part of the media layer spec (TBD)
  • Notification updates in case of changes in complex/deep structure attributes (TAPI has not clearly specified on how to repreent this)
    • content of NameAnValueChange::valueName - either use XPath or URI syntax to clearly identify the leaf that has changed rather than coarse attribute uuid/local-id
  • Sync v/s Async interaction/responses for REST APIs
15 minsTAPI RI OverviewKarthik Sethuraman 
TBDTAPI 2.0 Github Issues 

Not discussed due to lack of contributions

Action Items / Task Assignments

TAPI 2.0.1 Items

Items that will be part of the 2.0.1 Release

  • TAPI RI Updates
    • Compile tapi-connectivity.swagger using swagger-codegen tool
    • Use swagger-codegen to generate Python-flask server and Python client stubs
    • Returns responses from a predefined/static json file
  • Yang Updates
    • Yang modules meta data/information - Copyright, version, contact, etc 
    • Generate a TAPI Yang module that includes/imports all TAPI modules as a convenience
  • OpenAPI/Swagger updates
    • Update to the .swagger files generated from yang using eagle tool (updates to the eagle Yang2OpenAPI tool)
    • '-' in REST input parameter names need to be replaced by '_' to confirm with python-flask/connexion convention
      • no change to class/attribute/enum names
    • Handle augmentation pattern in a better/intuitive manner
      • example: Currently tool generates a additional element ContextSchema for augmentation instead of injecting onto the Context element
  • Add additional rates to LayerProtocolName
    • DSR/DIGITAL_SIGNAL_RATE layer
  • Add CapacityPac to the NodeEdgePoint
    • This information is need to expose NEP capabilities when modeling fixed-mapping cases in a compact/simplified manner without presence of Links/TransitionalLinks attached to the NEP.
  • Capacity attributes are always read-only in current version
    • This needs to be read/write when used in ConnectivityService request
  • Rename Context class to TapiContext to avoid Yang compilation issues in both ONOS and ODL
    • issues with having both the container and grouping having same same "context"
  • Enhance the Notification::ObjectType enumeration to include additional TAPI 2.0 classes
    • MEG, ME, MEP, MIP, MeasurementJob, NodeRuleGroup, InterRuleGroup, SwitchControl, Rule, Switch, Route, etc 

Github Issues

General Areas to be worked on (target at least 1 item per week for discussion in TAPI call - a brief contribution should be provided)

  • UML Lifecycle sterotypes - capture maturity of TAPI classes/attributes explicitly - no stereotype means "not determined"
  • Entity Lifecycle - (Lifecycle/Operation/Administrative state enumerations): need more explanation, documentation and inter-state-dependency diagrams
    • Some state diagrams are available in Core IM 1.3 Foundation module (512.3 figures 3-4, 3-5, 3-6 & table 16)
  • Topology pacs: need develop descriptions/examples how that can be used
  • "key" attributes should be extensible enumerations instead of string type (e.g. address-type, cost-name)
  • Termination pac (State/Direction) - needs discussion on usage or even if we need them
  • Generalized Capacity data structure
  • OTIM- OCH & OTSi usage clarification from ITU-T SG15
  • Extensible Enumerations - should all TAPI enumerations be extensible by default ?
    • Semantic v/s vendor/interface/run-time extensible
  • Backward compatibility
  • NMDA compatibility
  • Multi-vendor Inter-operability gaps
    • Can it be addressed by development guide/guidelines?

2018 TAPI Features

General Areas to be worked on (a brief contribution should be provided)

  • TAPI SDK release schedule (timefarme based)
    • 2.0.1 - Feb-mid?
    • 2.1 - July 2018?
    • 2.2 - Jan 2019?
  • TAPI Reference Implementation framework
    • single layer use case
    • multi-layer symmetric use case
    • multi-layer asymmetric use case
  • TAPI SDK/Model Refinement/Enhancement
    • OAM model
    • Virtual Network model
  • TAPI examples and documentation
    • Termination
    • Multilayer
    • OAM
    • Node Constraints
  • Technology Spec Model
    • ODU
    • OTSi/OCh
    • Media (photonics)
    • Ethernet
    • Wireless
  • ? Device/Equipment configuration interfaces
  • ? Physical Inventory
  • ? Mgmt of Device Control interfaces
  • ? Mgmt of Synchronization/Timing
  • ? Profiles & Templates