Adding config container for LACP member interface with port-priority
Closed this issue · 7 comments
Hi, I don’t see a way to configure a member interface’s priority in a LAG (or configure anything else for an LACP member interface, as there is no config container under /lacp/interfaces/interface[name]/members/member[interface]). I’m wondering if it would be ok to add a config container for member interfaces with port-priority, as well as the port-priority and partner-port-priority leaves under member state:
+--rw lacp
+--rw interfaces
| +--rw interface* [name]
| | +--rw members
- | | | +--ro member* [interface]
- | | | | +--ro interface -> ../state/interface
+ | | | +--rw member* [interface]
+ | | | | +--rw interface -> ../config/interface
+ | | | | +--rw config
+ | | | | | +--rw interface oc-if:base-interface-ref
+ | | | | | +--rw port-priority uint16
| | | | +--ro state
+ | | | | | +--ro port-priority uint16
+ | | | | | +--ro partner-port-priority uint16
Vendor examples for the configuration:
Arista, section "Configuring Port Priority":
https://www.arista.com/en/um-eos/eos-port-channels-and-lacp
Cisco, section "Configuring the LACP System ID and Port Priority":
https://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/gigeth.html
The configuration for aggregation has generally been under /interfaces/interface/aggregation. Currently, /lacp/members/member is a read-only container. It's worth discussing how we want to support this -- it does seem changing this to config true might be the best approach, but I don't think there's precedent for such a change.
Another way to do it is set port-priority under /interfaces/interface/aggregation, as it is a property of an interface. This is how at least 3 references do it. (the two above, plus JunOS port-priority.
I agree it's somewhat arbitrary where to place this configuration.
+1 - is best to create a uint16 leaf under the grouping aggregation-logical-config in openconfig-if-aggregate.yang for this imo
+--rw interfaces
+--rw interface* [name]
+--rw oc-lag:aggregation
+--rw oc-lag:config
| +--rw oc-lag:lag-type? aggregation-type
| +--rw oc-lag:min-links? uint16
+--ro oc-lag:state
| +--ro oc-lag:lag-type? aggregation-type
| +--ro oc-lag:min-links? uint16
| +--ro oc-lag:lag-speed? uint32
| +--ro oc-lag:member* oc-if:base-interface-ref
Thanks everyone for your responses! It looks like the attributes under /interfaces/interface[name]/aggregation/config refer to an aggregate logical interface, whereas port-priority refers to the priority of a physical interface in its aggregate interface. What if instead, I add port-priority to /interfaces/interface[name]/ethernet/config and /interfaces/interface[name]/ethernet/state? I'm also thinking of keeping port-priority and partner-port-priority under /lacp/interfaces/interface[name]/members/member[interface]/state.
So then my changes would look like:
@@ -12,5 +12,7 @@ module: openconfig-if-aggregate
+--ro member* oc-if:base-interface-ref
augment /oc-if:interfaces/oc-if:interface/oc-eth:ethernet/oc-eth:config:
+--rw aggregate-id? -> /oc-if:interfaces/interface/name
+ +--rw aggregation-port-priority? uint16
augment /oc-if:interfaces/oc-if:interface/oc-eth:ethernet/oc-eth:state:
+--ro aggregate-id? -> /oc-if:interfaces/interface/name
+ +--ro aggregation-port-priority? uint16
@@ -37,6 +37,8 @@ module: openconfig-lacp
+--ro port-num? uint16
+--ro partner-port-num? uint16
+--ro last-change? oc-types:timeticks64
+ +--ro port-priority? uint16
+ +--ro partner-port-priority? uint16
+--ro counters
+--ro lacp-in-pkts? oc-yang:counter64
+--ro lacp-out-pkts? oc-yang:counter64
Actually yes, you are correct on the first part - the port-priority is more well suited in parallel to the aggregate-id under the physical ethernet config/state and not under the aggregation container that is rather gated for the logical bundle interface.
when "oc-if:config/oc-if:type = 'ianaift:ieee8023adLag'"
Now a container to bucketize aggregation related parameters is probably worth exploring under ethernet. aggregate-id as-is today can be deprecated + relocated under this container and nodes specific to the LACP protocol could be called out as such giving expansion for any other possible parameters (link protection/static, etc..)
For the latter on LACP member priority placement for state, that LGTM
Agreed on using the ethernet subtree and given there are >=2 values, then adding a container is a reasonable option.
interfaces
interface
ethernet
aggregation
port-priority
aggregate-id
I'll also second Ebben's recommendation to use status deprecated for the port-priority leaf which is being removed (moved to the container)