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
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 | - 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 Issues | Lyndon 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 mins | TAPI RI Overview | Karthik Sethuraman | |
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