BGP IPv6 link-local next-hop behavior

[leonshaw]

See a previous discussion in #17073.

There are recently several PRs related to BGP IPv6 link-local next-hop: #16219, #17037, #17071, #17073. But we are lacking docs on the exact behavior. Quoting RFC2545 section 3:

The link-local address shall be included in the Next Hop field if and
only if the BGP speaker shares a common subnet with the entity
identified by the global IPv6 address carried in the Network Address
of Next Hop field and the peer the route is being advertised to.

Taking route-maps and nexthop-local unchanged into account, I think the criteria could be:

1. If link-local next-hop is set by route-map, or
2. If nexthop-local unchanged is configured and the route already has link-local next-hop, or
3. If the speaker shares a network with peer and has link-local address and the global next-hop is our peering address. (stricter than RFC so that link-local next-hop matches global).

Is it correct?

Some PRs mentioned above are approximately checking for criteria 3, but focus too much on specific cases. For example in the case of #17073,

AS 65000  | AS 65001
          |
      RR  |
       |  |
R1 --- | --- R2
          |

Routers share one network, R1 is a reflect client and R2 is an eBGP peer of RR, so RR should not send link-local next-hop in R1's routes to R2. However, IMO this is not because R1 is a reflect client as the PR claims, but because the global next-hop is R1 unchanged (eBGP multi-access case). Consider if R1-RR is eBGP connection, the link-local next-hop should not be sent either. On the other hand if RR-R2 is on another network, then the global next-hop is changed to self, and link-local next-hop may be included. There's no much relation between reflect client and link-local next-hop.

It's difficult to determine criteria 3 at subgroup level. As peer->nexthop and subnet is not part of subgroup key, a subgroup can't guarantee the number of next-hops is the same for all peers. Link-local addresses can also appear/disappear when connection is established but subgroup is not updated after creation.
So I wonder if the decision of link-local next-hop could be postponed till the processing of individual peers? That would make things easier.

[ton31337]

IMO, we should just follow RFCs without manipulating how we want, it clearly says:

The link-local address shall be included in the Next Hop field if and
only if the BGP speaker shares a common subnet with the entity
identified by the global IPv6 address carried in the Network Address
of Next Hop field and the peer the route is being advertised to.

So, do we really need 1/2 bullets at all?

[leonshaw]

IMO, we should just follow RFCs without manipulating how we want, it clearly says:

The link-local address shall be included in the Next Hop field if and
only if the BGP speaker shares a common subnet with the entity
identified by the global IPv6 address carried in the Network Address
of Next Hop field and the peer the route is being advertised to.

So, do we really need 1/2 bullets at all?

It's an option. But that means to remove set ipv6 next-hop local route-map action and neighbor nexthop-local unchanged from CLI.