Note that the meeting plan is at the end of these minutes.
10 min
Malcolm/Nigel
Report on TR-512.A.15 progress
Nigel and Malcolm reported that they met and now know how to describe the link. In the diagram the link is dawrn in the misleading place. Need to breakup the drawing so that it can be more interpretable.
Now realize that the ClientContext and ServerContext relationship is logically 1-1, but the ServerContext may be distributed in implementation and thus physically the relationship is 1-n. but logically still 1-1.
Server side to responsible for ensuring all the information of the resources are reportable to the client side.
So, in term of streaming, the server must support all the streams providing the information.
Server should provide a catalog of streams that the client can choose from, and not to allow the client to create streams on the fly.
Profiles. Examples: Physical inventory stream; Alarm stream; etc.
Server KPI. Client to filter it.
There might be circumstances that the client could be allowed to create a stream for itself, but that doesn't override the stream the server provides, and the client is required to pick one of the profile that ensures it gets all the information.
Client may partition.
Eg. Running a PM, client lost something and wants to get a particular record; Spotlight
Compaction. E.g, if the client crashed, it can reconstruct the data from the compacted stream, but may not get all the history. This should be part of the PKI in the agreement.
Stream aspects need to be captured.
Nigel DavisMalcolm Betts Provide write up of ClientContext and ServerContext relationship. Update A.15 with this text.
Also provide plan for completion of .A.15 in conjunction with plan for .8
5 min
Kam/Nigel
Report on TIP MUST action discussion
Nigel & Kam to put together material/presentation to be shared with Arturo and TIP/MUST to determine whether this is still relevant. If still relevant, will point out the relationship between the Core and TAPI etc. models. Action item from2021 Sep 07-10 : OIMT Virtual Face-to-Face
Propose to wait until TR-512.8 (Control) with streaming stuff of TR-512.A.15 (Controller lifecycle & security) are ready and then prepare the guidance/tutorial material (in parallel with preparing the publication) for liaising to TIP/MUST.
Nigel DavisHing-Kam LamPlan the delivery date for the TR and hence for the TIP/MUST tutorial work.
Actions in black,action responses in blueandmeeting notesfrom in green andmeeting notes from in red
Task
This was not covered onand will be added to the agenda for
Nigel DavisDefinitions of task using Component-System principles (explaining the distinction) and show clear boundaries. Say what a task is and what not. Define recursion. Emphasize reuse. Place orchestration on a figure.
Component-System pattern as described in TR-512.A.4 (v1.5)
Various other considerations...
Use specialized term "ControlTask" to avoid terminology confusion
ControlTask: A definition of activity of a functional Component {hence it is opaque} that provides management-control capability.
By "activity" I mean externally visible behavior. Transfer function perhaps gives a better feel.
I am considering the Task as the definition here, but we may want to have an instance of running task and hence make it a thing with a definition.
Use "Transfer Functions"
Agreed that the following is sufficient for now
ControlTask: A functional Component that provides management-control capability where that capability is defined in terms of transfer functions.
As it is a Component, as described in TR-512.A.2, it:
has inputs and outputs
can be adjusted with policy and controls
In the case of the control task, these are all externally visible and provided via inputs.
has internal workflow
is described in terms of subordinate components
is... etc.
ControlTask capability (collection of transfer functions) is defined from the outside and hence its description does not vary due to internal hidden control
Other components expose capability that is defined from the inside.
To further clarify the component based definition for ControlTask...
It may take a set of inputs, process them, provide a set of outputs then complete/terminate.
The outputs may all be at the completion of the task or some may be at intermediate points
The outputs may directly update system state or may be streamed for use by other components
The inputs may all be available at the start of the task or they may be available at various points
The task will be initiated by the occurrence of some condition (trigger)
The inputs may be from monitored state or monitored stream
The task may pause to wait for an input, abandon if it does not have an input, skip the input etc.
It may run
as a single activity that terminates once complete
continuously with internal loops until requested to terminate via some state input
It may express its capability in terms of apparent control task flows that explain, in abstract, how the outputs are generated from the inputs
This is the definition of the transfer functions.
A structure of apparent encapsulated ControlTasks with some stated flow
A flow may have loops etc.
An apparent ControlTask may have its capability expressed
It may express its capability in terms of a transfer function or some other structure that is not of a task form
It may be realized by subordinate control task flows
A structure of real control tasks with stated flow
Flow is determined by trigger conditions that are caused by outputs from other tasks
Split is multiple tasks watching for the same trigger condition
Join of two requires two specific condition outputs (one from each) to cause the trigger condition
Alternative depends upon an output value
It may be realized by code (algorithms etc.)
There will be no deeper view of realization
There may be an expression of capability in terms of apparent encapsulated tasks with some stated flow
Multiple instances of a specific type of ControlTask may run at the same time
A ControlTask instance will be running in some specific instance of flow and will be related to instances in the same instance of flow (needs more work here)
Discussion STOPPED HERE
Nigel DavisHow the orchestrator interprets complex tasks with intermediate outputs with loops etc.
As above, the ControlTask is defined in terms of apparent ControlTasks
Clearly a ControlTask is designed and is potentially designed for both the provider ControlConstruct and client ControlConstruct (Orchestrator)
The Orchestrator may already be capable of dealing with the task in a hard coded way
Nigel DavisExample of a complex task description in terms of an abstract workflow with intermediate output and loops etc.
Nigel DavisWork a definition set for the "Task" space accounting for the fractal nature and the Component-System pattern aspect. Deal with "triggers" (events etc.), constraints etc.
See above
Nigel DavisSet out some meaningful examples an interaction of "Tasks" to achieve some relevant outcome (e.g., service creation, restoration...). Note that the action "Nigel DavisTo study the boundaries of Job/Task, ControlConstruct, PC, CASC (algorithmic). Consider path computation as an example.Action item from2020 OIMT Virtual Face to Face - Week of April 13" should be covered by this action.
See above
Note that the ControlTask:
may be run as a PC or within a PC with other Tasks where that PCmay be implemented with software running on one or more equipments as per model
may be initiated by a ControlConstruct or CASC which which is implemented as software running on one or more equipments
Nigel DavisProvide a mapping from "Task" terminology to other terminology sets (e.g., Use Case, Workflow...)
TBD
The following agent item was not discussed on due to lack of time and will be added to the agenda for
Spec model review and agreement
Nigel Davis Take the spec model, prune out the stuff that are not relevant to simple layer hierarchy, look at how to apply the general principles (slide 32) notation to the stack of layers & rules, write it in the context of the original spec structure.
Nigel Davis Construct simple spec example using layer hierarchy model for the OTN payload structure, try longhand form, correct number of occurrence set, based on some specific ports. Code it in JSON form of YANG. Note that the action.
Action items re-dated
The following are proposed dates for the past actions. The action list has been updated to reflect this. The actions can be reverted/adjusted as necessary. Only actions that have been moved are listed.
Nigel DavisCover combinatorial rule for layer protocol options. "And" & "Or" in spec language.
Nigel DavisTake the spec model, prune out the stuff that are not relevant to simple layer hierarchy, look at how to apply the general principles (slide 32) notation to the stack of layers & rules, write it in the context of the original spec structure. Note that the action "Nigel Davis To prune out the unneeded stuff from the current Spec document so that to show the Yang "when" and "must" of the Occurrence pattern. Action item from2021 Sep 07-10 : OIMT Virtual Face-to-Face" is covered by this action.
Nigel DavisConstruct simple spec example using layer hierarchy modelfor the OTN payload structure, try longhand form, correct number of occurrence set, based on some specific ports. Code it in JSON form of YANG. Note that the action "Nigel DavisLay out the spec model with sufficient occurrence pattern of equipment in it. Relate UML to Yang. Action item from2021 Sep 07-10 : OIMT Virtual Face-to-Face" is superseded by this action.
Nigel Davis Construct draft temporal model document
Correct errors in the temporal model instance example
Consider model addition to allow IncorporatedTe to also be a contained TeElement (not reusable) to remove need for additional TemporalExpressions.
Better describe union and intersection rules (same type unions and different type intersect)
INTERSECT_COMPLEMENT should be two properties (TE incorporation union/intersection and Complement referenced TE true/false
Nigel Davis Make corrections to the streaming model as discussed including
Corrections to comments from meeting
Multiplicities around StreamHandler
Nigel Davisadd missing information flow corresponding to (2a) in Agg/Component diagram
Nigel DavisApply delegating root stereo type to ports in the model and prepare brief refactoring of LTP port applying the delegating root.
Nigel DavisMartin Skorupski To prune/clean-up LTP and FC model into two interrelated small models (aggregates) and then generate YANG from them.
Nigel DavisAndrea MazziniReview first draft of skeleton OAM document and determine whether content can be partitioned between AM and ND. Aim for 1.6 release.
Nigel Davis Review draft Temporal Expression document. Note that the action "Nigel Davis Draft temporal expression document" is covered by this action.
0 min
Next calls
Plan
Meeting planning proposal (where each meeting will deal with the corresponding actions (with the date of the meeting)):
