Skip to end of metadata
Go to start of metadata

Date

20 February 2018

This call is being recorded - the call recording will be provided on demand

Attendees

Goals

Discuss TAPI Multi-layer Termination Model Examples and Spec models 

Agenda

Administrative

    • TAPI SDK 2.0.1 Release Plan
    • External TAPI-related activities: ODTN, OIF, ITUT, MEF

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 2.0 Spec Models

    • ODU Model
    • OTSi Model

TAPI 2.0 SDK Items (contribution 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 

 

 

60 mins

Termination Model (SIP, SEP, NEP, CEP)
  • Fixed mapping case
  • Multilayer switching
  • Multi-stage multiplexing
  • Inverse multiplexing case
  • Asymmetric connectivity case

Andrea Mazzini

Karthik Sethuraman

Documents

15 minsMulti-layer ExampleLyndon Ong

Documents

    
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