Skip to end of metadata
Go to start of metadata

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

TimeItemWhoNotes
00:00chair topic 
no update 

00:00

Admin

Next meetings

2020-05-20: Martin Skorupski

2020-05-27: Martin Skorupski

2020-06-03: Martin Skorupski

2020-06-10: Martin Skorupski

00:05

Pawel Krecick
Thorsten Heinze

Proposal to align modeling of AirEquipment with WireEquipment

(follow link to see the email)

A new document is available: https://github.com/openBackhaul/equipment/tree/tsp

under review 2020-05-27

AI all: please provide feedback in advance in written form using the change tracker. Please send beck to Thorsten by email - and cc the group.

Support of Software and License → goes to several manufactured-things 

  • Do we need to categorize the manufactured-things?
    • which is the yang key: proposal: new attribute as the manufactured-thing does not "use" CoreModel:GlobalClass or CoreModel:LocalClass
    • would need a new attribute on core-model
    • The "correct way" is to reuse software-management of the core-model, which is not in yang yet due to pruned "DomainContrains"

Conclusion:

  • contribute to CoreModel a LicenseModel
  • For now LTP creation and its Capabilities depend only on 1 manufactured-things of the ExpectedEquipment.
  • TransmitterEquipment - should be updated according to the conclusion - later it needs to be updated once the model for firmware/license is stable.
  • for now: interface capabilities will reflect "only"  the equipment capabilities - not software and not license capabilities - operators needs to be aware the consequences.

00:10


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

dropping-behavior-kind on device/switch level - link to issue

AI: Danilo PalaMichael 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: 

PROPOSAL OF SIMPLIFICATION
In case expected-equals-transmitted-radio-signal-id=true the proposal is the following:

  • configure radio-signal-id sending only transmitted-radio-signal-id
  • leave expected-radio-signal-id with his default value -1.
  • in case of a configuration attempt on expected-radio-signal-id reply with:
    "operation-failed" and
    "#[onf:Attribute/feature not supported by the hardware.]#"


I am supporting this proposal and I am proposing to amend the comment of the expectedRadioSignalID attribute with the following additional phase "Only relevant, if expectedEqualsTransmittedRadioSignalID==false. ".


Should be agreed: 2020-05-27







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