1. Pages
2. …
3. OIMT
4. Meetings Calendar
5. Face-to-Face Meetings

2021 Jun 01-04 : OIMT Virtual Face-to-Face

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

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.

Prior Contributions :

• ONF_T56_Optional%20Spec.pptx
• ONF_T08_EquipmentUpdate.pptx
• oimt2021.LN.002-Equipment%20Type%20model.pptx

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
  • TR-512.7: Invariants, Extension, Narrowing, Substitution, Combinations, Definition traceability, Structures, Dynamics)
  • Progression of sub-setting - Constraining Semantics (oimt.2019.ND.012.01_SpecModelRework.pptx)
  • Target (oimt2020.ND.008-Spec.pptx)
  • Occurrence (oimt.2019.ND.019.00-Occurrence.pptx)
• 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 https://hillside.net/plop/2020/papers/davis.pdf
    
    • 
  • 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

• See slides 10, 11, & 12 of oimt2021.ND.004_Specification.pptx
  • 
  • 
  • 

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
  • Malcolm BettsTo write up the initial draft TR-512.17 for v1.5.

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. 

• See oimt2021.MB.003-Control-architecture-outline-CH.pptx (version 2)
  • Slide 5
  • Slide 36
  • Slide 37 Combined WAN (SP) and LAN (self) 
• MB: Options for handling request for additional resources: (1) need negotiation, (2) "Credit card" approach

Nigel provided feedback on Negotiation from implementation

• 
  • Nigel DavisTo provide description on Negotiation

• Summary

• End of vF2F bubble chart

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

• Release date for v1.5: 
  • Nigel Davis 17 Jun 2021 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