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

[John Scudder <[e-mail]>]

Hi Jeff,

> On Jun 26, 2021, at 10:49 AM, Jeffrey Haas <[e-mail]> wrote:
> 
> IMO, path-id is a lousy thing to tie-break on.
> 
> ** blows the dust off prior discussion **
> 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-pmohapat-idr-fast-conn-restore-03__;!!NEt6yMaO-gk!Tu7ZQLzHLMryoAz1GQuACoeSVHsC_MEDFDbTs7fDdavcj2sCxQOCHvmVnXxQHQ$
> 
> 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.

I won’t try to argue that this is a common case (although Robert has provided an argument). My perspective is that whether common or uncommon, ideally the protocol would cover the case. Now, my previous argument was that because leaving the tie-break underspecified/implementation-specific is safe to do, we don’t urgently need to fix the oversight; your assertion that it’s an uncommon case bolsters that position. But, I think it’s clear that if the oversight had been noticed while we were developing 7911, we’d have fixed it.

As for whether path-id is a “good" or “bad" tie-break, again I think that’s beside the point. I think it would be good to introduce something along the lines of fast-conn-restore to cover that use case, no doubt. The point of the path-id tie-break, if we did it, would be to make the outcome fully specified in all cases, even those missed by fast-conn-restore.

$0.02,

—John