-
Notifications
You must be signed in to change notification settings - Fork 2
Add peer interface annotation for physical interfaces #191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -63,6 +63,12 @@ const VRFLabel = "networking.metal.ironcore.dev/vrf-name" | |
| // to trigger certain disruptive operations, such as reboots or firmware upgrades. | ||
| const DeviceMaintenanceAnnotation = "networking.metal.ironcore.dev/maintenance" | ||
|
|
||
| // InterfacePeerAnnotation references the peer Interface resource on the other end of a physical link. | ||
| // The value must be a reference to another Interface resource in the format "namespace/name" | ||
| // or just "name" (for same-namespace references). | ||
| // This annotation is only valid for interfaces of type Physical. | ||
| const InterfacePeerAnnotation = "networking.metal.ironcore.dev/peer-interface" | ||
|
Comment on lines
+66
to
+70
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like using the reference to another resource here. However, I am wondering how we will deal with those interfaces that have peers outside our control and for which we do not have an Interface resource. We won't have a way to verify the cabling.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We also discussed this and our use case includes also verifying the cabling of interfaces connected to other devices and interfaces that we do not control. Usually the neighbor is a combination of the So in principle we would like to support both a reference to a physical interface and some sort of string. While this is not immediately pressing, its probably considering this already. What do you think? |
||
|
|
||
| // Device maintenance actions that can be requested via the DeviceMaintenanceAnnotation. | ||
| const ( | ||
| // DeviceMaintenanceReboot requests a device reboot. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think aggregated interfaces should be allowed too: "An An LLDP agent can be configured on an IEEE 802.1AX™ Aggregated Port and/or on any number of the physical ports belonging to the Aggregation" [IEEE8021AB-2016]. May be we could leave a note here or extend the commit message if we want to enforce this condition for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect that configuring LLDP on an Aggregate Interface, would lead to configuring it's member Interfaces. As the Aggregate Interface is a logical/virtual construct, for me it's not directly related to the physical cabling, so in this case I would expect that annotation to be on the members instead and not on the aggregate. But I'm happy to discuss.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point. We also discussed it in our alignment and we won't consider link aggregation. In this context, what do you think about renaming the
AnnotationtoPhysicalInterfaceNeighborAnnotation = "networking.metal.ironcore.dev/interface-neighbor". This would also be more consistent with theLLDPterminology.