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

[Jeffrey Haas <[e-mail]>]

John,

On Sat, Jun 26, 2021 at 03:13:09PM +0000, John Scudder wrote:
> 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.

There's a fair chance I brought out the fast-conn document during that
discussion.  The hand-waving we'd done at the time was effectvely the caveat
of "don't inject routes from ebgp".

> 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.

Path-ids are by protocol behavior permitted to be effectively random numbers
as long as they're consistently used.

The Juniper implementation tries to conserve the path-id space and will
pretty aggressively re-use the ids.  A result is that we'd deterministically
pick a random winner.

Another implementation I have accidental exposure to embeds either the BGP
identifier or neighbor address in the path-id.  For a single hop ebgp
leaking case via add-paths, it can proxy for one of the steps and lead to
more deterministic tie-breaking.  However, it only does so at that first
step.

With the path attribute from fast-conn-restore, you get that tie-breaking
behavior more deterministically across an AS.

The minute you start going multi-AS or start looking at the considerations
of the attribute as specified in that document as it leaks, the situation
becomes messier.  Effectively the attribute has meaning until the next point
you do a next-hop reset.  Now, how do you prove that the last party that
reset the nexthop stripped the attribute or reset it appropriately?

-- Jeff