Child pages
  • 2021 Jun 01-04 : OIMT Virtual Face-to-Face
Skip to end of metadata
Go to start of metadata

ZOOM URL:  (Same link for all sessions)

Meeting ID: 965 9391 1973
Passcode: 083385



Day 1


1 Jun

Day 2


2 Jun

Day 3


3 Jun

Day 4


4 Jun

Slot 1

6:00 am - 6:55 am EDT

  • Admin, welcome, 2021 Work Plan
  • Aggregates Recap
  • Environmental and
    Physical Dimensions Sensors
  • Spec Pattern
  • OIMT Design Principles
  • Interface vs LTP

Slot 2

7:05 am - 8:00 am EDT

  • Control Model
  • Security
  • Assignment State
  • Security
  • Summary


In general we need to focus on agreement and actions :

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
Tue 1.1a
  • Admin, welcome, 2021 Work Plan
KL25 mins

Synchronized the work items with the Bubble chart from end of Dec. 2020 vF2F 

  • Work Items updated for start of 2021.06 vF2F
  • Bubble chart updated for start of 2021.06 vF2F

Review the work plan: Will be reviewed at the Fri 4.2 session

TST and ONF update: None

Tue 1.1b
  •  Aggregates Recap


30 minsGetting everyone up to speed on the topic.
Updates from the previous discussions.



  •  Control Model


55 mins

Nigel ran through oimt2021.ND.002_ControlModelAndSecurity.pptx. It presents a sketch of business cycle as a slab of functions. It is provided as a background for the Control Model consideration. 

  • ND clarified that "Equate" means Equate capabilities to the needs. Might better be "Equivalent", rather than Equality.
  • ND clarified that Analyze and Optimize are multiple. They span across the whole business cycle (Invent/Sell/Maintain).
  • ND noted that should not take the sketch literally, in particular the direction of "Loop". In reality, the flow is spiral. 
  • MB confirmed that the sketch of view building and resource allocation from the Control Intent and Capability Intent make sense (slide 8).
  • MB noted that the previously called Admin Port is actually doing two things: Administration and Contract negotiation.  
  • MB noted that here are two orthogonal things in the telecom environment: offering the telecom service plus offering the management capability

Malcolm ran through oimt2021.MB.003-Control-architecture-outline.pptx (see version 1)

  • JS commented that View translation still exists even though the translation might be null. (Slide12 case 5)
  • Confirmed that View translation is where namespace and identifier translation occurs.
  • Confirmed that Exposure context 1 and Exposure context 2 have their respective own clients. (Slide 12)
  • JS noted that security includes view translation aspects. (Client context construction Step 2 in Slide 14)
  • The idea of maximum transaction/operation suggests that, in addition to "slicing" the bit-transfer-resources, also slicing the compute-resources. 
  • Noted that the statement "A server context does not accept (management) connection requests" (slide 22 Security consideration) is a simplifying assumption.
  • JS commented that with the introduction of slicing, he is not sure using role-based access control is the most efficient way to describe the limit of the control, and ABAC is more efficient. MB disagree. Will have further discussion later.
  • Noted that the Server context of "Local planned resources" allows one to start setting up a client text for testing (e.g., in slide 12, EC 2 view 2, in Planned state)  and gives good decoupling. (Slide 26)
  • Noted that the in View translation 1 (slide 12), the local controller has the freedom of controlling the agreement states of the resources. 
  • Commented that support for brown field is more tricky. Noted that migration could be a multi-step process. Control task with temporal expression. Sequence of planned steps with temporal expression.
  • Look at PEP to build the trust boundary. Where to put the PEP (Policy Enforcement Point).
  • The Client admin PEP ensures the accessing of compute resources not to beyond the boundary of the Client admin EC. (slide 16)
  • The Resource allocation PEP ensures server context not to be swamped by the client context requests. 
  • Next step: A PoC trial on some of the key concepts.
    • E.g., Access control. Slide 22, last item.  
    • JS: RBAC might not be efficient. 
      • MB: In telecom environment, there are small number of roles and large number of objects.
      • Need more discussion.
Wed 2.1
  •  Environmental and Physical Dimensions Sensors
ND55 mins

Functional - Config and Readings

Optical Power

Building on previous contribution ONF_T58_Sensor_Model.pptx


Nigel ran through the slides.

  • Security


55 minsSecurity Direction and Plans

Malcolm presented further advancements in the work in oimt2021.MB.003-Control-architecture-outline.pptx (see version 2).

Malcolm noted the client context is only put in place when a trusted commercial relationship has been achieved. The environment is relatively closed.

Malcolm noted that the ExposureContext can last for a very long period of time.

Malcolm noted that there are few groups and roles. Chris agreed.

Jonathan asked whether slicing had an effect and increased the number of contexts.

Jonathan suggested that we need to look from the whole network point of view.

Malcolm pointed out that there can be 10s/100s of client contexts. Each client context may have a few roles.

Nigel noted that the client context is relatively small compared to the whole network. Malcolm agreed that if there are 100 slices each would be ~100th of the network.

Malcolm noted that the client context is not formed until there is a commercial trust relationship and negotiation is underway. If the negotiations fail then the client context is deleted.

Malcolm discussed the views that have a mix of real, emulated and planned resources.

Brief discussion on:

  • merging views etc.
  • migration plans and disruption minimization
  • Switch to current view
  • Illegal steps would be prevented from being migrated

Editor's note: Resource allocation ought to be through a view translation as the allocation may not be simple. 

Malcolm suggested that an NE may not need a PEP because it is in the operator's private network.

Andrea asked whether each green box represented a database.

Malcolm/Nigel noted that the green boxes represent data storage, cache or read-through.

Chris asked for an expansion of the diagram to show proxy objects. How many proxy objects levels are there? How many levels. 

Need to explore the various cases to determine where proxy objects and where there are read only views.

Nigel suggested that it is important to exercise the the diagram with specific cases e.g., of path computation to determine where the PEPs should. There may be several levels of PEPs.

  • Malcolm Betts Nigel Davis Exercise examples to determine PEP positioning... where do we need PEP.
  • Malcolm Betts Nigel Davis Expand on creation of compute/communications resources for the control environment. Also note how this model should be the same model as used by the client to control main network. Show how existing technologies for compute allocation would dovetail into this.
  • Malcolm Betts Nigel Davis Explore intent v write actions. 

Stephen/Jonathan indicated that they had no objections.

Agreed to cover assignment state followed by security/control in the overflow slot tomorrow.

Thu 3.1
  •  Spec Pattern
ND55 mins

Focus on Equipment Spec (+ Holder and Connector)

Including use of optional spec pattern

Prior Contributions :

Nigel presented oimt2021.ND.004_Specification.pptx (Simplified Spec). Note that the slides uploaded have been updated as a result of comments made during the call.

  • Spec recap: as background from
  • Considering Equipment and Sensors
    • A simple example
    • Expanding the example
      • Note: Each slot has two connectors (the blue rectangle)
    • Extract from the Occurrence Pattern PLoP paper
    • Spec in rough
        • To further discuss the direction of the Enumeration association. It may be reversed.
        • AM: When to use Spec ref (red)? And when to use Enumeration (blue)?
          • ND:
            • Spec ref (red) is still within the spec structure. It is kind of a sub-division of the overall specification. The association relationship is fix/rigid.
            • Enumeration (blue) is a list of alternatives. (In YANG, it could be Identity in instead of enum.) The orientation could be reversed. There is an dependency-boundary between the two association ends. It is more fluid, have different lifecycle.
        • AM: Still fail to see the standardization of information (Spec / Properties / Invariants / Rules) that may apply to a number of instances in the network. 
        • One UUID for the collection of BaseSpec/Properties/Invariants/Rules
        • To improve the terms:
          • Invariants → Type Invariants. Invariant properties of the type of instances. E.g., manufacturer code
          • Properties → Instance Property Definition. E.g., serial number
        • To improve the Key: JSON --> JSON value. Yang --> Yang schema
        • AM: Consider Connection End Point specification as another example, Time slot is an instance property.
        • To clean up: Type = "ABC", Manufacturer = "ABCD", 
        • To add more examples.
      • Partially updated figure
    • Action items - ND:
      • Nigel Davis To clean up slide 10
      • Nigel Davis To answer whether these properties are Soft properties or not?
      • Nigel Davis To write pieces of YANG and JSON codes with proper values and proper format.
  • General considerations (Not discussed)

On Friday

Nigel provided the YANG & JSON examples

Thu 3.2a
  • Assignment state
MB25 mins

Malcolm presented oimt2021.MB.002-Assignment-state-figures.pptx (version 2)

  • The objective to get okay from the team that this material good enough for writing up the first version for Draft TR-512.17 v1.5 soon
  • It is also needed for the control model
  • Ran through the 3 cases  
    • Case 1 - Permanents (dedicated) resource:
      • Added the "Client request" status to the PLANNED enum literal if allow client to create a planned resource
    • Case 2 - Fixed capacity shared resource
      • CH: Does it need the INSTALLED state as for case 1?
        • MB: In case 2, INSTALLED means to be long term, then go to PENDING_WITHDRAWAL when something is not normal, such as going to the end of the contract. In case 2, SCHEDULED_WITHDRAWAL might mean regular/periodic withdrawal.
        • CH: Okay. Expect text in the document to explain/clarify that.
    • Case 3 - Variable capacity shared resource
  • Example temporal expression
    • For a permanent (dedicated) resource shared by clients A and B
      • Note the possibility that the server may chose not to expose POTENTIAL_AVAILABLE capacity to a client even the resource is free.
    • For a variable capacity shared resource shared by clients A and B (CIR = Committed Information Rate)
      • Noted in the packet variable capacity shared resource example, in period 4, the CIR and PIR for Client A are zero, thus effectively the resource is not available to Client A, but is still shown in the variable capacity chart
      • Similarly in the TDM example, Client A has zero capacity in periods 3 & 4
      • These examples are kind of overlapping with Case 2 - Fixed capacity shared resource. So, wonder if we need SCHEDULED_WITHDRAWAL, POTENTIAL_BUSY, POTENTIAL_AVAILABLE, and just to simply use the Variable capacity shared resource for both cases if we can use the "0" allocation notion.
        • Discussion noted that there are distinction semantic between 0/0 CIR/PIR and deletion. For example, 0/0 may come back to non-zero, the contract may still be in effect.
        • MB: May swap the tables.
  • Agreed that Malcolm will start writing up the draft by using the presented material
Thu 3.2b
  • Security/Control
MB30 mins

Chris presented oimt2021.MB.003-Control-architecture-outline-CH.pptx,

  • It is his feedback on Malcolm's oimt2021.MB.003-Control-architecture-outline.pptx (see version 2).
  • Identifies areas that need to be look at in more detail
  • Feedback shown in pink
    • Slide 5: It shows the data plane (Devices X & Y) which represent the end points of the infinite recursion loop as shown in slide 4.
      • MB: There are "real" things in Devices X and Y
      • CH: Asked that if RBAC/ABAC already happens in the interface to client, does it make sense to also do RBAC/ABAC in the controller or not.
    • Slide 6
      • ‘Proxy Objects’ may actually be just entries in an Event Log
        • CH noted that we need to talk about Event Log. But not now.
      • Tenant is not equal to User
      • M2M interface means no UI
        • MB: This is an important point
    • Slide 14
      • Noted the adding of two PEPs in the controller
    •  Slide 15 Client Context restrictions
    • Slide 16 Distributed controller
      • Indicate places where for consideration for whether local or remote
      • MB: Need to keep separate: where we might want the remote thing and who has control of which bits of it 
    • Slide 31. Real objects added to devices
      • Question for discussion whether need the Proxy objects for the local resources  
        • CH: Should avoid proxy objects everywhere.
        • ND: Need rationale
    • Slide 34 State based security
      • MB: Some of the Update/Delete might in fact change the contract (needs contract negotiation).
    • Slide 35 Event vs Proxy Object API
  • Jonathan confirmed that the material, such as the state stuff, is helpful for the security consideration
  • Next steps
    • First to look at the local vs remote for distributed controller (slide 16). Where we might want the remote thing and who has control of which bits of it

On Friday

Chris presented additional updates/thought on Security/Control. 

Nigel provided feedback on Negotiation from implementation

Fri 4.1a
  • OIMT Design Principles
CH25 minsGeneral guiding principles for model design.

Chris presented OIMT%20Design%20Principles.pptx

  • There was general agreement on the Design goals/principles
  • Discussion items (see slide 8)
    • Generic vs specific models
      • Can’t optimize one model

      • Can always do separate optimal models, but then can’t put them all together (Integrate)

    • When should we have more than one representation ? (Bounded Context)
    • Some people see the commonality in everything – all is the same
    • Some focus on the differences
Fri 4.1b
  • Interface vs LTP


30 minsComparison of Termination Point to Interface models. Look at combining the IETF (Interface) and ITU-T (Termination Point) concepts in a meaningful way.Chris presented Interface%20and%20LTP.pptx
Fri 4.2
  • Summary
KL55 mins
  • End of vF2F bubble chart

    • Color code: Red means non-backward compatible change. Ignore the other colors.

  • Release date for v1.5: 
    • Nigel Davis  To provide a proposed date for Release v1.5
  • Proposed date for the next vF2F: September 7-10; 06:00 - 08:00 EDT daily
  • Next meeting (June 17) to summarize the actions, to priority topics 


  • No labels