| 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|
no alarm support by devices for (PureEthernet)Structure_PAC
Latest testing showed that none of the devices under test is supporting alarms in the PureEthernetStructure and the HybridMwStructure.
Vendors not participating in the tests also confirmed that their devices don't implement alarms on these interfaces.
It should be considered to remove all attributes, data types and classes related to alarming from the PureEthernetStructure and the HybridMwStructure modelings.
Thorsten Heinze created the following two issues on the openBackhaul Github for being discussed and decided before the next update of the respective modelings:
|00:15||Identification of Object instances||@all|
How to align between Controller/Apps/Mediator/Devices?
Please see related email: https://groups.google.com/a/opennetworking.org/forum/#!topic/wireless-transport/daCPBnPKJzo
Feedback from vendors available
=> Vendors confirmed to be able to store an external equipment label and an external interface label on the device.
The following text has been added to the TransmitterEquipment document:
ControlConstruct and LogicalTerminationPoint
Please see related email from 2020-05-14: https://groups.google.com/a/opennetworking.org/forum/#!topic/wireless-transport/m9PWypPwZKQ
Please see related document: https://github.com/openBackhaul/equipment/blob/tsp/TransmitterEquipment_1.0.0-tsp.200702.1720%2Bspec.1.docx
Can we release the document?
During the latest two weeks review period, only one feedback has been provided and consolidated into the document.
During the parallel meetings, no further need for clarification has been communicated.
As upfront announced, a voting over accepting the document has been held (represented vendors: Ceragon, Ericsson, NEC and SIAE).
Nobody disagreed to the TransmitterEquipment specification. Everybody agrees to the current version of the document. Formal decision was made to adopt this document.
Procedure: NetConf filtering based on ODL RestConf implementation
|Wire interface errors in modelling leaf-lists in config and status|
Issues are documented in openBackhaul GitHub:
VLAN Model with reduced scope.
review period for documents from last August will end 2020-06-09
Martin Skorupski Add link to ongoing discussion...
dropping-behavior-kind on device/switch level - link to issue
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.