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