| 6am PST | 6am EST | 10:00 UTC | 11:00 CET | 12:00 EET | 15:30 IST | 18:00 CST | 19:00 JST |
(please feel free to correct and update your names Thank you very much!!!)
|00:00||chair topic||no update|
Eduardo explained his proposal about how to describe firmware (https://groups.google.com/a/opennetworking.org/g/wireless-transport/c/3BJHnPa5PRU) and addressed a couple of questions to the vendors.
Continuing the discussion about firmware. NEC provided input and it was consolidated in the proposal.
How to activate a software package: leaf or RPC?
Discussions still needed, RPC is preferred, need to see how to model and how to integrate in our processes (Papyrus, UML2YANG etc.)
Alex Stancu to provide example from O-RAN FH model about how it is done in o-ran-software-management; then we can assess how we can adapt it to our needs.
SIAE is checking if RPC is feasible; Nokia will also do some checking. → maybe RPCs will be useful in other situations as well, we need to see
Do we need also a Download RPC? Probably. But this could be considered outside of the package model, does not really influence the inventory part.
Is ImageName (string) and ImageVersion (string) combination enough for uniquely identify a software image?
ImageSize proposed to be eliminated. No objections.
ImageClass - need tot see what happens if the case vendors do not support it; same for ImageIdentifier
ImageComparison proposed to be eliminated. No objections.
Need further discussions.
Parameter (status report and further discussion)
Package and Image class should inherit from GlobalClass - same as for Profile
|00:??||In VlanInterface historical-performance-data attribute name to be corrected|
The following issue incl. proposal has been introduced
Decision has been scheduled for 9th of December.
End of the meeting
Discussions to be continued:
|00:00||VLAN FC creation||Thorsten Heinze|
Creation of objects
S1 use case
new proposal by SIAE:
In order to provide to the application the "next" uuid an option could be the following:
1) Add in the model in the section "status" the "next-uuid" parameter
2) In case this "next-uuid" is influenced by some value: add in the section "configuration" the corresponding "influencer" values
i.e. with reference to the VLAN creation, in VlanFd we could have something like:
- In section "configuration": "next-vlan-fc-vlan-id"
- In section "status": "next-vlan-fc-uuid"
|00:00||Issues in General|
Use case discussion challenging the model proposal:
Please see updated slides (thanks Eduardo).
Feedback from vendors:
As a result of the discussion about Firmware, their might be a need for a "restart" trigger.
The "software activation trigger" usually also leads to a "restart" but with new software, which a "restart" reboots using the currently running software.
Other terms for the same? or similar? function:
|@Eduardo Yusta||License Management|
Please see email_
Please see related issues:
Please confirm by email to Martin Skorupski by end of this week (Nov6) that keeping FM and PM for xyzStructure is ok?
Status: positive feedback to keep it as it is:
Decision: we keep xyzStructure as they are and close the issues above.
|00:00||Centralize RMON counters|
Support is welcome to consolidate with respect to RMON
|00:00||Layering discussion (FCs, FDs etc.)||Thorsten Heinze|
Discussion and agreement about the following proposal:
The following aspects are proposed to be decided by the 5G-xhaul subproject.
- The ForwardingDomain shall be interpreted as a Potential for Forwarding (e.g. SDH Matrix).
[sko] Potential: something which allows the creation of “forwarding” based in the FD:LTP
- The ForwardingConstruct shall be interpreted as an Actual Forwarding (e.g. Connection between two VC-12 endpoints at the SDH Matrix).
[sko] Actual: configured Forwarding – check operational states and traffic flow
- There might be 0 .. * ForwardingConstructs inside a ForwardingDomain.
Discussion on dependencies between LTPs, FD, FC and between the layers will continue...