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
TAPI 2.0 SDK Items (contribution driven)
Discussion Items
Time | Item | Who | Notes |
---|
5 mins | General Administrative | Karthik Sethuraman | |
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 mins | Multi-layer Example | Lyndon Ong | Documents |
| | | |
TBD | TAPI 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