Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking Fri, 25 June 2021 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B90283A0317 for <>; Fri, 25 Jun 2021 08:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 659CbkmwXUav for <>; Fri, 25 Jun 2021 08:54:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 754063A02BD for <>; Fri, 25 Jun 2021 08:54:41 -0700 (PDT)
Received: from (unknown [xx.xx.xx.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4GBM5C27Nbz2yB4; Fri, 25 Jun 2021 17:54:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1624636479; bh=4v88UMrCma8YfXQlqUdgT1c7jJhDukDY1tg7wGCZL/U=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=So/RmfRET/QG7X8q+yFfv3yDQnz+enPvvIRhXsGbT7eYSnRsIe/wAkx8TeFM0q1e2 GeL2ykE19NOg0hTtRrn6WtJpjybPk7oWbSVW4dwpdpgXB/rKhAGbMQ81olCNJ0ARVC ajxHU8Rq9yVwfsV5jUBQabW8XPLSjPQItHpmcxGG/at6eQrAFlV4Vq54a+rZBPQGbK Fc0NtMO+KMkxHSOD2bYZcr0tyyIJ0+uY2xmKYSSYaSTLfAW3eiSjumO8lKWugHRzLX 3hkZg17mZe3gSHAGpGcR84xSTIZkQwErsTtRKt+BKsu17/JDDu3bPtCFZ4lKYQiyyG DKCsE+Zhdw6Iw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4GBM5C0n7Gz2xC9; Fri, 25 Jun 2021 17:54:39 +0200 (CEST)
To: Robert Raszuk <>
CC: Claudio Jeker <>, John Scudder <>, "idr@ietf. org" <>, "" <>
Thread-Topic: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking
Thread-Index: AQHXadhPBhWOE97yjUy1ubZTOGj4F6sk3jRA
Date: Fri, 25 Jun 2021 15:54:37 +0000
Message-ID: <7652_1624636479_60D5FC3F_7652_57_1_53C29892C857584299CBF5D05346208A4CDFAEC2@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <> <20976_1624607831_60D58C57_20976_28_1_53C29892C857584299CBF5D05346208A4CDF9BB2@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <19431_1624612909_60D5A02D_19431_174_7_53C29892C857584299CBF5D05346208A4CDF9FB9@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <6424_1624619306_60D5B92A_6424_261_1_53C29892C857584299CBF5D05346208A4CDFA365@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <20531_1624631867_60D5EA3B_20531_372_1_53C29892C857584299CBF5D05346208A4CDFAAF1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A4CDFAEC2OPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Jun 2021 15:54:48 -0000

From: Robert Raszuk []
Sent: Friday, June 25, 2021 5:40 PM
Cc: Claudio Jeker <>; John Scudder <>; idr@ietf. org <>;
Subject: Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking


Don't agree. If a BGP speaker spends two paths with path_id they will be identical on both RRs.

[Bruno] You are assuming that your two “diverses RR” learn the paths from the same (set of) peers. I agree that this is typical, but this is not guaranteed. If not, the path-id would not be comparable.

If they are from different peers there is no problem to start with as best path already picks path from lowest neighbor address.

I meant two Add Path RR peers. Each peer/session advertising both paths in one session. Cf below topology

Add Path RR1a --- Diverse RR1
Add Path RR1b -----+

Add Path RR2a --- Diverse RR2
Add Path RR2b -----+

- “—“ is a IBGP sessions advertising the two paths.
- I agree that the topology is debatable and does not match typical deployments. That’s all I found so far to find a counter example for your Diverse Path use case, so let’s call my example weak and close the Divers Path discussion




Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.