Skip to content
Skip to breadcrumbs
Skip to header menu
Skip to action menu
Skip to quick search

Pages
…

Open Transport Configuration and Control Home
5G-xHaul
5G-xHaul Call-in Details & Notes

2020-07-29 5G-xHaul Meeting notes

Skip to end of metadata

Created by Martin Skorupski, last modified on Aug 05, 2020

Go to start of metadata

Date

29 Jul 2020| 2am PDT | 5am EDT | 9:00 UTC | 11:00 CEST | 12:00 EEST | 14:30 IST | 17:00 CST | 18:00 JST |

Web Conference:

~~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

Attendees

Alex Stancu
@Andreas Lattoch
Alok Surve
Daniela Spreafico
Danilo Pala
Daniel Perez Calvo
Eduardo Yusta
Hubing
Hsudarsa
Jorge Lopez
Istvan Vencz
Jasper Yang
Leo
Ma Yong
Michael Binder
Nader Zein
Paul Parva
Pawel Krecicki
Petr Jurcik
Prathiba
Roberto Servadio
Shuzhan
Thomas Seitz
Thorsten Heinze
Yossi
Martin Skorupski

(please feel free to correct, update your names Thank you very much!!!)

Info to:

Tracy Van Brakle

Goals

going forward

Discussion items

Time	Item	Who	Notes
00:00	chair topic		no update
00:00	Admin		Next meetings 2020-07-29: Martin Skorupski 2020-08-05: Martin Skorupski 2020-08-12: Martin Skorupsk 2020-08-19: Martin Skorupski
00:00	VLAN IF and Conection	Thorsten Heinze	UML Model based on ONF CoreModel 1.4 FD for VLANs → FD ↔ EthernetSwitsh FC for a single VLAN ID
00:00	VLAN	Thorsten Heinze	VLAN Model with reduced scope. review period for documents from August 2019 will end 2020-06-09 https://github.com/openBackhaul/vlanInterface/tree/tsp https://github.com/openBackhaul/vlanFd/tree/tsp https://github.com/openBackhaul/vlanFc/tree/tsp Ongoing work...

00:05	updated YANGs	@all	New yang modules in offline emails (Prathiba/Alex) Main changes yang 'must' statement for augmentation corrected (Issue 32) correction leaf-refs pointing the THIS LTP of the PAC Proceeding Wait for more updates and publish them together Candidates (ordered by prio): VLAN (discussion must finished) RMON (discussion must finished) Descreed config values in caps Alarm ComboPorts (maybe no impact?) Impact on Core Firmware (software-inventory) (concept open) Licenses (concept open) Augmentation of Equipment and Connector (decided) Equipment Alarm Management (concept open) Target: new yangs in about 3 month
00:18	RMON	@Andreas Lattoch	Related Contribution in Email from 2020-04-30 Latest discussions revealed the following documented issues: - https://github.com/openBackhaul/macInterface/issues/27 - https://github.com/openBackhaul/macInterface/issues/28 - https://github.com/openBackhaul/macInterface/issues/29 - https://github.com/openBackhaul/macInterface/issues/30 → all for issues on the agenda for decision next week 2020-07-29 - Please send comments to be addressed until 2020-07-27 - Thanks!
00:36	RMON	@Andreas Lattoch	Next https://github.com/openBackhaul/wireInterface/issues/31 - rxCollisions attributes to be added to WireInterfaceStatus and WireInterfacePerformanceType statistics - int64 performance - int64? Thorsten Heinze Preparation of calculation
00:53	RMON	@Andreas Lattoch	Next RFC2819 - no history Proposal: Moving from history to statistics
			MEETING ENDED
00:??	AlarmCapabilities	Thorsten Heinze	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: https://github.com/openBackhaul/pureEthernetStructure/issues/19 https://github.com/openBackhaul/hybridMwStructure/issues/22
00:??	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 While creating an instance of ControlConstruct or LogicalTerminationPoint, an instance of the NameAndValue datatype at the name attribute, which is inherited from the GlobalClass, shall be automatically created and filled with valueName:“externalLabel” and value: “”(empty String). After rebooting, the interface (e.g. mediator) the last configured value shall be represented again.
		@all	Procedure: NetConf filtering based on ODL RestConf implementation Active representation of the entire Network Planning representation of the Network requirement of database and ToplogyApplication as abstraction for app/µServices
	Wire interface errors in modelling leaf-lists in config and status	Thorsten Heinze Alex Stancu Martin Skorupski	Issues are documented in openBackhaul GitHub: https://github.com/openBackhaul/wireInterface/issues/27 https://github.com/openBackhaul/wireInterface/issues/28 https://github.com/openBackhaul/wireInterface/issues/29 https://github.com/openBackhaul/wireInterface/issues/30
00:00	dropping-behavior	Thorsten Heinze	dropping-behavior-kind on device/switch level - link to issue AI: Danilo Pala, Michael Binder Daniela 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: Proposal: The dropping-behavior-kind shall become part of a Profile, which can be instantiated multiple times, in case the device allows independently adjusting the dropping-behavior-kind per interface, or just a single time, in case the device allows adjusting the dropping-behavior-kind just on device/switch level. further details should be agreed. A new profile type should be created, called "PROFILE_NAME_TYPE_DROPPING_PROFILE The profile details are just extensible ENUM (yang: identity) similar like "dropping-behavior-kind-type" ethernet-container-capability: available-dropping-behavior-kind-list will be of type "identity-ref" to the PROFILE_NAME_TYPE_DROPPING_PROFILE ethernet-container-configuration: dropping-behavior-kind will be of type be of type "identity-ref" an entry in ethernet-container-capability/available-dropping-behavior-kind-list The pointers from ethernet-container-capability and ethernet-container-configuration allow the following use cases The EthernetSwitch (FD) allows only one Profile, all capabilities and all configuration are "static" because only one Profile exists. Any dynamic configuration happens in the Profile itself. Several Profiles with different configuration/behavior exists - ("static profiles"). Any configuration happens only by switching the profile. a combination of a) and b), which is not recommended due to unnecessary complexity. Conclusion during the discussion: investigate in adding another ethernet-container-capability attribute to express, if the LTP can, must, must-not follow the configuration on device (forwarding-domain?) level creating a device (forwarding-domain) PAC to uml:specify (yang:augment) ETH-Switch capabilities and configuration Further discussion on agenda for 2020-06-10.
00:00	ComboPort	Roberto Servadio	See contributions: https://wiki.opennetworking.org/download/attachments/265093121/ALCp2e_Equipment_Management.pptx?api=v2 https://wiki.opennetworking.org/download/attachments/265093121/ethernet-combo-port-as-fc-switch.pptx?api=v2 Switching the port by management interface → CoreModel solution is ForwardingConstruct with FC-Switch. AI: Martin SkorupskiShow how this works with CoreModel 1.4
0min	UUID		Status: discussion on-hold core-model allows definition of both Logical Termination Points (interfaces), but also connections Forwarding Domain: either connection inside the same device connections outside devices Link: any type of link, not only microwave Forwarding Construct: concrete forwarding between two or more LTPs / ports unidirectional / bidirectional 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 we need UUIDs for documenting the network we cannot write the UUIDs in the device, the device needs to create it the device does not have a network wide view this is needed because of the Planning the network Possible solutions: the device generates whatever, the IDs are retrieved and a mapping table is maintained we prescribe a method/algorithm that is implemented in the device for creating UUIDs (which become predictable): using some prefix which is known during the implementation time of the device - (e.g. MAC address of the Management interface); vendor sends info about Order no. and MAC addr. to the operator and the Planning will be done with these prefixed values → less complex than a field technician configuring the prefix on the device with some dongle fixed UUID with prefix and postfix Suggestions: use the Device name instead of the MAC addr. clean-up application that handles the changing of MAC addresses Out of time, we need to follow up: proposal, next week Tuesday 09:00 CET -- Notes from 08 Apr 2020 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.

Action items