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

Jeffrey Haas <jhaas@pfrc.org> Sat, 26 June 2021 16:00 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD473A1ACD for <idr@ietfa.amsl.com>; Sat, 26 Jun 2021 09:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewYeZAg9grjH for <idr@ietfa.amsl.com>; Sat, 26 Jun 2021 09:00:31 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 202433A1AD9 for <idr@ietf.org>; Sat, 26 Jun 2021 09:00:31 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id B3DE51E45C; Sat, 26 Jun 2021 12:26:27 -0400 (EDT)
Date: Sat, 26 Jun 2021 12:26:27 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: John Scudder <jgs@juniper.net>
Cc: "idr@ietf. org" <idr@ietf.org>, "dwalton76@gmail.com" <dwalton76@gmail.com>
Message-ID: <20210626162627.GF14665@pfrc.org>
References: <F689CF63-236D-401D-9C8E-AC1C39CDE772@juniper.net> <20210626144948.GD14665@pfrc.org> <395B392F-DB11-4363-8459-B817EA7C0647@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <395B392F-DB11-4363-8459-B817EA7C0647@juniper.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OX5jvWBZDjZLFkkE-egGTaZ9nxg>
Subject: Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Jun 2021 16:00:32 -0000

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