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

2021 Sep 07-10 : OIMT Virtual Face-to-Face

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

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 10 Sep 2021 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. 

• 08 Sep 2021 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. 

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.)

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 25 Nov 2021 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 25 Nov 2021 To blend TAPI model of streaming with the Core model

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

• • Chris Hartley To send draft TR-512.15 Storage to ND

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 30 Sep 2021 To review .13 Party and .14 Location 
• Malcolm Betts 27 Sep 2021 To review .3 and .17 States
• Hing-Kam Lam Nigel Davis 30 Sep 2021 (In separate call) To update the FE document to remove stuff already covered and refine other items as appropriate
• Nigel Davis 30 Sep 2021 Figure number alignment
• Nigel Davis Hing-Kam Lam 30 Sep 2021 Inter-document references 
• Nigel Davis To share with CH the inter-document reference problem (relative references were turned into absolute references)
• Nigel Davis 05 Oct 2021 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 05 Oct 2021 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)
  • Posted at oimt2021.ND.007_TR-512Delivery.pptx

Location extensions

• Task 30: TR-512.14 "Location Model" for v1.5 (Chris)
• oimt2021.LN.003-Location model.pptx (6 May 2021)
• Feedback on Location correspondence (29 April - 6 May 2021)
• Task 75: TR-512.A.15 "Location Examples" for v1.6 (Leo)

• 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.

Overflow discussion on Yang refinement control

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

• • Another example
  • 
• ND: Another example is regarding Read/Write refinement.
• SM noted that IETF netmod is working on Yang versioning requirement, and have discussion on:
  • https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-05
  • https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-03
  • https://www.ieee802.org/1/files/public/docs2021/yangsters-smansfield-version-revision-0421-v02.pdf

• Nigel Davis 28 Oct 2021 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.

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. 

• • MUST IP Controller SBI Requirements: https://cdn.brandfolder.io/D8DI15S7/as/mfbj6nm7w38xnbvrmcnbp9t6/MUST-IP-Controller-SBI-Requirements-Document-v10_FINAL_VERSION_WEBSITE.pdf 

  • MUST IP NBI Technical Requirements: https://cdn.brandfolder.io/D8DI15S7/at/wq47398bnkjx48fw8pxmkk5/TIP_OOPT_MUST_IP_NBI_Technical_Requirements_Document_v10_FINAL_GREEN_PUBLIC_ACCESS.pdf 

  • MUST Optical Controller NBI Requirements: https://cdn.brandfolder.io/D8DI15S7/as/557f4z3n738v4cww28qjxh6/MUST_Optical_Controller_NBI_Requirements_Document_v10_FINAL_VERSION_WEBSITE.pdf 

  • MUST Optical Controller SBI Technical Requirements: https://cdn.brandfolder.io/D8DI15S7/at/pgnh4kq5fhbj56kwnfwn3r4/TIP_OOPT_MUST-Optical-SDN-Controller-SBI-Technical-Requirements-for-Open-Terminals_V10_FINAL_GREEN_PUBLIC-ACCESS.pdf

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 14 Oct 2021 : 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).

• Release plan for 1.6 and beyond - Part2

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

• Planning & Work Items
• OIMT document number allocation
• Bubble chart at the end of the 2021.09 vF2F meeting