Child pages
  • 2020 30 Nov & 2-4 Dec: OIMT Virtual Face-to-Face
Skip to end of metadata
Go to start of metadata

ZOOM URL:     (Same link for all sessions)

Meeting ID: 914 8259 4464
Passcode: 182466


In general we need to focus on agreement and actions :


Day 1


30 Nov

Day 2


2 Dec

Day 3


3 Dec

Day 4


4 Dec

Slot 1

6:00 - 6:50 EDT

  • Admin, welcome, 2020 Work Plan
  • Lyndon, update on TST and ONF focus etc.
Generalized Job/Task model (especially Control Construct)

Streaming, aggregates and document based store

(Cloud Native Architecture)

(Simplified) Spec model progress

Slot 2

7:00 - 7:50 EDT

  • Applying security to the Core model and TAPI Discussion
  • Applying the temporal concepts to the Core model and TAPI (event system)
Intent grammar - Broad discussion on possible ways forwardEthernet ExamplesPLoP Papers


Assigned to Slot


a or b for 1/2 slot

Topic TitleLeadLength requested
(full or 1/2 slot)
Topic DescriptionMeeting Notes
with Document Links
and action items
Monday 1.1
  • Admin, welcome, 2020 Work Plan
  • Lyndon, update on TST and ONF focus etc.
KL50 mins

OIMT work plan discussion

  • Nigel noted that there is a serious need for resources to pick up the editing work of the planned deliverables. 
  • Cannot decide on the time frame of the releases until the editing issue is resolved.
  • Agreed to modify the work plan
    • Release 1.5:  Will include T13a Model restructure packaging (with diagram cleanup) and Location & Party models only
    • The rest of the items for the original Release 1.5 will be pushed to Release 1.6.
  • Hing-Kam Lam Nigel Davis Talk offline for v1.5 publication
    • Option 1: Just Location (.14) and Party (.13), this can be 1/2021
    • Option 2: Some model structuring & key diagrams clean up, and Location and Party, plus a re-build of all the dot series documents (not rewriting the text), this needs a couple of weeks. 3/2021 
      • Aim for Option 2.
Monday 1.2.A
  • Applying security to the Core model and TAPI Discussion



  • Especially how does this apply to TAPI and hence what we need to close on in the core
  • Implications of secure transport for OTN especially how do we manage the keys for secure transport and indeed do we need to (in addition to management security)
  • Discuss FlexOsec and implications for core and TAPI.

Nigel shared oimt2020.ND.014-SecurityConsiderationsSketch.pptx

  • We cannot cover all aspects of security. 
  • Key aspects to be considered are listed in slide 2
  • Nigel Davis In the core model, to consider representing the encryption properties in the LTP
  • Nigel Davis (To make a proposal to initiate the discussion) To consider whether we need to form a task to work on the ControlConstruct for token processing, or just to note the presence of token processing (i.e., outside our space)
  • Nigel Davis To describe the architecture of view construction being carried out based on security consideration (authorization & authentication)
  • Different approach: ours vs IETF (dynamic view construction from deep complex filtering)
  • Security shell (surface) vs deep query
  • Nigel Davis To work on how deep in the control hierarchy does security go.  Two strategies to work on:  Understand the view at surface vs Query deep in the solution. Draw a few examples of the architectures and implication.
  • Multiple access could be done with multiple views
  • In summary:
    • Main area is View construction. 
    • For Token processing and Encryption, to acknowledge the requirements and point to where they are dealt with
Monday 1.2.B
  • Applying the temporal concepts to the Core model and TAPI (event system)



  • Brief presentation (CH)  followed by focused discussion on how we can apply some part to TAPI and hence what we need to close on in the core.

Chris presentation Temporal Expression ONF.docx

  • Paper is a re-submission of work done for TMF
  • To ensure TE are aggregate compatible, need to break up infinite recursion (Fig. 2)
  • Mentioned that TAPI needs TE for service
  • MB: Future connection request needs TE expression; compound expression on time; examples; needs to be able to set, check before needed,
  • ND: Need a particular resource with specific capability, a range of things,
  • CH: capability requirement within/outside business hours, TE defines the business hours
  • MB: basic TE is okay, how to use, 
  • Leo: How to express the state of the network, and plan resources, need follow up
  • ND: That is where TAPI comes in; mode of operation use the; Ask the controller provide multi options, time etc reservation, hold intermediate reservations, 
  • ND: committed future, potential future,
  • Physical connectivity is less dynamic in setting up & tearing down than logical/functional
  • CH: A lot to explore, nothing is concrete now,
  • ND: make TE depend on TAPI needs.

Wednesday morning (0:00 - 0:17) recap and action items:

  • Chris Hartley Use aggregates to break up TE infinite recursion and allow reuse of TE blocks
  • Chris Hartley Need to clarify how temporal expression could be used in TAPI for connectivity services. No particular time frame from TAPI. Aim for 2Q2021 in Core for TAPI in 4Q2021.
  • Chris Hartley Need compound temporal expression for compound events, to address cases with ranges of options & variations. 
Wednesday 2.1
  • Generalized Job/Task model (especially Control Construct)



  • Briefly present the generalized model (CH) and the core Control Construct Task (ND)
  • Focus on application to TAPI, especially OAM Job, to enable us to determine which pieces to close first in Core - purpose

Chris presentation ONF_T57_JobTask.pptx as background

Nigel presentation oimt2020.ND.015-ControlTask.pptx

  • OAM job fits nicely in the Task space
  • Task to create task
  • MB & CH: need to distinguish between Task pattern (Spec) and Task instances, lifecycle state of task (of the actual run). 
  • CH: Can compare this to the Software model. Software applications / inventory (definition) vs running software (providing functionality)
    • Nigel Davis To refine the presentation to account for the comments. To clarify/split the task of definition (meta data) and task of run (control). Need to distinguish task pattern (spec) and task instance. Task instance has lifecycle aspects. See if we can apply the pattern of the software model in the Task model regarding definition vs run.
    • Nigel Davis See if possible to have a general pattern (definition vs run) that can be used for deriving for Software (software inventory vs functionality) and Task. As necessary, refine the Software model. Document the pattern
  • There are constraint aspects of a task, e.g., complete in certain time limit.
  • There may be a requirement on measuring the performance/progress of a running task, so there is a task of measuring. Thus recursion of task. Try not to go too far.
    • Nigel Davis The overall solution should consider including events that trigger the running of task.
  • Control Task (TR512.8)
    • Different views of various aspects of a task; view mapping; 
      • Generation of event to notify the result/progression of task
    • Identifier of control task appears to be missing
      • Nigel DavisCheck ControlTask for presence of identifier and if missing add
  • Expressing a Task 
    • Recursive (task to achieve an intent (task))
    • Ongoing task (infinite lifetime);
    • Extreme short-lived task (may not worth to represent it)
  • OAM job
    • ND: Job is the definition of a view, 
    • ND: Should the CurrentData and HistoryData be separated from the OamJob?
      • AM: Agreement in MEF that the persistence of the CD and HD be consistent with the measurement job. Retained by the job.
        • ND: So the OamJob is the task plus the control construct.
    • ND: The composition (the CD/HD in OamJob) makes sense if the OamJob is the ControlConstruct with the Task and is owning the ExposureContext, 
      • Take insight from OAM Job for schedule, time range; to enhance ControlTask with Spec and time range, look for any feedback into TAPI oam job and also the Core model, to see whether need any further states in oam job.
  • Need definition of Job, Task, Workflow, 

Thursday morning 3.1 Chris provided as a wrap-up on Concur Task Tree

Wednesday 2.2
  • Intent grammar - Broad discussion on possible ways forward

Intent grammar (Domain Specific Language ?) - probably not as we need to get a better hook to pull this

  • Expressing constraints/possibilities over a machine interface such that we can apply to advancing TAPI ConnectivityService actions
  • Applies to all model aspects (physical/functional etc.)

Nigel presentation oimt2020.ND.016-IntentGrammar.pptx

  • ControlConstruct
  • Contract (Intent) grammar 
  • Considering the Core
    • Need a good way to express the occurrences of thing in the contact of the constraint in intent grammar
    • Need to bring in the temporal aspects
  • Considering TAPI
    • To explore expressing intent structure in terms of connection, NEP and CEP capabilities instead of a shadow service model
  • Related work
    • To look at TMF order, MEF?, TOSCA, IETF L3VPN, 
Thursday 3.1
  • Streaming, aggregates and document based store

(Cloud Native Architecture)



 (ND to do a few slides on the fast changing parts (config/state) and  #ShearingLayers ... also implication for TAPI).

  • Relates to cloud architectures
  • Relates to gNMI streaming
  • CH to present aggregate pack and relate to document store in principle (even if not used in practice)

Chris presentation ONF_T64_DddAggregates.pptx and blog site advancing-enterprise-ddd

Nigel presentation oimt2020.ND.017-StreamingMethods.pptx

  • Steaming in the context of cloud and gNMI
  • Core work (TR-512.10 Interaction) suggested focuses
    • For the state of the controlled system and state of task acting on the controlled system 
    • Interaction
      • CH: missing the Centralize vs distributed aspects
        • To include Centralize vs distributed in the streaming context
  • Stream strategies
    • View of the current TAPI messaging structure
    • Access & fidelity defined by ExposureContect
    • CH: Need more explanation on ExposureContext
      • ND: In TAPI is the TAPI context. It is the view of information about the controlled system made available through the port for a subset of the client. EC is not the view, it is the access to the view. It is the access control etc.
        • ND: EC is the access to the view (TR512.8)
          • Need more clarification on ExposureContext in TR512-8
    • Compacted log emulation 
      • change "simulation" to "emulation" in the slide
    • Nofify periodic: "change only" means delta from previous state/value
    • gNMI has three modes: Absolute of all, Absolute of the thing that has changes, Delta of the thing that has changes.
      • Add Delta to the list.
    • Client needs to know the reporting policy
      • Add "policy" to reporting characteristics
    • Synchronization
  • Stream message (see current TAPI model)
    • LogRecordHeader is meta data, LogRecordBody is the data
    • Policy of generating the notification at source
      • In the meta data of the StreamRecord, should identify the policy of generating the notification at source (i.e., what triggers the notification)
  • Model and alignment
    • Model 
      • Look for optimum stream arrangement regarding one big stream vs multiple streams
      • Include priority
    • Alignment
      • Time skew: multiple kinds of skew (not same magnitude of scale)
        • detection skew (time happened vs time detector registered it, +ve delay)
        • time stamping skew (time detector registered it vs time stamp value, +ve)
        • event skew (remote clock)
        • clock skew (local clock difference to remote clock, +ve or -ve)
        • reporting skew
        • received skew (time message received vs time stamp value, +ve)
      • Need to understand the order of magnitude of the skews
  • Snapshot via Get
  • Snapshot via stream
    • ContextControl: context definition 
  • Not presented:
    • General pattern sketch: not discussed
    • Have not gotten to the cloud architecture yet.
  • To progress TR-512.10 with the material

Friday morning: CH: regarding messaging, send whole message - aggregate makes more sense. If separate messages may cause alignment and consistency issues.  Local ID hard to identify if not in aggregate.

Thursday 3.2
  • Ethernet Examples
  • Review the examples, add material/description including attribute detail (from IEEE etc.)
  • Identify further useful examples to develop
  • Focus these examples on application to TAPI wrt major deployment pressures and also use in MEF
  • A.6 document

Kam presentation oimt2020.KL.005_ieee-bridge-representation.pptx

  • CH: slide 4 IEEE 802.1D/E bridge diagram, the data packet flow is across the bridge, but the control packet flow is between two separate bridges
  • CH: On the PB and PEB, the Open Config yang is much simpler and modeled closer to device implementation. It will be interesting to compare the two approaches.
  • CH: May need to modify to fit into the Core model.
  • Next step:
    • To analyze the material to see what to do for:
      • Core TR-512.A.6
      • TAPI 
        • AM: Current OAM is based on both ITU-T and MEF requirements 
          • When reviewing TAPI connectivity service model, to perform gap analysis. (1) Anything in G.8052.1 UML/YANG is new to current TAPI or just re-factoring. (2) Any bridge component aspects are missing in TAPI?

Friday morning: CH: Open Config yang is port-based; IEEE yang is component-based - has the extra port-connection and that may be a limitation.

Friday 4.1
  • (Simplified) Spec model progress
  • Present and discuss next steps
  • Assemble the pieces to form a coherent picture
  • Consider the ITU-T challenge of describing constrained usage of a general model for implementations with different ranges of configurability (including none). Key example is the photonic model work.

Nigel presentation oimt2020.ND.018-SimplifiedSpec.pptx

  • The simplification is specially focused for TAPI
  • Specs  
    • TR512.8 stack of controllers,
    • representation/determination of state
    • In TAPI relating to Control spec, the only example today is the IP address of the NE. The NE IP is not a spec but just an instance. It is the IP address of the ControlPort on the ControlConstruct that runs the device.
    • In Core
      • Broader work is needed in Core (red)
    • Core abstract, TAPI implementation
    • TMF SD1-36 SNCTypes spec
    • Photonic specs deep complexity, FC spec and Ltp spec both inside each other
    • Transport FC (blue)
      • Look for reduced spec for TAPI
    • In TAPI, we don't explain what connectivity service can be created.
      • Would be a connectivity service spec also
  • Sketch of dependency
    • Arrow indicates the order
  • Potential Focus
    • (The list is not in priority)
    • Looking at the general spec structure model with occurrence play in it in a TAPI context
      • Will share the general spec structure model when it is ready
    • It is very hard to separate the rich inherent complexity from the accidental complexity (don't understand the problem properly)
      • To start in Mid-January in an OIMT brainstorming session on modeling of Occurrence (in FC spec)
    • LTP
      • To describe the overall lifecycle of the specs: how the spec is created, how is it to be published, etc.
        • To look at the Spec Lifecycle presentation slide pack used in the Core Build event
      • Need to understand what we mean by the Value-Justify step 
        • Need to consider the criteria of being successful, then try to layout the steps, 
      • Try to layout for a particular small part of the consideration (of slide #3), then set real value of the trial
    • Leo: step by step approach with limited scope
      •  Lay out the path so that know where it leads to
    • AM: TAPI is doing something similar - the use case based approach, with limited scope 
    • Reference implementation statement
    • FC Spec: 
      • Need to look at TMF SD1-36 SNCTypes to see whether it is critical to do the actual detailed layout 
      • Need to look at adding specific FC scheme spec, such as 3R 
    • FD spec
    • The TAPI FD spec doesn't identify the supported FC spec 
      • Need to look at identifying the supported FC spec of the FD
  • Next step
    • Reduce the action
Friday 4.2
  • PLoP Papers

PLoP papers (

  • Occurrence pattern - Nigel
  • Abstract graph - Chris

Chris presentation An Abstract Graph Pattern (Done on Monday 1.2)

Nigel presentation Occurrence - A Knowledge Layer Pattern

LN: kind of equipment library

AM: In MTNM the potential CTP, potential for multiplicity; building the shadow model

ND: pattern of supporting potential CTP

  • Summary
KL60 mins
  • End of vF2F bubble chart
  • Next week to summarize the actions


  • No labels