Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2020-07-15 5G-xHaul Meeting notes

Versions Compared

Old Version 5

changes.mady.by.user Alex Stancu

Saved on

compared with

New Version Current

changes.mady.by.user Thorsten Heinze

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

| 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

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

Info to: 

Goals

  • going forward

Discussion items

AI: Thorsten HeinzeA new issue item will be created for further discussion?
TimeItemWhoNotes
00:00chair topic 
no update 

00:00

Admin

Next meetings

2020-07-15: Martin Skorupski

2020-07-22: Martin Skorupski

2020-07-29: Martin Skorupski

2020-08-05: Martin Skorupski

00:10AlarmCapabilities

no alarm support by devices for (PureEthernet)Structure_PAC

  • Shall we delete all related object classes and parameters? 

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:15Identification 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

Proposal added to the TransmitterEquipment document

=> 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.
00:25TransmitterEquipment

Thorsten Heinze

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.

TransmitterEquipment_1.0.0-tsp.200715.1225+spec.1.pdf







@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:00VLAN

Thorsten Heinze

VLAN Model with reduced scope. 

review period for documents from last August will end 2020-06-09

Ongoing work...

00:00RMONAndreas Lattoch

Martin Skorupski Add link to ongoing discussion...





00:00dropping-behavior

Thorsten Heinze

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:

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. 

  1. A new profile type should be created, called "PROFILE_NAME_TYPE_DROPPING_PROFILE
  2. The profile details are just extensible ENUM (yang: identity) similar like "dropping-behavior-kind-type"
  3. ethernet-container-capability: available-dropping-behavior-kind-list will be of type "identity-ref" to the PROFILE_NAME_TYPE_DROPPING_PROFILE
  4. 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
  5. The pointers from ethernet-container-capability and ethernet-container-configuration allow the following use cases
    1. 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.
    2. Several Profiles with different configuration/behavior exists - ("static profiles"). Any configuration happens only by switching the profile.
    3. 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:00ComboPort

Roberto Servadio

See contributions:

Switching the port by management interface → CoreModel solution is ForwardingConstruct with FC-Switch.

AI: Martin SkorupskiShow how this works with CoreModel 1.4


END


0minUUID

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  

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