| 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|
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:
(follow link to see the email)
The deadline for commenting was reached yesterday. Thorsten Heinzewill consolidate the comments.
The application needs a clear reference between the LTP and where to interface it at the outside of the device. This number or text needs to be put into the model. The current proposal is to use the label attribute (either in equipment or connector). Michael Binder pointed out that label is used usually by the operator for other purposes and we should use the name attribute for our purpose. In the UML, name attribute has a multiplicity of min 1. We need feedback from Nigel Davis and Martin Skorupski to see which of the attributes (name or label) would be more suited. Email sent to Nigel about this is here.
LTP has an accessPort reference, and it is a reference to a pin group.
Equipment is referencing the connector.
We should not model all the pins and pin groups. We should model where the RJ45 or SFP should be connected. Proposal was to use the accessPort to reference a connector or we add a new attribute which references the connector.
Thorsten Heinze would prefer adding a new attribute "_connector", next to the "_accessPort", and keep the old "_accessPort" for referencing pin groups, if needed in the future. No other opinions.
Physical-port-reference in the LTP points to the equipment. Originally it is not pointing to the Equipment class, but it is a String. Question: use this attribute to point to the connector? or keep it pointing to the equipment. Or should we change it back to String and it should contain a label or a reference to a connector.
We need to define the option that we want to use. Thorsten Heinze, it should be as close as possible to the CoreModel, it will be better when updating to a new version of the CoreModel.
Maybe we should keep the physical-port-reference as a String (original definition) and use it to put the (label) text located on the outside of the device. This means we do not need to model the connector. @Pawel points out that we need to define what the String should look like, and all vendors should align in this regards. It should contain information about rack, slot, port etc.
Martin Skorupski Convert email into wiki.
VLAN Model with reduced scope.
review period for documents from last August will end 2020-06-09
Ongoing work - on Agenda of next weeks....
Martin Skorupski Add link to ongoing discussion...
on Agenda of next
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.