connection-map in device model

[ojnas]

Could someone please explain how the connection-map list in the device model is supposed to be used for a ROADM device? The device whitepaper only says that it "reflects any connectivity restrictions / blocking in the device". Furthermore, the network model whitepaper says that "Add, Drop and Express links can be auto detected based on connection map from the device".

Some specific questions:

• The device model also has internal-links and physical-links. How are these related to the connection-map?

• The physical-links list is read-write and supposed to be pushed from the controller based on actual cabling. Is the device supposed to update the connection-map, which is read-only, based on the physical-links information?

• What information can be derived from the connection-map that cannot also be derived from the physical-links + internal-links?

[fgruman]

Connection-map was meant to be a more concise and easier to use mechanism than the physical links + internal link mechanism, and is the primary entity that is used to drive path computation.

The connection-map provides the connectivity from external ports. It applies to ROADM and transponder nodes.
For ROADM it shows the connectivity from SRG add/drop ports to ROADM degree external ports.
Or ROADM degree external to ROADM degree external.

For transponder it shows connectivity from client port to network port.

If you were using internal links and physical links, then you would need to trace the physical and internal links from the source port to destination port. It would be even more complex when you consider the pluggables on transponders.

[ojnas]

Thanks, @fgruman , that makes sense. So the network controller primarily reads the connection-map (+external links (EDIT: or rather LLDP neighbor information)) from the device to build the network topology, right?

Could you please also comment on this question:

Is the device supposed to update the connection-map, which is read-only, based on the physical-links information (that is pushed from the controller)?

[fgruman]

Yes, controller would primarily use connection-map to understand the internal node's connectivity between the external facing ports of the device.

External links are purely provisioned by the controller. Controller can choose to create external links for the discovered neighbor relationship (e.g., via LLDP). And this can lead to topology + internal connectivity information for path computation.

The device should update the connection-map based on provisioning on the node - this include not just the creation (and deletion) of physical links, but also the creation/deletion of equipment (circuit-pack and ports).

At this time, we do not have the operational status of the connection map (e..g, set a connection map entry to operational OOS when a fault is detected). This may be considered in the future.