Extend Add-path Send leaf with values ADDPATH-ECMP and ADDPATH-ALL

[nupkanoi]

This proposal extends Add-path Send leaf with values ADDPATH-ECMP and ADDPATH-ALL to add support ecmp and send all paths within add-path feature.

Platform Implementations

1. Arista Feature Documentation: BGP Additional Paths (Add-Path)

bgp additional-paths send ecmp (Advertises all ECMP multipaths)
bgp additional-paths send any (Advertises all paths)
bgp additional-paths send limit (Limits the best-path advertisement count)
bgp additional-paths receive

2. Cisco (IOS-XR)

additional-paths send / additional-paths receive
additional-paths selection route-policy
RPL policy action: set path-selection multipath advertise or set path-selection all advertise.

Cisco should natively translate the enum values ADDPATH_ALL and ADDPATH_ECMP to the appropriate route-policy
Example route-policy:

route-policy ADDPATH-ECMP
  set path-selection multipath advertise
end-policy
! 

3. Juniper (Junos)
   path-count
   path-selection-mode equal-cost-paths
   path-selection-mode all-paths

4. Nokia (SR Linux)

network-instance protocols bgp afi-safi ipv4-unicast add-paths send true
send-max
Coupled with the BGP Multipath configuration (protocols bgp afi-safi ipv4-unicast multipath) to advertise ECMP ranges.

Tree View

 module: openconfig-bgp-common
         |     |  |     |     +--rw add-paths
         |     |  |     |     |  +--rw config
         |     |  |     |     |  |  +--rw receive?                  boolean
-        |     |  |     |     |  |  +--rw send?                     boolean
+        |     |  |     |     |  |  +--rw send?                     union
         |     |  |     |     |  |  +--rw send-max?                 uint8
         |     |  |     |     |  |  +--rw eligible-prefix-policy?   -> /oc-rpol:routing-policy/policy-definitions/policy-definition/name
         |     |  |     |     |  +--ro state
         |     |  |     |     |     +--ro receive?                  boolean
-        |     |  |     |     |     +--ro send?                     boolean
+        |     |  |     |     |     +--ro send?                     union
         |     |  |     |     |     +--ro send-max?                 uint8
         |     |  |     |     |     +--ro eligible-prefix-policy?   -> /oc-rpol:routing-policy/policy-definitions/policy-definition/name
         |     |  |     |     +--rw use-multiple-paths
         |     |  |     |     |  +--rw config

[gemini-code-assist]

Code Review

This pull request updates the openconfig-bgp-common.yang submodule to version 9.9.2, extending the send leaf under Add-path to support a union of boolean and explicit enumeration modes (ADDPATH_ECMP and ADDPATH_ALL). Feedback suggests keeping the parent module and other submodules in sync with this version update to avoid compilation failures, and clarifying the behavior of ADDPATH_ALL when send-max is not configured.

[arun-arista]

Can we also consider adding ADDPATH_BACKUP to the enum?
Adding on to your Platform Implementations, there is bgp additional-paths send backup that would advertise the best path and the backup path.
We can also add a leaf prefix-list that controls which routes are advertised out as add-path.

[navaneethyv]

@nupkanoi please fix the failing checks.

[earies]

Even though you are retaining the original type in a union, that is a backwards incompatible change at a high level and warrants a major version increment vs. patch

[nupkanoi]

I'm a bit unclear on why this is considered backwards-incompatible given the boolean type is still supported in the union. Could you help me understand the impact? Please let me know what major version number you'd recommend bumping this to and I'll update the PR.

[earies]

Any type change can have impact beyond the wire encoding - in this case wire encoding could stay the same but codegen, validation, etc.. could now be problematic - impacts unknown. A client also has to adapt to new typing and values being a possibility.

Interleaving types like this is probably not a good idea either as it becomes messy and complex very fast - a usual approach would be to leave the current definition intact (unless there is proof there is no implementation, etc..) and introduce a new structure and create a migration path.

I don't think there are any widely published rulesets on this and is left to interpretation tbh - sliding unions in is just a gap that probably needs some rules around it.

[nupkanoi]

Thanks for the detailed explanation, @earies . That makes complete sense, I hadn't fully considered the downstream blast radius for codegen tools (like ygot) where a union would fundamentally change the generated types and break existing clients expecting a standard boolean.

I agree with your suggested approach to leave the current definition intact and create a clean migration path. I have made the following changes to the PR:

1. Revert the send leaf back to type boolean; to ensure strict backwards compatibility.
2. Deprecate the send leaf by adding status deprecated; and updating the description to point to a new leaf.
3. Introduce a new leaf (e.g., send-mode) of type enumeration (or identityref) to capture all add-path send states. This would include the new values (ADDPATH_ALL, ADDPATH_ECMP, ADDPATH_BACKUP) as well as a baseline value (e.g., STANDARD or BASIC) to map to the legacy send = true behavior.

Let me know if this looks good to you.