1. Pages
2. …
3. Open Transport Configuration and Control Home
4. 5G-xHaul
5. 5G-xHaul Call-in Details & Notes

2020-03-25 5G-xHaul Meeting notes

meeting times

issue - overlap with O-RAN WG9 Transport

the proposal is to move the meeting to one hour earlier 

Option #1: Current situation - keep it - 

today: 6am ONF time → 14:00 CET → 15:00 Israel standard time → 21:00 China

next week: 6am ONF time → 15:00 CEST → 16:00 Israel standard time  → 21:00 China

Issue: Nader, Alex, Petr are blocked

Option #2: Proposal from next week

next week: 5am ONF time → 14:00 CEST → 15:00 Israel summer time  → 20:00 China

Issue: There is an O-RAN-SC TOC meeting; blocking Alex Stancu, Martin Skorupski and Tracy

Option #3: Next proposal from next week

next week: 4am ONF time → 13:00 CEST → 14:00 Israel summer time   → 19:00 China

Issue: no participant form Asia and US

Option #4: Next proposal from next week

summer: 2am ONF time → 11:00 CEST → 12:00 Israel summer time   → 17:00 China

winter: 2am ONF time → 11:00 CET → 12:00 Israel standard time   → 18:00 China

Decision:

Propose to the group 2am Pacific local time.

summer: 2am ONF time → 11:00 CEST → 12:00 Israel summer time   → 17:00 China

winter: 2am ONF time → 11:00 CET → 12:00 Israel standard time   → 18:00 China

AI Thorsten: send email with the proposal to the group.

Meeting next week will remain ad 6am ONF time

next week: 6am ONF time → 15:00 CEST → 16:00 Israel standard time  → 21:00 China

2min

Use Case #1: config attribute is not supported by hardware - what should be the HTTP error code?

HTTP status:

• 400 (not found)
• 500 (HTTP server error)

NetConf error codes

• operation failed → mapped by ODL to HTTP 400 (not found)

Please see: RFC6021 for NetConf errors and RFC8040 for NetConf errors mapping to HTTP status.

Candidates on NetConf:

• operation-not-supported

Use Case #2: config an attribute name is not specified in YANG  (typo)

to be checked before decided

UC#1

• operation-not-supported should be reported on NetConf level

UC#2

• cant be influenced - because of the NetConf framework

AI: Martin/Lumina should address/check the mapping in ODL for the errors to HTTP status. 

core-model allows definition of both Logical Termination Points (interfaces), but also connections

• Forwarding Domain:
  • either connections 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