| 2am PDT | 5am EDT | 9:00 UTC | 11:00 CEST | 12:00 EEST | 14:30 IST | 17:00 CST | 18:00 JST |
https://onf.zoom.us/j/853336915 -Zoom is blocked by more and more ITs.
Please use the following link: https://thorsten-heinze-telefonica-de.webex.com/join/andreas.lattoch.external
(please feel free to correct, update your names Thank you very much!!!)
|00:00||chair topic||no update|
2020-06-03: Martin Skorupski
2020-06-10: Martin Skorupski
2020-06-17: Martin Skorupski
2020-06-24: Martin Skorupski
Need for parallel configuration of transmitted-radio-signal-id and expected-radio-signal-id shall be avoided for simplifying configuration processes.
So in case AirInterfaceCapability::expectedEqualsTransmittedRadioSignalID==true, the AirInterfaceConfiguration:: expectedRadioSignalID shall be implemented like an unsupported attribute (always sticks with its default value).
The following changes have to be made on the modeling:
Decision: as proposed above.
Proposal to align modeling of AirEquipment with WireEquipment
(follow link to see the email)
A new document is available: https://github.com/openBackhaul/equipment/tree/tsp
under review 2020-05-27
AI all: please provide feedback in advance in written form using the change tracker. Please send beck to Thorsten by email - and cc the group.
Feedback from 3 companies - Thanks!!!
Updated document will be delivered by Thorsten.
Review session on the agenda for 2020-06-10.
VLAN Model with reduced scope.
review period for documents from last August will end 2020-06-09
dropping-behavior-kind on device/switch level - link to issue
AI: Danilo Pala, Michael BinderDaniela Spreafico: Please provide options how to solve the issue and a recommendation for discussion next week.
AI: Martin SkorupskiWork out a proposal to be discussed next week.
based on the proposal made in the issue:
further details should be agreed.
Conclusion during the discussion:
Switching the port by management interface → CoreModel solution is ForwardingConstruct with FC-Switch.
AI: Martin SkorupskiShow how this works with CoreModel 1.4
Status: discussion on-hold
core-model allows definition of both Logical Termination Points (interfaces), but also connections
core-model is also suitable for representing entire Networks, not only a Device
this means that Universally Unique IDs are required
Devices cannot get the UUIDs from outside, they need to be generated by the device, and cannot be overwritten from outside
Devices are unaware by their surroundings (the network), so it cannot know if a UUID is already used by some other interface in other devices
IETF defines how to create UUIDs, and the core-model references this RFC
Out of time, we need to follow up: proposal, next week Tuesday 09:00 CET
Discussion about UUID and Links/Asszosations/References between object classes
ODL MountPoint is and association to a NetConf server - some NetConf servers representing some times the microwave model.