Child pages
  • 2018-12-03~07 OIMT & OTCC Joint Interim Meeting Notes
Skip to end of metadata
Go to start of metadata


  • 3-7 December 2018

Meeting Venue

  • 220 Humboldt Ct, Sunnyvale, CA 94089, USA
  • Remote participation URL: 

Meeting Host

  • Infinera



  • Reaching Out: TOSCA, ODTN (TIP & Photonic), OpenConfig
  • Core model: Compute/CPU/Memory, Storage, Spec, LTP port, Port Spec & Spec Entry, Capability/Service/Need/Intent/Constraint, Cloud Native
  • Guidelines & Tooling: UML, Papyrus, Mapping
  • TAPI 2.2: Photonic, Connectivity & multilayer & LLDP, Routing & resilience constraint, OAM, Equipment

Agenda plan



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.2Storage (Disk, LUN, ...) CH

Task 36a (see: ONF_T36a_Storage.pptx)

 CPU / MemoryCH

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
1.3Joint with ODTN on TIPSSL

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.4Joint with ODTN on Photonic use casesDV


Tooling + Guidelines


Latest draft of guidelines in progress

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
2.2Spec model application - general ND
  • Action item - Nigel: Light weight model, detailed invariant structure not included in the core.
  • Comment: FC Spec v1.4, don’t be over cocked.
2.3TAPI 2.2 Connectiity: Multi-layer / Layer-transition capability / Constraint AM/KS

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
2.4TAPI 2.2 (photonic) KS/SSL/AM/NDSlides: Facebook TIP L0 Model Overview 2018.pptx
2.5OpenConfigAnees Shaikh 


  • Currently OpenConfig capability

  • The roadmap of planned/speculative future capabilities in OpenConfig

  • What other open source groups OpenConfig is working with


Rough notes:

  • 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

Moving forward:

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
    • DONE
  • Action item - Nigel: Develop draft mapping of OpenConfig to ONF Core/TAPI

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
    • 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.2Capability / 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.)
    • 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)
  • 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.3Cloud 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


TAPI and Core Model presentation in the ODTN session in ONF CONNECT (See

Presentations and Videos of ONF CONNECT:

  •  TAPI and Core Model are in the Optical Transport Track

TAPI 2.2 Connectivity: LLDP



Problem Statement:

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


4.L(1:30 - 2:00)FQ (CMCC)

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 Photonic: Media Channel & AssemblyKS 

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.2Future 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!

GitHub repository administrators:

Action Items