| Time | Item | Who | Notes |
|---|
Mon 6th | Admin | Kam | Planning for future face-to-face meetings - 3 meetings per year, rotating locations: Europe, NA, Asia, ...
- Try to avoid conflict with other SDO meetings
- OIF (1/16-18, 4/23-27, 7/30-8/3, 10/29-11/3), IETF (3/17-23, 7/14-20, 11/3-9), ITU-T (3/11-15)
- 2018 OIMT+OTCC Interim Meetings
- Proposals:
- March 12 - 16 @ London or Budapest
- June 11 - 15 @ Ottawa
- December 3 - 7 @ Melbourne Australia
- Action Item - Kam: Set up doodle poll
|
| | CMCC TAPI lab test | Weiqiang | Weigiang presented a summary of the result of China Mobile's lab test on the TAPI 2.0 specification - Presentation slide: CMCC Laboratory test of SOTN northbound interface based on TAPI 2 0.pptx
- Worked with Yunbin Xu of CAICT on testing
- The interface was done in OpenAPI JSON.
- The JSON code was hand-translated from the TAPI 2.0 UML
- Suggested work items from China Mobile
- Time accuracy requirement for scheduling in the interface between the controller (e.g., between the Super Controller and Domain Controller)
- Restoration performance. The test result of restoration was not good. Much longer than ASON. Need to understand the unsatisfactory switching performance in service restoration (Ethernet service with ODUk switching)
- Need to understand the scope of the ROADM work – metro or long haul
- Suggestion to CMCC JSON and IISOMI UML-JSON
- Harmonization of the CMCC JSON and Use the auto translation tool to generate the JSON. Model change be made on the UML model instead of on the JSON code.
- Used TAPI 2.0 and TAPI-like CMCC, multiple vendors, Supercontroller SBI (possible NBI)
- Eth, ODU and OCh topologies, Eth-ODU and ODU-OCh transitional links
- Multilayer setup – e.g., first domain has Eth SIP to ODU SIP, routing by the domain controller rather than the supercontroller
- Need VLAN push/pop actions to set the VLAN ID and Type (part of LTP?)
- Question of timing synchronization for scheduling – need controllers to agree on time
- Although their workaround was to rely on supercontroller to trigger
- Malcolm notes failure case – supercontroller needs to be informed
- Broader OIMT issue – note sync of OTN may not be visible to controller
- NTP? Question if this is accurate enough – if distributed connection
- Distributed mgmt./control scheduling
- Modification – bw, resilience, protection type – done via TAPI
- Note updateType from TAPI 2.0
- Multi-domain vs. per domain restoration – works but performance tradeoffs – performance not considered good, looking at whether it is dataplane or control plane
- Centralized vs. distributed, perdomain (1 vendor), interdomain (multivendor)
- OTU4 between domains, could have used OTU2 or other
- Identifying the trib slot – still causing some confusion
- Tested link fault, perdomain=100-1000ms, interdomain – 2.9s (worse than ASON) - needs more analysis
- CM conclusions – generally good
- Look at IM with PTN defined by CMCC – MPLS-TP model (ITU-T based? TAPI-like) – strategic mediation might be a solution?
- Did not use tools to generate JSON, used UML directly to JSON on their own – ok for prototyping but maintainance would be better with tool
- CM notes interest in API to ROADM, ITU-T is also looking at this – lots of questions – metro or longhaul?
|
| | TAPI - FRD review | Lyndon | - Presentation slides: CORD Build TAPI Agenda and Notes
- noted that OIF 2018 Demo is in planning, vendor survey out soon, contracts & NDA in January
- Some questions on OIF policy, noted that now OIF demo rather than joint
- FRD – noted that Option B is much more complex that Option A, we need to find time to discuss – Notification also high priority but OAM not, fairly simple for EPL. Notification discussion for Wed. AM session.
- reviewed current FRD status
- discussed additional appendixes with examples - notification is high priority, OAM lower priority
|
| | TAPI - Ethernet Spec model | Andrea | Much of the discussion was on Ethernet LAG model, instead of the Spec method - Presentation slides: EthernetUni_Tapi_Andrea_bz.pptx
- Simple LAG model compared to multi-chassis LAG – simple is most we can handle now.
- Even simpler, only one LAG
- Modifying ethernet UNI diagram – issues with complexity, maybe less complex in CIM?
- What to you expose to the controller? Do you need to be able to configure LACP? Hopefully not. Not in TAPI. Plug and play.
- No resolution yet
|
| | Controller, Processing Construct and Component | Nigel/Chris | - Is separate "ControlComponent" class needed?
- Client/server vs. peer – each component has client and server parts, can relate to others via hierarchy or peer, as peers client part can talk to server part of the peer
- TOSCA liaison – Processing Construct = TOSCA Node
- Kill “NE” concept, replace with ProcessingConstruct and ConstraintDomain
- CD can group together physical components of “NE” for sale
- What about a “Site”, geographical? A type of ConstraintDomain
- FD narrow form of CD?
- Equipment model – Andrea suggests “NE” just moved to equipment model –
- LTP – negligible forwarding, FD – negligible processing
|
| | Software & Model structure | Chris | Chris led the discussion - Presentation slides
- Comments
- Is FileSystemEntry useful/necessary?
- RunningOperatingSystem is a specialized RunningSoftwareProcess. Is it needed?
- Decoration (at instance) is Specification (at definition)
|
Tue 7th | IISOMI Guidelines | Bernd | Bernd led the discussion - Presentation slide: iisomi2017.BZ.001.01_IISOMI-Guidelines_Nov-Interim.pptx
- Architecture figure (slide 3)
- Agreed to remove UML-XML mapping
- Agreed to change JSON to OpenAPI/Swagger
- UML Modeling Guidelines IISOMI 514 (slide 4)
- Agreed to update the ClassDiagramStyleSheet.css file: Clarifying the use of the last item (green text)
- UML to YANG Mapping Guidelines IISOMI 531 (slide 5)
- Papyrus Guidelines (IISOMI 515) slide 6
- Need to check the MARS model in Oxygen if the relationship orientation is reverted
Nigel has checked briefly: Now appears OK but will need to confirm with more extensive checks of models known to have the issue - Noted that there is an editorial issue with Oxygen (cannot move the position of the straight line). Since this is editorial, agreed that this won’t stop us from migrating to Oxygen
- UML Profiles (slide 7)
- Critical Issues
- UML Modeling Guidelines
- Agreed not to use association class (NIH – Not invented here)
Official reply to MEF will contain onf2017.167 from Chris explaining AssociationClass to Class mapping
- UML to YANG Mapping Guidelines
- Conditional Specify/Augment
- Karthik clarified that the criteria attribute is set at create and invariant
- Agreed to use Constraint, not to use a stereotype property like “target”
- Agreed that the criteria could also be a list of attributes
- New Simple Augment Path (slide 16) & New Augment Path Example (slide 15)
- Agreed to add “XOR” and 0..1 on both main classes
- Park the examples of slides 16, 17, & 18 for the mapping guidelines (i.e., not to address their mapping for now)
|
| | Specification method - IM/TAPI | Nigel/Karthik | Topic not covered. |
| | TAPI - MEF topics | Andrea | Brief discussion. Awaiting liaison statement from MEF. |
| | Entity Lifecycle | Malcolm | Malcolm led the discussion - Presentation slide: oimt2017.MB.001.00.entity-lifecycle.docx
- Agreed that Figure 1 provides the good scope
- Using term Supporting/Dependent entity, instead of Server/Client
- Try Simple example: LTP example multi-layer then inverse mux
|
Wed 8th | TAPI - FRD review | Lyndon | - discussed notification example
- identified issues with notification
- identified 3 basic use cases in framework of OIF Demo - Link Failure (input to path computation), connService provisioning; connService failure
- Considered intermittent alarms
- discussed briefly multi-layer/multi-domain example
- looked at TAPI agenda slides but also need to look at .041 contribution slides where layers are more fully separated in topology
- see TAPI Agenda for more details
|
| | CORD BUILD Presentation & Discussion at : - Introduction to OIMT & OTCC
- Model Driven Solutions
- Towards Dynamic Interfaces & APIs
- PoCs and Next Steps
| Chairs/Leads | Presentation slide deck: To be posted - Good attendance. Sessions went well
- Had discussion with CORD (Scott Baker & Sapan Bhatia), ONOS (Andrea Campanella), and Guru on the OIMT and TAPI works
- Andrea wants to compare their current NBI JSON with TAPI JSON (sounds like it should be pretty simple given their NBI has a single box model), then we discussed whether the target should be using REST/JSON or protobufs, the IM group is going to look at a UML-to-protobufs mapping.
- Scott and Sepan said they thought the TAPI information model could be valuable to be incorporated into CORD, as CORD does not currently support a sophisticated topology/connectivity model. We are going to pursue this further with them. Sepan would prefer the models be mapped into x-proto, so not exactly the same as protobufs. Andrea seemed to think that protobufs would be acceptable and better (at least better specified).
- Guru was also here, he was mainly I think trying to build up support for the new Open Disaggregated Transport Network project (a spinned off project from ONOS), which will support TAPI as NBI to ONOS - provided that vendors pony up resources to do the development. He was encouraged by the CORD discussion, basically said for us to keep pursuing this independently of the ONOS work.
|
| | Science Fair Demos | OIMT/OTCC | |
Thu 9th | UML-JSON Mapping | Rick | Rick presented the changes to the UML-JSON guidelines document that were made based on the May 2017 Beijing meeting - Documents:
- Mainly discussed the mapping of Complex data type attribute with multiplicity > 1
- Next steps:
- Action Item - Rick: Update the UML-JSON guidelines document per the discussion; Update the mapping tool per the discussion
Agreement: - When re-designing the UML-YANG mapping tool, we should include UML-JSON so that there will be one single mapping tool for all mappings (YANG, JSON, TOSCA, Proto buff...) with a common front-end for inputting and interpreting (i.e., reading) the UML model input.
- Action Item - Tool Re-design Team: Include Rick into the team
|
| | TAPI - ODU Spec model | Italo/Kam | Discussed the ODU Spec comments in odu spec comments - IB - kl - Line 3: After clarification from Kam, Italo is okay to stay with Termination Point in the description
- Line 4: Indeed there is mismatch G.8052.
- Action Item - Kam: to follow up with updating G.874.1
- Line 5: ODU Rate
- This item took most of the discussion, which concluded with
- G.874.1: No change is needed to G.874.1 that the data type is "REAL"
- Action Item - Italo: Will provide a contribution for the right mapping for TAPI.
|
| | OAM | Andrea | Documents Andrea continues the presentation, with scenarios at UNI, ENNI and INNI, trying to capture how EVC and OVC "MEF Services" can be represented on Resource side, together with the relevant monitoring points. Scenarios are in general agreed, to be further developed. Noted that the C-VLAN/S-VLAN encapsulation model can be simplified, collapsing the layers: to be verified if the EVC-OVC relationship is always 1:1 at UNI. MEF describes OVC trunking in transit networks. Theoretically “deep packet inspection” monitoring could be performed on selected C-VLAN flow even if encapsulated in S-VLAN tunnel. OAM model may foresee such capability. For further analysis.
|
Fri 10th | Operations patterns, Intent, TOSCA | Nigel | Operation patterns, Intent, and TOSCA Discussion - Definition of service provided in the material is not a formal definition.
- It will be necessary to close on a formal definition in ONF
- Outcome-oriented constraint-based interaction
- Focus of a request is on what, where and when. How is delegated.
- The what/where/when may be decomposed into components "with what parts" {{It says "with what" in the slides, this can be mistaken for "using what")
- It is important to not confuse "with what parts" with
- "how", i.e. what mechanism
- "using what", i.e. what tools and "who", i.e. people (essentially a special "using what")
"how" to achieve the desired what/when/where, who should work to achieve it and what tools to use are delegated to the provider
- The request is in terms of constraints, where a specific value is just a very tight constraint
- Often (perhaps actually, always) a specific value has a tolerance and/or a time factor, hence it is clearly a constraint
- [Editor’s note: Need to think about the cycle from invention through negotiation to contract (at least in abstract)
- This relates to the lifecycle of a scheme through the creation of the spec through the deployment of an instance through change of the scheme…]
- Need to develop explanation of the through/to/about pattern and also on the align/notify of change approach
- {{Editor's note: This needs to be documented in TAPI and potentially in the core as a candidate architecture (using the ControlComponent and View as an axis)}}
- We should aim for consistency across all interactions including grammar, constraints and nouns. Considering all interactions:
- Demand
- Inform
- Broadcast Query
- We should begin to explore dynamic encoding where a semantic can be coded in various different ways depending upon the circumstances
- Considered support for general intermittent state
- Brief discussion on architecture principles
Component-System Pattern Approach to interfacing Canonical models of networking, control, processing, physical, software Management-Control Continuum
- Brief discussion on modeling approach Semantic sets v categories
- Brief discussion on decoration and spec approaches
Next steps - Operations pattern
- Generalize the work to cover any exchange, including notifications
- Work towards a first phase grammar
- Consider building this on top of protobufs
- Explore protobufs for case driven structure “compacting” behaviour
- Note that the above is not particular relevant to TOSCA at this stage
- Intent
- Consider Outcome-Oriented Constraint Based (OOCB) interactions as the basis for all interactions at all levels
- Examine TAPI for evolution to OOCB style
- Look at mapping existing TAPI operations to OOCB
- Consider OOCB in the context of TOSCA
- Scheme specs
- Further develop the concept and realization
- Discuss relationship with TOSCA
- This will require further exploration of the meta-model and component-system overlap
- Component-System pattern
- Continue to progress this with TOSCA looking for lessons on both sides
|
| | Controller, PC & Components | Nigel/Chris | Topic covered sufficiently earlier in the week |
| | TAPI - Update on TIP activites | Stephane St-LAURENT | Telecom Infra Project ( TIP) presentation by Stephane St-Laurent (Infinera) - Presentation slide deck: To provided by Stephane
- Introduction to Open Optical Line System WG
- Introduction to TIP OLS Demo - Overall architecture
- The ONF Core Model (conceptual) and TAPI model (implementation) are being used extensively in OOLS
- Explicitly in the interface between the Service Application and the L0 Power Controller
|
| | Work plan | Team | Additional v1.4 work items - UML-Protocbuf language mapping document
- UML-Protobuf generator (prototype)
Proposed v1.5 work items - Party model (for Person/Org Unit)
- Location model
- UML-TOSCA mapping document (from 1.4)
- UML-TOSCA generator (from 1.4)
Work items and schedule were reviewed and updated |
| | Topic | Bidirectional associations | Discussion - Currently TAPI model has unidirectional associations, MEF Core model uses bidirectional
- Request from MEF is to make all associations in TAPI bidirectional as well (this request has not been received formally yet)
- This issue affects more than just TAPI, as it affects UML Guidelines and benefits from previous discussions and experience in the Core Model
- Pro
- It was noted that this will ensure MEF and ONF aligned rather than MEF defining a variant of TAPI (however, there may be other things that emerge if this change is made)
- Con
- A number of points were raised –
- Additional overhead, difficulty keeping implementations consistent, need to impact both sides of the association when there is a change, etc.
- Modeler can no longer define that only one direction is required
- Agreement is to take this issue up to the OTCC TST for formal discussion and conclusion
- Send liaison back to MEF with our thoughts and follow up questions (after we look at MEF's liaison to ONF (the liaison document has not yet been received))
|
)