osrg
WIP: fix(#3214): tablemanager use link-local nexthop if global is unspecified
Work In Progress. Showcasing a quick fix for #3214.
When BIRD peers using only a link-local address it supplies this in a 32byte next-hop as :: LL (i.e. :: fe80::ade0). FRR supports this format as well (see this issue).
Though not entirely related, there's a draft RFC about this here.
This PR adds logic to the table manager that: if the nexthop is unspecified and the LinkLocalNexthop is valid and actually a local-link, then uses the LinkLocalNextHop for the path.
Some questions and statements floating in my mind while working on this:
A new RFC Draft for LinkLocal only capable peers state that a peer that advertises ONLY a LinkLocal Nexthop MUST encode this in 16 bytes nexthop.
This would mean that while decoding the nexthop in bgp.go the BGP_ATTR_NHLEN_IPV6_GLOBAL actually means BGP_ATTR_NHLEN_IPV6_GLOBAL_OR_LINKLOCAL.
This might also - at least for me - require a concrete definition for PathAttributeMpReachNLRI.NextHop In bgp.go. Is the field NextHop only Global or can it also be the LinkLocal? What is the LinkLocalNextHop field in that case.
2025-10-31: path.go derives whether its local from the fact it uses a LocalAddress vs Address of a peer. This would argue in favor of NextHop being global address only.
