Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking

[Jeffrey Haas <[e-mail]>]

On Thu, Jun 24, 2021 at 06:14:55PM +0000, John Scudder wrote:
> Claudio recently pointed out a bug in RFC 7911 to the authors, and we thought we should let the WG know. The gist of the bug is that the tie-breaking process is underspecified, because it’s technically possible to receive two routes for the same destination, from the same peer, with different path-id, and with all tie-break metrics the same (all the way down to peer address). My guess — but it’s only a guess, I haven’t checked — is that implementations may mostly have chosen to prefer the first path received.[*] But the only thing we can say with confidence is “it’s underspecified and therefore implementation-dependent.” 
> 
> When I worked through this, my conclusion was that whatever option an implementation chooses should be safe, since by definition the paths are equivalent all the way down. I don’t see a way to form a loop even if every router in the network makes arbitrary — and conflicting — choices in this situation, since by definition of IGP distance, if a given router A makes an arbitrary choice, none of its neighbors when presented with the same set of routes will make a conflicting arbitrary choice, since the options are:
> 
> - The peer is closer to both destinations, in which case it can make any choice it wants, the traffic will not loop back to A,
> - The peer is further from both destinations, in which case it can make any choice it wants, the traffic will not loop back from A,
> - The peer is closer to one and further from the other destination, in which case it isn’t faced with a dilemma, it will choose the closer (and the traffic won’t go back towards A).
> 
> I guess if you’re in a network that doesn’t have IGP distances at all (maybe everything is static routed?) or if IGP distances don’t follow the usual rules of IGP “physics”, then you could create a problem. But those are pathological cases where we’d expect BGP not to work very well anyway. 
> 
> Claudio suggested that path-id would be a good final tie-break; that makes sense to me. We could do a quick update to 7911 to standardize this new tie-break, we could do a bis of 7911 to include the new tie-break, or we could just leave things as they are, relying on my argument above that says there is no strong need to standardize a tie-break since any choice is OK. 

IMO, path-id is a lousy thing to tie-break on.

** blows the dust off prior discussion **

https://datatracker.ietf.org/doc/html/draft-pmohapat-idr-fast-conn-restore-03

In general, when a given peer is passing along multiple paths, the case that
gives us grief is when we get them from ebgp.  The draft above discusses the
problem nicely.

If there are common scenarios where a given BGP speaker will locally
originate multiple paths without having gotten them from somewhere else, I'm
not currently aware of it.

-- Jeff