Commonality & relationship with Core (see oimt2018.ND.033.00_ToscaJointWorking.pptx)
- Action Item 1.1.a – ND/CL: White paper on the mapping from Core/TAPI Model to TOSCA, starting with some specific use case examples; aim for TR-512 v1.5 release.
- Action item 1.1.b –
- Action item 1.1.c – ND/CL: Develop mapping of TAPI, including specification models, into a profile. Do lightweight Core mapping. Consider possible tooling..
- Action item 1.1.d – ND/CL: Investigate method for expressing constraint for System of Components (not just properties)
- Action item 1.1.e - ND/CL: Consider implications of change at each level of progression (from Component-System pattern, through levels specific components, through application to implementation
|1.2||Storage (Disk, LUN, ...) ||CH|
Task 36a (see: ONF_T36a_Storage.pptx)
| ||CPU / Memory||CH|
Task 36b (see: ONF_T36b_CPU-Memory.pptx)
- Need to consider not just the speed but also the latency
- Redundancy of: CPU? Storage?
- Performance, temperature, etc. go with the physical model
Task 41 (see: ONF_T41_IdentityImplementation.pptx)
- Agreed not to inherit from LocalClass and GobalClass
- Agreed to use stereotype to indicate whether to generate localIdentifer or globalIdentifier for the class
- Action item - Karthik Sethuraman: Verify whether TAPI use the MEF’s YANG to Restconf generator or not.
- Answer: No.
- Current generators are: UML to YANG generator, and UML to OpenAPI generator
|1.3||Joint with ODTN on TIP||SSL|
ODTN on Telecom Infra Project (TIP) (see: Facebook TIP L0 Model Overview 2018…)
- Overview of TIP on Open Optical Packet Transport (OOPT)
- Open Optical Line System (OLS)
- Comment on Slide 76 "MC Pool": It includes the gaps of spectrum between the MCs. Shouldn't it be a MC instead, i.e., it is not just a simple "Pool".
- Action item - Stephane: To update slide 78 on the grid
|1.4||Joint with ODTN on Photonic use cases||DV|
Reference Implementation for ODTN (See: Reference Implementations of Open Disaggregated Transport Networks)
Tooling + Guidelines
Latest draft of guidelines in progress
Presentation & issue discussion
- The open issues in the UML modeling guidelines draft were discussed
- For UML Papyrus file naming convention, special characters "_", "-", and "." are allowed.
- In the UML-YANG mapping guidelines will state that when translate to YANG, the "." character in the UML Papyrus file will be translated to "dot" in the YANG file name.
- The other open issues are not discussed due to running out of time
- Action item: Discuss the remaining open issues in the IISOMI calls
- Papayrus issues
- UML-YANG mapping guidelines open issues
- UML-YANG mapping tool open issues
- Guidelines documents editorship
- IISOMI UML-YANG Mapping Call chairman
|2.2||Spec model application - general ||ND|
- Comment: FC Spec v1.4, don’t be over cocked.
|2.3||TAPI 2.2 Connectiity: Multi-layer / Layer-transition capability / Constraint ||AM/KS|
- Legenda if graphical representations
- Ethernet over ODU over ODU
- Option B and
- Option A: slides 19, 23,
- DSR mapping in ODU or DSR mapping in ODU over ODU
- Option B and
- Option A: Slides 39, 41, 42 (Can we optimize to omit the NEP 100?), 46,
- Action item - Nigel Davis: Define the adapatation layer transition rules for ODU
|2.4||TAPI 2.2 (photonic) ||KS/SSL/AM/ND||Slides: Facebook TIP L0 Model Overview 2018.pptx|
|2.5||OpenConfig||Anees Shaikh |
Currently OpenConfig capability
The roadmap of planned/speculative future capabilities in OpenConfig
What other open source groups OpenConfig is working with
- Have no NMDA compliant model; has distinct container for config and state data
- Test against the YANG, at the moment just looking for schema compliance
- Lack of documentation
- Transport model is pretty abstract
- Don’t like the model be augmented; augment for vendor-specific is fine; try to define operational complete model
- Still try to align with OpenRoadm, but didn’t get far
- Optical model is still evolving
It was agreed that OpenConfig and TAPI appeared to be complementary.
- Action item - Nigel: Provide links of TR-512 v1.4 and presentations to Anees
- Action item - Nigel: Develop draft mapping of OpenConfig to ONF Core/TAPI
LTP Port + Port Spec and Spec Entry
LTP Port and Spec enhancements for “2.0”
- Preparing to make the change
- Add port to LTP for the function of LTP
- Motivation (use cases) of the Port model
- TAPI needs
- Photonic model needs
- LTP options consideration: (see slide 7)
- Option 5: Option 4 modified, don’t deprecate the old on; for simplicity
- Comment: Options 2 and 3 are the same in the surface,
- Action item - All: need to make decision
- LtpPort roles: (see slide 8)
- Action item -Nigel Davis: Change “PROVIDER” to “SEVER”
- Action item -Nigel Davis: Add roles MONITORING, OVERHEAD; (keep CONTROL and MONITORING separate)
- Action item -Nigel Davis: Add a figure to have the G.798 Points (TCP, AP, MP, RP, DP, TP, ...) to illustrate how the LtpPort & LpPort map into the G.798 xxxP; G.798 may benefit with updating. (NOTE: TCP=TerminationConnectionPoint, AP=AccessPoint, MP=ManagementPoint (Mgmt & Control), RP=RemotePoint, DP=DefectPoint, TP=TimingPoint; See Figure 14-64/G.798 & Table 14-30/G.798)
|3.2||Capability / Service / Need / Intent / Constraint … ||ND|
Slide: oimt2018.ND.036.00_CapabilityServiceNeedIntentConstraint .pptx
Expressing Capability and Needs
- General pattern of flow (slide 3: Capability,
Service, Need, Intent etc.)
- Action item –Nigel Davis: Add ControlConstruct as example of the party
- Recursive interaction
The term Service is unnecessary. General pattern. Separation of Service and Resource layers is unnecessary. Replace Resource and Service with Capability.
- Action item - Nigel Davis: Consider replacing the term "Party". Not to cause issue with the MEF term "Party"
- Action item - Nigel Davis: Analyzes if the general pattern description against the MEFconcept
- Action item - Nigel Davis: Engag with MEF to determine the term "Order"
- What we have in ONF (slide 5)
- Action item - Nigel Davis: need to look at the Resilience model in TR-512 v1.5 and/or v2.0
- Action item - Nigel Davis: On slide 5, put Control at the top of the slide, put Controlling in the last main bullet (regarding TR-512.8)
- Expression of Capability (slide 6)
- Focus on harmonization (slide 7)
- Action item -Nigel Davis: In addition to able to form a guiding meta-model with TOSCA, we should produce a TOSCA profile.
- Action item: Need PoC running code
- Progression (slide 9)
- Large amount of Type Spec. It might benefit from tooling
|3.3||Cloud Native (Kubernetes, Istio, Containers) (?) ||ND|
Input material for informaiton
Immutable data needs a (unique) immutable identifier !
Some good thoughts on the need for schemas
Data in SOA
Event Payload Protocols
Data-modeled, event-driven, network software is the answer
There is orchestration, but it’s a set of model-driven state/event processes. Same with management.
No amount of gilding of the device lily will make it useful, or even survivable. Abandon this old-think now, while there’s still time, or the cloud will roll over you.
The Evolution of Uber’s 100+ Petabyte Big Data Platform
Netflix Keystone Real-Time Stream Processing Platform
eBay Replatforming to Kubernetes, Envoy and Kafka
Cloud Native & Event Driven Solution
- Cloud Native (Task 54)
- Event driven solution investigation (Task 39)
Model Aspect Mechanism
Will Continue discussion in the coming OIMT calls
|3.4||ONF CONNECT|| |
TAPI and Core Model presentation in the ODTN session in ONF CONNECT (See https://www.opennetworking.org/onf-connect/schedule/)
Presentations and Videos of ONF CONNECT: https://www.opennetworking.org/onf-connect-2018-collateral/
- TAPI and Core Model are in the Optical Transport Track
TAPI 2.2 Connectivity: LLDP
Add LLDP support to TAPI to provide neighbour discovery between a router and a transponder of an Open Line System (OLS)
- How/where to attach the IEEE object classes to the TAPI OAM object classes?
- Answer: CEP. Further question is which CEP. To study.
- Is it possible to just model the snooping function without preventing the enhancement to the full IEEE functionality?
- Answer: Yes. The model must not prevent future enhancement.
- Is it reasonable to just model the snooping function?
- How to model more than one LLDP Agent per interface/port?
- Answer: To study. Note that in IEEE, a LLDP Agent handles only one LLDP level
TAPI 2.2 Connectivity: Resilience
|4.L||(1:30 - 2:00)||FQ (CMCC)|
SPN requirement on Information Model (Slides: Requirements for the SPN infomation modeling.pptx)
TAPI 2.2 Photonic: Connectivity
Slides: Photonic Model V15.pptx
Discussion agreed on the following terms
| ||TAPI 2.2 Photonic: Media Channel & Assembly||KS|| |
TAPI 2.2 Equipment
Review of work item XLS & F2F action items
Work items and deliverable plan
Action items: See the action items in this wiki page
|5.2||Future call schedule|| |
Consolidation of weekly call plan (TAPI, OTIM, OIMT, IISOMI)
- TAPI calls will be consolidated into 2 hours per week using the Tuesday IM-B & IM-C slots (i.e., 09:00 - 11:00 US Eastern Time)
- OIMT calls will be consolidated into 2 hours per week using the Thursday IM-D (06:00 - 07:00 US Eastern Time) & IM-E (08:00 - 09:00 US Eastern Time). Slot IM-F will be deleted.
- OT-IM's Tuesday IM-A slot be deleted. OT-IM topics will be discussed in TAPI IM-B/-C or OIMT IM-D/-E as needed.
- IISOMI Infrastructure and IISOMI UML-YANG Mapping will be consolidated into 1 hour per week using the Wednesday IM-H slot (08:00 - 09:00 US Eastern Time). The Friday IM-G slot will be deleted.
- Wireless Transport (WT) are welcome to join the TAPI and/or OIMT calls to discuss WT related topics.
The following table shows the consolidated call plan (effective from 2019) and also the call plan of rest of the month of December 2018 taking into account of call cancellation due to the year-end holiday season.
Action item - @Kam: Update the IISOMI Infrastructure, UML-YANG, and OT-IM wiki pages for call schedules and minutes linkages.
DONE; see Conference Call Schedule
| ||IISOMI administration|| |
Although the IISOMI Infrastructure Sub-team weekly call and IISOMI UML-YANG Sub-team weekly call are combined, they remain as two sub-teams. Only the weekly conference calls are combined. The minutes of the combined weekly calls will be posted on the Infrastructure Sub-team Minutes wiki page.
Action item - @Bernd: To create the format of the common minutes IISOMI_Call_181212. -> Done; see first common IISOMI minutes: 2018-12-12 IISOMI Meeting Notes.
| ||Future F2F meetings|| |
Proposed 2019 OIMT & OTCC interim meetings
- 1Q in Sydney Australia: March 18-22, 2019, hosted by Cisco. Confirmed.
- 2Q in China: May 6-10, 2019 (?), need host (Huawei? CMCC?)
- 3Q in USA (Santa Clara, California) September 9-13, 2019. Co-located with ONF CONNECT (September 11-13)
- 4Q in Europe, December 9-13, 2019 (Ciena London?)
| ||Editors and GitHub Adminstrators|| |
Guideline document new editors. Bernd will have new assignment. Many thanks to Bernd!
- TR-514 UML Modeling Guidelines: Kam
- TR-515 Papyprus Guidelines: Kam
- TR-531 UML-YANG Mapping Guidelines: Karthik
GitHub repository administrators: