1. Pages
2. …
3. OIMT
4. Core Model
5. OIMT minutes
6. 2018 OIMT Minutes
7. 2018-12-03~07 OIMT & OTCC Joint Interim Meeting Notes

Page History

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

Task 36a (see: ONF_T36a_Storage.pptx)

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.
  • DONE
    • Answer: No.
    • Current generators are: UML to YANG generator, and UML to OpenAPI generator

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

Reference Implementation for ODTN (See: Reference Implementations of Open Disaggregated Transport Networks)

• ONF ODTN Wiki: https://wiki.onosproject.org/display/ODTN/ODTN
• ONF ONOS Wiki for the "Device behavior calls":
  

https://github.com/opennetworkinglab/onos/tree/master/apps/odtn/api/src/main/java/org/onosproject/odtn

• To join: odtn@opennetworking.org

Tooling + Guidelines

Latest draft of guidelines in progress

• Draft_TR-514_UML_Modeling_Guidelines_v1.3.01.docx
• Draft_TR-515_Papyrus_Guidelines_v1.3.01.docx
  
• Draft_TR-531_UML-YANG_Mapping_Gdls_v1.1.01.docx

Presentation & issue discussion

• iisomi2018.BZ.011.01_IISOMI-GuidelinesOverview_December-2018.pptx
• 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

• Action item - Nigel: Light weight model, detailed invariant structure not included in the core.
• Comment: FC Spec v1.4, don’t be over cocked.

Slides: otcc2018.AM.003-Multilayer_Termination-22nov.pptx

• 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

Outline

• Currently OpenConfig capability

• The roadmap of planned/speculative future capabilities in OpenConfig

• What other open source groups OpenConfig is working with

LTP Port + Port Spec and Spec Entry

Slide: oimt2018.ND.019.02_LtpPortAndSpec.pptx

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
    • For examples, see Photonic Model V12.pptx slides 46, 47, & 48
  • 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)

Slide: oimt2018.ND.036.00_CapabilityServiceNeedIntentConstraint .pptx

Expressing Capability and Needs

• General pattern of flow (slide 3: Capability, Service, Need, Intent etc.)
  • Advertise
  • Negotiate
    • Action item –Nigel Davis: Add ControlConstruct as example of the party
  • Examine
  • 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)
  • Action item - Nigel Davis: Add Constraint
• 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

Slides: https://wiki.opennetworking.org/download/attachments/266141701/ModelAspectMechanisms.pptx?api=v2

Input material for informaiton

Data-modeled, event-driven, network software is the answer

http://blog.cimicorp.com/?p=3483

There is orchestration, but it’s a set of model-driven state/event processes. Same with management.

http://blog.cimicorp.com/?p=3430

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.

https://blog.cimicorp.com/?p=3581

The Evolution of Uber’s 100+ Petabyte Big Data Platform

https://www.infoq.com/news/2018/11/uber-big-data-evolution

Netflix Keystone Real-Time Stream Processing Platform

https://www.infoq.com/news/2018/09/Netflix-Keystone-Real-Time-Proc

eBay Replatforming to Kubernetes, Envoy and Kafka

https://www.infoq.com/news/2018/09/ebay-replatform-open-source

Discussion

Cloud Native & Event Driven Solution

• • • Cloud Native (Task 54)
      • Action item - Chris Hartley: To post the slides
        • DONE
    • Event driven solution investigation (Task 39)
      • Action item - Chris Hartley: To post the slides
        • DONE

Model Aspect Mechanism

• • • Action item - Chris Hartley: To post the slies
      • DONE

Will Continue discussion in the coming OIMT calls

TAPI and Core Model presentation in the ODTN session in ONF CONNECT (See https://www.opennetworking.org/onf-connect/schedule/)

• ONF Transport API: Opening up Disaggregated Optical Transport Applications
• ONF Core Model

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

LLDP

Problem Statement:

Add LLDP support to TAPI to provide neighbour discovery between a router and a transponder of an Open Line System (OLS)

Slides:

• • otcc2018.BZ.001.02_LLDP-TAPI.pdf
  • ieee802-dot1ab-lldp@2018-11-11.zip

Issues:

• • 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?
    • Answer: Yes
  • 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

https://github.com/OpenNetworkingFoundation/TAPI/projects/4

SPN requirement on Information Model (Slides: Requirements for the SPN infomation modeling.pptx)

• Interpretation of the color code (green/blue) on left side of Slide xx. Current assumption is that adaptation between adjacent layers of different colors means new and need to be addressed. Need confirmation from Weiqiang.

•  For information modeling, G.MTN part belongs to SG15. ONF should look into from where to get the SR-TP (Segment Routing in MPLS-TP) and L2 VPN information model, may work on it if not available elsewhere. L2 VPN is in IETF. 3GPP uses L2 VPN in mobile network. ONF investigate how 3GPP is using that.

TAPI 2.2 Photonic: Connectivity

Slides: Photonic Model V15.pptx

Discussion agreed on the following terms

• NMC is the intended spectrum band (frequency slot) for an OTSi
  • NMC is not a MC
    
• OTSiA: a group of one or more frequency slots reserved for a set of OTSi instances belonging to the same OTUCn, having an OTSiG-O
  
• MC is the result of spectrum configuration (filtering)
• MCA: one or more MCs that have the same route
• Is there overhead associated with a MC
  • ITU-T Standard: no (current text, MC has no monitoring capability)
  • Proprietary: yes
• There is no overhead associated with a MC

• A: Grouping that has the opportunity of having overhead

• Fiveconcepts related to carrying signal end-to-end

  1. NMC is the emergent effect of the serial concatenation, including any filters in the modulator and demodulator
  2. The spectrum allocated to carry an OTSi.
  3. The media channel resulted from the configuration of a filter. This is the frequency slot of the filter in ITU-T.
  4. The actual spectrum occupied by an OTSi signal
  5. The observation spectrum. This may be wider/narrower than the actual allocated spectrum.
• OTSiMC layer protocol qualifier defines the spectrum over which the OTSi is observed. The corresponding package will define the following attributes
  
  • Spectrum bandwidth: lower frequency, upper frequency
    
  • Power properties: total power, power spectrum density (PSD)

TAPI 2.2 Equipment

Review of work item XLS & F2F action items

Work items and deliverable plan

• Latest updated version per review/discussion: oimt2018.KL.001.11_oimt-work-items.xlsx

Action items: See the action items in this wiki page

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

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.

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?) 

Guideline document new editors. Bernd will have new assignment. Many thanks to Bernd!

• TR-514 UML Modeling Guidelines: Kam
  • Action item - @Bernd: Send latest draft TR-514 v1.3.02 to Kam -> Done; latest draft uploaded after the meeting as: Draft_TR-514_UML_Modeling_Guidelines_v1.3.02.docx
• TR-515 Papyprus Guidelines: Kam
  • Action item - @Bernd: Send latest draft TR-515 v1.3.02 to Kam -> No updates required; latest draft already uploaded before the meeting as: Draft_TR-515_Papyrus_Guidelines_v1.3.01.docx
• TR-531 UML-YANG Mapping Guidelines: Karthik
  • Action item - @Bernd: Send latest draft TR-531 v1.1.02 to Karthik -> Done; latest draft uploaded after the meeting as: Draft_TR-531_UML-YANG_Mapping_Gdls_v1.1.02.docx

GitHub repository administrators:

• EagleYangUml: vacant. Volunteer is needed.
  • The initial task of the administrator is to move the material from the (old) repository https://github.com/OpenNetworkingFoundation/EAGLE-Open-Model-Profile-and-Tools/tree/ToolChain/YangUmlTools to the new repository https://github.com/OpenNetworkingFoundation/EagleYangUml.
• EagleUmlOpenAPI: vacant. Volunteer is needed.
  • The initial task of the administrator is to move the material from the (old) repository https://github.com/OpenNetworkingFoundation/EAGLE-Open-Model-Profile-and-Tools/tree/ToolChain/UmlOpenApiTools to the new repository https://github.com/OpenNetworkingFoundation/EagleUmlOpenAPI.