BGP best path next-hop selection enhancements#

Olivier Vroonen, Stéphane Litkowski (Cisco)

• Why: BGP's resolvability and cost rules assume the NEXT_HOP is the actual forwarding endpoint. GRE/MPLS/SR-MPLS/SRv6 tunnels break that assumption, producing real blackholes and wrong picks — shown with concrete examples of a VRF route dropped because no transport tunnel exists to the best path's next hop, and a delay-optimized (colored) path chosen by lowest IGP metric.
• What: Standardizes behavior vendors already implement: introduces the concept of a "forwarding address" (e.g., the tunnel endpoint) with a "forwarding context" (tunnel type and characteristics, resolution constraints such as which table to look up in); requires resolvability checks against the forwarding address, not just NEXT_HOP; makes costs from different contexts comparable via a preference notion (like RIB preference); and requires BGP to re-evaluate best paths whenever underlying reachability or cost changes (tracking).
• How: Builds on the partial fixes already in RFC 9012 (tunnel encapsulation) and RFC 9252 (SRv6) but addresses both resolvability and path suboptimality generically, not just for one encapsulation.
• Where applicable: Any tunnel-based BGP deployment, including SRv6 DC underlays — broadly applicable. Early individual draft (-00); value is mostly standardization of existing vendor behavior for interoperability.