Skip to end of metadata
Go to start of metadata

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

Date

13 February 2018

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

    • Multi-layer, Multi-domain Connectivity
    • Termination Model (SIP, SEP, NEP, CEP)
    • 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

To-be-removed
  • Next week - agenda TBD
5 mins

TAPI SDK 2.0.1 Release

To-be-removed
  • 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
    • RI Updates
      • Working version of TAPI RI - current version in 2.0 does not work (SNAPSHOTS available from this week on snowmass git repository)
      • Compile tapi-connectivity.swagger using swagger-codegen tool
      • Use swagger-codegen to generate Python-flask server and Python client stubs
      • For 2.0.1: Returns responses from a predefined/static json file
      • ONOS based implementation not yet in the Snowmass baseline - probably will be ready for 2.0.2
        • A small mediator-like python code layer that does the mapping between T-API and ONOS REST API
    • Yang Updates
      • Yang modules meta data/information - Copyright, revision, contact, etc (must have)
      • Need to 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
    • Enhance Topology Pacs descriptions
    • 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 name "context".
      • This only happens with context as it is the only top-level container, rest of containers/lists are enclosed in some other grouping
      • rather than have folks edit TAPI Yang files, it is better to update the TAPI UML as it is low impact
    • OAM Module Bugs (noticed by MEF)
    • Other Github Issues ?
5 mins

TAPI-related external activities:

  • OIF 2018 TAPI Interop

Lyndon Ong 

Following is a recap from previous TAPI Call
  • Main focus is PRESTO/TAPI 2.0.x Testing
  • IA Spec development in progress currently
  • Actual testing in carrier labs in April/May
  • 4 Use cases
    • Multi-domain, Multi-layer Connectivity
      • Setup, Recovery, Re-optimization
      • Expect 10G-ETH and/or ODU2 interfaces
  • 7 Vendors, 4 Carriers
  • Questions
    • How to SIP attributes esp. specifying ODU trib/timeslot information
      • TAPI itself has not defined SIP attributes for any technology
      • Current MEF NRM/NRP spec/sdk defines SIP/CSEP/CS attributes for ETH (L2)
      • For ODU/L1, MEF has only TS (paper) for service definitions (no model/SDK)
        • We could either use the MEF L1 drafts to develop the SIP/CSEP/CS models as joint OIF/ONF/MEF activity with OIF Interop project
        • Or we could use an shortcut method to develop an "label" format to be passed as name attributes of SIP/CSEP/CS
      • OIF is looking to borrow the information from the current NEP/CEP to build the SIP/CSEP augments for ODU
    • Alignment of PRESTO and TAPI
      • expect it to be aligned, but this is more of an OIF discussion point as it involves bridging MEF and ONF
10 mins

TAPI-related external activities:

  • ONF ODTN Project
Lyndon Ong
  • ONF ONOS project focused on TAPI as NBI and OpenConfig as SBI
  • For 1st Phase, TAPI NBI discussion on whether to only specify TRPD Client ports parameters or also line side (OTSi)
  • Ultimately the goal is control all the way down to L0
  • A joint call in near future would be preferrable
 

TAPI-related external activities:

  • ITU-T SG15
Hing-Kam Lam
  • ODU: Latest ITU-T G.709 and G.874.1 implies that OCh and OTSi are not the same - so keep both for now
  • ODU: Latest G.874.1 is liaised to ONF - probably does not include OTSi
  • ODU: What about latest G.798?
  • OAM: ITU-T G.8052.1 has been liaised to ONF. Need to review for impact to TAPI OAM model

 

60 mins

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

Andrea Mazzini

To-be-removed

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
  • Enhance Topology Pacs descriptions
  • 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  
  • OAM Module Bugs (noticed by MEF)
  • Other Github Issues ?

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