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

Versions Compared

Old Version 3

changes.mady.by.user Martin Skorupski

Saved on

compared with

New Version Current

changes.mady.by.user Martin Skorupski

Saved on

Key

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

Date

 2am PDT → 5am EDT → 11:00 CEST → 12:00 EEST   → 17:00 CST

https://onf.zoom.us/j/853336915 (https://wiki.opennetworking.org/login.action?os_destination=%2Fdisplay%2FOIMT%2FConference%2BCall%2BSchedule)

Attendees

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

Info to: 

Goals

  • going forward

Discussion items

TimeItemWhoNotes
 0minchair topic 
no update 

0min

Admin

Next meetings

2020-03-25: Martin Skorupski

2020-04-01: Martin Skorupski

2020-04-08: Thorsten Heinze

2020-04-15: Martin Skorupski

0minUUID

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


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.

UUID would be unique when the combination of device-id/mountpoint-name/network-element-name and device internal ids are unique.

UUID are created in advance by Planning Tools - and could be derived from expected equipment.

Idea: Planning tool deals with hardware templates - Requirement: capabilities, validation 


Action items