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

["Jakob Heitz (jheitz)" <[e-mail]>]

Then the code would have to compute the attribute length for each path, carry it along and pass it to the bestpath compare function.
For what? To increase convergence time?
Because simple byte length will not be good enough and people will start arguing that
an extended community is just as valuable as a regular community and count the number of communities
rather than bytes and then the tunnel attribute is longer and on and on.
I vote for path-id.

Regards,
Jakob.

From: Idr <[e-mail]> On Behalf Of Robert Raszuk
Sent: Thursday, June 24, 2021 1:40 PM
To: John Scudder <jgs=[e-mail]>
Cc: [e-mail]; idr@ietf. org <[e-mail]>
Subject: Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking

John,

> 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

While this is not about risk of loops, those paths may possibly contain different optional attributes otherwise they would be rather duplicates.

More specifically one of them may contain additional optional attributes while the other may not.

Perhaps with add-paths while we are at this discussion it may make sense to choose the path with a longer list of BGP path attributes as such path may be more useful to receivers.

Only then when the number of such attributes  is the same fall to path_id as tie-break.

Thx,
Robert


On Thu, Jun 24, 2021 at 8:15 PM John Scudder <jgs=[e-mail]<mailto:[e-mail]>> wrote:
Hi Folks,

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.

For the moment, this is just an FYI for the WG. Thanks very much to Claudio for pointing out the bug!

—John

[*] You may notice that it’s possible to have two such paths packed into the same update in some circumstances, which makes the choice even more arbitrary since it’s pretty notional to say one has arrived before the other.
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr