Add next-hop-unchanged for BGP

[dplore]

Change Scope

By default BGP changes the next hop of a BGP route to itself when advertising to neighbors. .../afi-safis/afi-safi/.../config/next-hop-unchanged is added to disable this behavior.

This feature is commonly used in combination with BGP based VPN's (RFC4364).

The full paths added are:

/network-instances/network-instance/protocols/protocol/bgp/global/afi-safis/afi-safi/ipv4-unicast/config/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/global/afi-safis/afi-safi/ipv4-unicast/state/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/global/afi-safis/afi-safi/ipv6-unicast/config/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/global/afi-safis/afi-safi/ipv6-unicast/state/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/afi-safis/afi-safi/ipv4-unicast/config/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/afi-safis/afi-safi/ipv4-unicast/state/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/afi-safis/afi-safi/ipv6-unicast/config/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/afi-safis/afi-safi/ipv6-unicast/state/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/peer-groups/peer-group/afi-safis/afi-safi/ipv4-unicast/config/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/peer-groups/peer-group/afi-safis/afi-safi/ipv4-unicast/state/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/peer-groups/peer-group/afi-safis/afi-safi/ipv6-unicast/config/next-hop-unchanged
/network-instances/network-instance/protocols/protocol/bgp/peer-groups/peer-group/afi-safis/afi-safi/ipv6-unicast/state/next-hop-unchanged

This change is backwards compatible.

Platform Implementations

• Cisco IOS XR
• JunOS no-nexthop-change. Note, this is implemented only at a hierarchy of eBGP
• Nokia SRLinux next-hop-unchanged
• Nvidia next-hop-unchanged:

[OpenConfigBot]

No major YANG version changes in commit 06d8d29

[LimeHat]

This should be configurable with per afi/safi granularity and not tied to multihop.

Nokia ref: https://documentation.nokia.com/sr/24-7/7750-sr/cli-books/classic-cli-command-reference/classic-n-commands.html?hl=next-hop-unchanged#yc23860

Nvidia ref: https://docs.nvidia.com/networking/display/onyxv3104302/bgp+commands#src-132451846_BGPCommands-neighbornext-hop-unchanged

Another Cisco ref that shows per-afi/safi config
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-12/configuration_guide/rtng/b_1612_rtng_3650_cg/configuring_bgp_next_hop_unchanged.pdf

I know that Arista supports the config like in the above cisco reference as well, just wasn't able to find a public reference immediately.

[dplore]

This should be configurable with per afi/safi granularity and not tied to multihop.

Nokia ref: https://documentation.nokia.com/sr/24-7/7750-sr/cli-books/classic-cli-command-reference/classic-n-commands.html?hl=next-hop-unchanged#yc23860

Nvidia ref: https://docs.nvidia.com/networking/display/onyxv3104302/bgp+commands#src-132451846_BGPCommands-neighbornext-hop-unchanged

Another Cisco ref that shows per-afi/safi config https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-12/configuration_guide/rtng/b_1612_rtng_3650_cg/configuring_bgp_next_hop_unchanged.pdf

I know that Arista supports the config like in the above cisco reference as well, just wasn't able to find a public reference immediately.

Moved to afi-safi container. I also renamed the leaf to 'next-hop-unchanged' to align with something much closer to what implementations are already using.

[robshakir]

This is still inconsistent with how next-hop-self is represented in OpenConfig -- where it is something that is within a policy not a leaf. I don't agree with this proposal unless we have a coherent approach within the models.

Note that implementations would already a need to be mapping the current approach to underlying config -- so either this is implemented (and thus can be extended), or unimplementable (and thus the current n-h-s approach should be deprecated).

[robshakir]

Requesting changes to make this consistent with next-hop self in the models.

[dplore]

Requesting changes to make this consistent with next-hop self in the models.

Sorry I do not understand the issue. Could you provide an example of how BGP next-hop-self is represented in openconfig? Maybe that will be enough for me to understand how to propose something that enable/disables that. But if you have a suggestion in mind, I'd also be happy to see that too.

One idea is that you're referring to the typedef bgp-next-hop-type used in /routing-policy/policy-definitions/policy-definition/statements/statement/actions/bgp-actions/config/set-next-hop.

Are you saying that it's better to define next-hop-unchanged within each policy rather than at the afi/safi level?

[robshakir]

Next-hop self is specified through:

1. (/routing-policy/policy-definitions/policy-definition/statements/statement/actions/bgp-actions/config/set-next-hop)[https://openconfig.net/projects/models/schemadocs/yangdoc/openconfig-routing-policy.html#routing-policy-policy-definitions-policy-definition-statements-statement-actions-bgp-actions-config-set-next-hop]
2. (bgp-next-hop-type)[https://openconfig.net/projects/models/schemadocs/yangdoc/openconfig-routing-policy.html#type-bgp-next-hop-type] enum values -- i.e., SELF here.

We have discussed this numerous times over the years -- since some implementations have this in config not policy, I'm not understanding why we would have one thing (n-h-s) be via policy and another (unchanged) be in neighbour config.

[dplore]

Next-hop self is specified through:

1. (/routing-policy/policy-definitions/policy-definition/statements/statement/actions/bgp-actions/config/set-next-hop)[https://openconfig.net/projects/models/schemadocs/yangdoc/openconfig-routing-policy.html#routing-policy-policy-definitions-policy-definition-statements-statement-actions-bgp-actions-config-set-next-hop]
2. (bgp-next-hop-type)[https://openconfig.net/projects/models/schemadocs/yangdoc/openconfig-routing-policy.html#type-bgp-next-hop-type] enum values -- i.e., SELF here.

We have discussed this numerous times over the years -- since some implementations have this in config not policy, I'm not understanding why we would have one thing (n-h-s) be via policy and another (unchanged) be in neighbour config.

Ah ok, I understand the reason and goal here. But the semantics are different from the 100% of all the precedent that I can find (I spent a lot more time search and found a total of 6 references below, all of which have distinct configuration for this and apply on a per session basis).

Is there an operational reason to need to craft policies to selectively choose which routes would cause next-hop self to be unchanged? The operational use cases I know of are both the classic scenario of override RFC4271 behavior: EVPN and an internal one at Google. The Google use case is for R1 to learn multi-path routes from an eBGP neighbor R2 and we want R1 to retain the next-hops/multipath information when sending the routes to iBGP peer R3.

• Cisco IOS XR
• JunOS no-nexthop-change. Note, this is implemented only at a hierarchy of eBGP
• Nokia SROS next-hop-unchanged
• Nvidia switch (config router bgp 65001 address-family l2vpn-evpn) # next-hop-unchanged:
• Arista EOS neighbor xyz123 next-hop-unchanged. (although I found other references in support articles that are not publicly viewable that if address-family evpn is configured, then this behavior is the default).
• Extreme Networks neighbor next-hop-unchanged

I appreciate that it is elegant to have 'things related to next-hop-self' in the same subtree, but from a standpoint of precedent and ability to easily translate existing bgp policies into openconfig, applying on a per session is very straightforward. If we apply via policy, then I guess it's just adding another statement with no condition and an action next-hop-unchanged. Implementations however will have to parse the logic in context of routing-policy. This will be be an issue if there are statement/conditions defined, which is something we aren't asking for and implementations don't offer (to my knowledge).