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-05-06 5G-xHaul Meeting notes

Skip to end of metadata

Created by Martin Skorupski, last modified on May 06, 2020

Go to start of metadata

Date

06 May 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 GCTIO
Hubing
Jorge Lopez
Jasper Yang
Ma Yong
Michael Binder
Nader Zein
Paul Parva
Pawel Krecicki
Petr Jurcik
Roberto Servadio
Shuzhan
Thomas Schulze
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-05-06: Martin Skorupski 2020-05-13: Martin Skorupski 2020-05-20: Martin Skorupski 2020-05-27: Martin Skorupski
00:10		Thorsten Heinze	Proposal to replace maxQueueDepth by availableQueueDepthList (follow link to see the email) For information only: Please see related issue. There is an action item to vendors to validate the proposed solution within the referenced email. closed! see description in the issue
00:08		Pawel Krecick	Proposal to align modeling of AirEquipment with WireEquipment (follow link to see the email) For information only: There is an ongoing action item to Martin and Pawel to develop the necessary explaining document for next week. Please feel free to review and contribute: https://github.com/openBackhaul/core/wiki/equipment-model-alingment Felix F. should be involved and will review. On the agenda for next Tuesday. Status: Discussion ongoing A single document is required: Please see: https://github.com/openBackhaul/core/wiki/equipment-model-alingment min 3 working days required for review → proposed doc on FR morning proposal to split the topic in smaller parts 1 equipment architecture single top-level-equipment (guideline how to use the model) holder OccupiningFRU LTP-> referencing to equipment co-channel-profile (xPIC) 2 dynamic management / instantiation behavior in case of real time management - synch between device and SDN-controller/NMS actual equipment - objects - changes needs to be notified Model: equipment object class sub object: actual-equipment sub-objects: expected-equipment Question: Does (container) equipment ALWAYS exists in advance before actual equipment can be instantiated? working assumption: yes (according to wire equipment) Once the actual equipment is plugged actual equipment is instantiated (software level) and notified to the SDN-Controller/NMS In addition in case of plug-and-play - a new matching expected equipment is also instantiated Please look for further details "wire-interfaces" ... further object creation of for LTPs and Pac are created. the creation of expected equipment drives the creation of further object (LTPs, ...) expected equipment can be created by plug-n-play via netconf request. as agreed for wire-equipment must be reused for air-interface equipment Problem: hardware dependent parameters - but no hardware wire-equipment solution: expectation about the hardware ODU equipment object expected equipment creation too many possibilities → a lot of data and different capabilities software version capabilities depend on current hardware but must depend only on expected equipment Proposal catalog lookup by mediator/device how additional data comes to the device. software upgrade external databases management interface pre-configuration of expected equipment same solution as above (once it is available) 3 parameters TO be continue
00:00		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. We think there are more attributes. On the agenda for tomorrow.
00:00		Thorsten Heinze	Default value for header-compression-name - link to issue Discussed and decided - please see link
00:00		Roberto Servadio	radio-signal-id: proposal of simplification - link to issue Answer: ??? to be discussed
00:00		Alex Stancu	pyang warning for must statement - link to issue Discussion: Decision:
01:11	Validation	Thorsten Heinze	Info: Profiles are now part of the interface validation. Preferred for next implementations: error-messages.

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