[Idr] Re: Link-local nexthops and route reflection

["Krishnaswamy Ananthamurthy (kriswamy)" <[e-mail]>]

Proposal looks good to me Jeff.

Thanks
Krishna

From: Jeffrey Haas <[e-mail]>
Date: Friday, June 27, 2025 at 1:46 PM
To: idr <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [Idr] Link-local nexthops and route reflection
https://datatracker.ietf.org/doc/draft-ietf-idr-linklocal-capability

The last substantive issue to be addressed in the link local capability draft are iBGP issues.  The two things to be addressed are the Working Group deciding how it would like to address this, and the second drafting appropriate text to implement the desired behaviors.

Our general issue is that when a route is received with a link-local-nexthop (and only the LLNH), it has scope only to the interface that it's received upon.  Nothing else is valid.

Both iBGP and eBGP procedures say that if a route is being re-advertised to a peer where the nexthop is on the same subnet, this may be done without changing the nexthop.  This is the original "third party nexthop" scenario.

For link local nexthops, this is even further restricted.  It's possible to readvertise the received LLNH to another peer if, and only if, the two peers have nexthops that are on the same interface.  A subnet check no longer is correct since every interface is "on the same subnet" from a link local perspective.

Broadly speaking, this is the situation for any type of readvertisement for routes with LLNH.  If you're propagating the route and it had a RFC 2545 global + LLNH, the LLNH can be stripped and the global propagated when the link local is no longer safe to propagate even if the global one is.  However, we don't have that option if the route only has a LLNH.

My proposal is the following:
1. Absent additional configuration, routes that contain only a LLNH SHOULD NOT be propagated using iBGP to peers that don't share the same interface as the LLNH.  This becomes a form of "treat as withdraw" type behavior.
2. If permitted by configuration, such propagation from one BGP neighbor to another is allowed, but the nexthop MUST be changed.  This new nexthop will depend on the properties of the iBGP peering session.  If it is directly attached, it MUST use a LLNH and MAY include a global nexthop using RFC 2545 procedures.  If it not directly attached, an appropriate global nexthop address MUST be chosen.

Thoughts?

-- Jeff