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 9ebc0b6

[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).