Child pages
  • 2021 Sep 07-10 : OIMT Virtual Face-to-Face
Skip to end of metadata
Go to start of metadata

ZOOM URL: https://onf.zoom.us/j/84255643286?pwd=ODNqN3ZpN05CWHlZcSt4Y1FqeXdrdz09 (Same link for all sessions)

Meeting ID: 842 5564 3286 
Passcode: 081500 

Schedule

https://www.timeanddate.com/worldclock/converter.html?iso=20210907T100000&p1=5&p2=136&p3=tz_edt&p4=tz_cst-china&p5=250&p6=37&p7=215


Time-slot

Day 1

GMT Tue

7 Sep

Day 2

GMT Wed

8 Sep

Day 3

GMT Thu

9 Sep

Day 4

GMT Fri

10 Sep

Slot 1

6:00 am - 6:55 am EDT

  • Admin, welcome
  • Power Model Investigation
  • Control / Streaming Model,
    including ITU-T control arch/model
  • 1.5 Delivery Session
  • TIP / MUST - Optical Landscape
  • Release plan for 1.6+ part 1
  • Media multi-point model

  • 10 min break
  • 10 min break
  • 10 min break
  • 10 min break

Slot 2

7:05 am - 8:00 am EDT

  • Simplified Spec
  • OAM open discussion
  • External Bodies Landscape
  • Location extensions
  • Overflow
  • Release plan for 1.6+ part 2

Topics

In general we need to focus on agreement and actions :

Assigned to Slot

(Day.slot)

a or b for 1/2 slot

Topic TitleLeadLength requestedTopic 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 June 2021 vF2F 

  • Work Items updated for start of 2021.09 vF2F
  • Bubble chart updated per comments at the start of 2021.09 vF2F

Will be reviewed at the Fri 4.1b session

Tue 1.1b
  • Power Model Investigation

CH

30 mins

Task 76

ONF_T76_Power_Model.pptx

ONF_T76_Power_Model.pptx 

  • Traditional Functional concepts - slide 4 (Power supplier, Power consumer, & Power links). But these are really not what we want.
  • Physical Inventory - slide 5. The standard physical inventory model should be able to cover a lot of needs for PSE/PSU (Power Supply Equipment/Unit) and the standard equipment attributes, and do not need to repeat the modeling for these aspects.
  • Background research: slides 6 (IETF PoE management Yang), slide 7 (IEEE PoE Yang), slide 8 (OpenConfig Yang modules: PSU, access point, power over Ethernet), slide 9 (DMTF Redfish power distribution eqpt)  
    • Quite some commonalities but different groups have different focus - e.g., details versus specific
    • Chris' 2013 TMF work - slide 11 (TIP Redundancy Model Submission 1-2). Fairly opaque.
  • Intra/inter-Chassis power - slides 12 & 13
  • Power over Ethernet (PoE) - slide 14.
    • Note: PoE - Passes electric power along with data on twisted-pair Ethernet cabling.
    • CH: PoE should be looked at separately from intra/inter-chassis power.
    • ND: Usage of power might require Control and become more relevant, such as monitoring of power
    • MB: Ethernet already doing energy efficiency, thus has partially/completely shutting down. E.g., if the link is idle then reduce the bit rate of the link.
  • 2 Port Q-Bridge with PoE - slide 15.
    • CH: PoE is part of Ethernet and injected/extracted at ETY LTP. Not sure if it will overload the LTP concept or not.
    • MB: Should it be to the connector or LTP
    • ND: Power on the same wire is not uncommon. Could make it lightweight.
  • Site Power (slide 16). Agreed that this is out of scope
  • Unanswered Questions (slide 17)
    1. Do we want to represent chassis power cabling?
      • ND: Our model inherently has the capability to support this. No need to extend the model. Cabling and AccessPort seem to be sufficient. TAPI to determine if they want to use it.
    2. Do we want to use ConstraintDomain to group power providers and consumers?
      • ND: In TR-512.8 there is a diagram which shows several emerging functions that show the protection grouping (ConstraintDomain) of power.
      • CH: Makes sense to use CD 
    3. Do we want to directly relate power functions to Equipment?
      • ND: The model allows us to use Equipment to represent a lump of power stuff. If we want to build a model for power, such as monitoring etc., we could use Sensor, ProcessingConstruct, etc.
      • MB: We need to step back to ask ourselves what we are trying to do with the model.
      • MB: On the environmental aspect on power consumption, the model should link to how much is being consumed, link to the temperature 
    4. Is there any benefit in adding a Spec layer?
      • CH: This is about the power functionality, attributes related to power, voltage, current  
    5. How best to handle the input voltage and current to PSU?
      • CH: Cannot ignore power into the chassis. If stop at the chassis, need 1-ended PowerFeed.
  • Possible Spec attributes (slide 18, not complete)
  • Refactor Concepts - slide 19.
    • Try to get away from power supplier/consumer, which is a role or state and may change over time (e.g., rechargeable battery).
    • Use PowerFeed and PowerFeedEnd instead.
    • ND: Our Cable model is quite capable for modeling that.
  • Proposed Power Model (slide 20)
  • Examples (instance diagrams) - slides 21 (into backplane), 22 (out from backplane), 23 (chain together), 24 (Multi voltages)
    • MB: PSU's total input power is not what it is consuming, rather it is also passing the power on.
    • CH: Could measure what it is consuming and also what it is providing down-stream.
  • Proposed PoE Model (slide 25), PoE (side 26 in the presented version/[27 in the later on posted version]), PoE Example (slide 27/[28])
    • CH: Need to test if there is any benefit to involve LTP in the model
  • Law of Conservation of Energy (slide 28)
    • ND: Should be able to work out from the Spec.
  • AI - all To discuss the next step: Park it, or Stick it in a TR early draft document, or link to it from a Task (make it grey), .... Make sure not to lose it. 
  • Extra new slide added: PoE and  Connector Pin Strand (slide [26]). Linking PoE to LTP. Need to consider more on how to integrate into ConnectorPin and LTP. 
Tue1.2
  •  Simplified Spec
ND55 mins

Simplied Spec oimt2021.ND.004_Specification.pptx (version 2 - updated 20210907) 

  • (Note: The slide numbers in the following notes refer to the slide number of version 2 of the presentation slide deck.)
  • Spec recap: Invariants, Extension, Narrowing, Substitution, Combinations, Def traceability, Structures, Dynamic
    • Chris commented before on would like to understand which of these can be done in which standards and Yang
    • Thus here to address a few of his comments and try to improve the spec. 
  •  A simple example (slide 7). Comment on temperature sensor.
    • Nigel Davis  To look for an example that is more robust and compelling on the need of a separate occurrence. 
    • MB: The case to use the sensor of temperature to control the equipment. E.g., CPU of the computer.
    • ND: Sensor spec is more relevant than temperature spec.
  • Expanded Spec (slide 10) Compatible with Association.
    • ND: Need schema for expressing Type and value for Instance. Yang is an example useful schema language, and JSON is an example language for expressing the value.
  • Slide 11 (from Chris). Instance type based constraints. Possible solution. Expansion of (2) and (3).
    • Nigel Davis  In the "Instance type based constraints" sub-slide, there are the two levels - operational (black, first two rows) and knowledge/spec (blue). Add label.
    • Nigel Davis In the "Expansion of (2) and (3)" sub-slide, the two red "ConstraintedBy" associations are related to the red question marks in the "Instance type based constraints" sub-slide
  • Slides 13, 14, 15, 16, 17 address the slide 12 CH comment: "Are these YANG features? A table would be good to match with solutions".
    • Nigel Davis To extend from slide 17 to deal with the general property constraint and the constraint on localId
  • Spec recap (slide 18). Grey items - haven't be dealt with yet. Red items - have been dealt/looked at.
    • CH: Concerns on compatibility when changing API specification by augmentation for narrowing ... 
    • ND: Unavoidable in reality. Also there is standard way of specifying these. The Occurrence pattern requires to fill out the occurrences. Can fill out by using UML or Yang. UML needs to be encoded - such as into Yang 
      • Nigel Davis Lay out the spec model with sufficient occurrence pattern of equipment in it. Relate UML to Yang. 
      • 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.
  • Essential pattern (slide 21)
    • Compact form of that in slide 10. To see if any thing is missing in the general pattern.
    • Nigel Davis To compare the essential spec pattern in slide 21 with the current spec model to see if they align. Bring in the missing pieces, if any. Then set up the spec model diagrams and this essential pattern together so that they can be related. Also explain the general pattern of occurrence and provide the Yang. 
  • Final statement
    • ND has been working with Martin S, who thought the spec model is useful but got very little material to be used to meet with O-RAN. Martin agreed that we need to refine Yang itself to support this spec work and also agree to input to IETF.
Wed 2.1
  •  Control / Streaming Model
ND55 mins

Resource Recursion, Including ITU-T control arch/model and Exposure Context work

Streaming Model

Resource Recursion (oimt2021.SS-001-Controller-recursion.pptx) by Stephen Shew

  • Consider resource recursion in SDN controller, Client context, and Exposure context
    • Network resources and compute resources
  • Compute resources open questions (slide 7) and Compute resources in the control architecture (slide 2)
    • ND: No need to arrange the computer resources in a particular way (local, cloud, ...) - as long as they are connectable.
    • MB: Slide 2 is work in progress. There is a need to constrain the compute resource that a client context can use.
    • CH: Also needed from security consideration. 
    • MB: Quite comfortable on the need of the PEPs (Policy Enforcement Points) in the middle/interior, but not quire comfortable on how to define and specify them because there isn't an exposed interface. 
    • CH: The internal PEPs may just be filters, rather than a full PEP.
    • Agreed that this is an area that needs to be worked on.
    • MB: Regarding the compute resources, they could be local, remote in the cloud. Don't know don't care. The interfaces among the server context, local context, and client context are private.
    • CH: Recursion of VM has limitation on the number of levels due to efficiency consideration. Might be at most 2 or 3. levels deep. Rather might want to consider the group concept, to group the Client Contexts instead - resource pool; create group hierarchy.
  • Network resource recursion (slide 8) and Compute resource recursion (slide 9) 
    • Similar recursion patterns that lead to the proposal 
  •  Proposals (slide 10)
    1. Consider limited recursion of network resources within an SDN Controller.
      • Discuss whether to allow local network resources for CC and EC
    2. Consider limited recursion of compute resources within an SDN Controller.
      • Discuss whether to allow local compute resources for CC and EC
  • ND: Early draft of TR-512.A.15 "Controller Lifecycle & Security Consideration" has been liaised to SG15.
  • SS: Pool of distributed computer resources (VMs) implies networking among them.
  • MB: Compute resources are used to manage the transport resources that support the clients. If the compute resources are distributed, there are networking resources connecting the distributed compute resources and that needs to be exposed. But no need to expose the semantics of the control of the network resources that are actually sold to the clients. Need more thinking on this area.
  • SS: The brackets in slide 8 just for showing the recursion. It doesn't imply the SDN controller knows the details inside the contexts.
  • To the question for clarification on the first two bullets of slide 3, the discussion clarified that the SDN controller itself doesn't recurse. 


Streaming Model (oimt2021.ND.006_Streaming.pptx) by Nigel Davis

  • Malcolm Betts To look at TR-512.8
  • Nigel Davis  To change shared association between ControlConstruct & ExposureContext to composite association, and to change Log to StreamLog (because the log here is not traditional log).
  • Need to examine client/server interactions – How does the client process the stream ?
    • Mapping autonomous changes emitted from server into client objects: Partial vs. full updates e.g., Operational state change mapped into client instance…
    • Correlation of client request with response from server (“instant” e.g. config “delayed” – measurement job).
    • Adjustment of streamLog parameters based on back pressure from client.
  • Nigel Davis  To blend TAPI model of streaming with the Core model
Wed 2.2a
  • OAM open discussion
AM/
ND
30 mins

OAM oimt2021.ND.005_OAM.pptx

  • MEG spans a fragment of a ForwardingConstruct/connection
    • Regenerator in the middle of an optical connection?
    • MEG without a client connection in packet networks – client connections that will be monitored are co-routed with the MEG – MEG is a connection?

Continued discussion occurred in the Overflow slot (Thu 3.2b)

  • ND suggestions (not proposals yet): 

    • Mep & Mip augment OIMT LP
    • Meg ~ Fc
      • A grouping with directionality and flow in it.
      • FcPort is split - half & half 
    • Mep/Mip/MepMipList/Cep ~ LTP/Lp/FcPort
      • Mep, Mip, Cep are component Ltp
      • LtpHasComponentLtp
    • Not changing the core; Ltp gets MEP/MIP role


Wed 2.2b
  • External Bodies Landscape
Lyndon25 mins

External Bodies Landscape oimt2021.LO.001_OnfStandardsUpdate.pptx

  • O-RAN
    • WG10 OAM and Information modelling
      • Mix control and user traffic
      • WG10 Tooling for UML YANG
    • WG9 TAPI topology
  • OIF Interop testing – TAPI and OpenConfig
  • OIF AI/ML work
    • Application of AI/ML for Enhanced network operations
  • IETF
    • The CCAMP YANG models overlap with ONF
    • IETF TEAS IETF network slicing YANG
  • IEEE Future Networks Initiative
    • AI/ML, edge automation
    • System Optimization
Thu 3.1
  •  1.5 Delivery Session
ND55 mins

Version 1.5 Delivery discussion: OIMT document number allocation and Planning & Work Items

Nigel reported on the progress of preparing v1.5

Action items

  • Chris Hartley To review .13 Party and .14 Location 
  • Malcolm Betts  To review .3 and .17 States
  • Hing-Kam Lam Nigel Davis  (In separate call) To update the FE document to remove stuff already covered and refine other items as appropriate
  • Nigel Davis  Figure number alignment
  • Nigel Davis Hing-Kam Lam  Inter-document references 
  • Nigel Davis To share with CH the inter-document reference problem (relative references were turned into absolute references)
  • Nigel Davis  Generate PDF (last step)
  • Nigel Davis In the UML, prune out all the redundant diagrams. Still available in Git but not in the document
  • Nigel Davis To move the streaming model out from TR-512.8
  • Hing-Kam Lam Nigel Davis  To move all the diagrams into folders
  • Hing-Kam Lam To review DD to make sure each of the big sections are in place, no missing datatypes, just review the presence, no need of deep review.  
  • Nigel Davis To post the power point that summarizes the status of the progress (things that have been done and still to be done)


Thu 3.2a
  •  Location extensions
LN30 mins

Location extensions


  • LN recapped the feedback (Feedback on Location) from his colleagues who work on the GIS space.
    • In GIS, there are several standards on location and several projection options could be used.
    • There's always some form of interaction between the integrators - or reverse engineering - to determine additional formats or semantics that are not explicitly specified in the API definition.
      • CH: The intention of the Location model is to decouple one from that and can extend as needed.
    • Will get input from colleagues for drafting A.15
    • Location within location will be useful
      • CH: That can become very complex. Learned from experience should avoid that (recursive naming structures).
      • CH: Suggest to provide some examples in A.15 so that they can be looked.


Thu 3.2b
  •  Overflow
---25 minsSpare slot for any discussions that were cut short

Overflow discussion on Yang refinement control

  • CH suggestion: Tagging model with <<AllowRefine>> with specified refinement options
    • For example, for string length, options could be

  

  • Nigel Davis  Review IETF/IEEE documents and CH slides and merge as appropriate into simplified spec.


OAM open discussion - Notes captured in slot Wed 2.2a above.

Fri 4.1a
  • TIP / MUST - Optical Landscape
Arturo30 mins

TIP OOPT MUST: Telecom Infra Project Open Optical and Packet Transport Mandatory Use Case Requirements for SDN for Transport

Papers can be downloaded from

https://telecominfraproject.com/oopt/

ND: TAPI has a strong relationship with TIP OOPT MUST from an external perspective on TIP MUST. The TIP MUST operator community has chosen TAPI as the base model and OpenConfig for transponder model. Has provided TIP MUST the TR-547 use cases. Don't get full visibility of TIP MUST. The TIP OOPT MUST minutes are not public. We are not clear about their schedule of deliverable. We have asked liaison with TIP MUST so that we could be more prepared and proactive, instead of reactive, with TIP MUST. 

SS: OIF and TIP MUST have some interaction for the upcoming OIF 2022 demo. The OIF Interoperability Working Group is preparing for the 2022 demo. There is a desire in OIF to incorporate one or more of the TIP OOPT MUST use cases in the 2022 demo. The scheduled call with TIP MUST leadership has been postponed to Sept. 15. So no additional information to share at this point.

ND: There is OIF Security work, which Jonathan is working on. I assume the security requirements will also be included in the 2022 demo.

Arturo: Has postponed the meeting of this week to next week. By then will be able to provide info regarding the alignment among TIP MUST and OIF around the use cases developed in MUST. A focus of TIP MUST is on the definition of SDN architecture by operators involved, including standardization or adoption of standards to cover the set of use cases defined by the operators in the group. The group is organized into 3 work groups: IP, Optical transport, and Microwave. On Optical and IP sides, there have been already 2 different deliverables, addressing the set of use cases for IP and Optical northbound and southbound interfaces of SDN controller. These are available in public. (See the links below.) ONF TAPI was selected for the NBI from the Optical SDN controller. Planning to release a second deliverable on the NBI shortly, targeting by the end of this month, which will extend the use cases for the NBI, to try to come up with the latest TAPI 1.1 Reference Interface Agreement. The idea is that after these use case definitions are complete, will start the second deliverable development in TIP and will ensure ONF is invited to participate. Have already discussed with Nigel and the TAPI team to see how to share information from TIP with ONF in the near future, to have good cooperation to address the operator use cases that are not fully standardized yet so that TAPI can progress on the definition. There are conversations ongoing in TIP and ONF on license amendment to ease the liaison and co-operation between TIP and ONF. 

ND: 3-party Collaboration structure: OIF - testing, ONF - specification, TIP - enforcement of specification by MUST

Arturo: Documents there, use cases defined

ND: Question 1. On IP case. There is a touch point between Ethernet and IP. The controller will be controlling IP, Photonic and Ethernet pieces. How will the IP use cases and the preferred interface definition play with TAPI and where will that play? 

Arturo: Technical details will come from the IP side of MUST. Going to address the multi-layer use cases. DWDM and IP over Microwave. Will be part of the hierarchical controller definition. Will take the Reference Implementation Agreement for the different domains and try to put them in place. Not expect this to be straight forward. Need discussion with IETF, ONF, OpenConfig to align the model implementation. 

ND: Core model developed in this group (OIMT) is intended to be technology independent and provide a layer model that isn't TAPI but is related easily to TAPI and also to OpenConfig work easily. Having the Core model in background might help.

Arturo: Will be interested to have high level presentation on that.

  • Nigel Davis Hing-Kam Lam  : To put together material/presentation to be shared with Arturo and TIP/MUST. Will point out the relationship between the Core and TAPI etc. models. 

Arturo: Will inform the operators about this.

ND: Question 2: Also related to the Core model. The model provides representation of the control, how controllers interact, representation of software, etc.  Those areas may be of interest to TIP MUST and help resolve future challenge.

CH: We have done quite some work looking from different ways. The OIMT core model is more functional focussed.

ND: The TAPI physical model, CEP/NEP models are derived from the Core model.

ND: For hierarchical control, the control model draft document, forming of a view, that has been liaised to SG15. That might be of interest to TIP/MUST.

Arturo: Will try to make sure information flows. 

ND: Core model, principle, structure.

CH: Given a use case we could show how the core model meets the need of the use cases. 


TIP OOPT public documents:  https://telecominfraproject.com/oopt/ → Deliverable: 

That covers the use cases and reference implementation.

Arturo: Recommend to look at the white paper (in the deliverable page).

Fri 4.1b
  • Release plan for 1.6 and beyond -  Part1
ND/
KL
25 minsIncludes bubble chart + task list review

T63 is soft. To check if it is required for TAPI.


Fri 4.2
  • Release plan for 1.6 and beyond - Part2

ND/

KL

55 minsIncludes Summary

The work items, document list, and release plan (Bubble chart) were reviewed and updated.


(smile)


Attendees




  • No labels