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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A2F33A1AC2 for <>; Fri, 25 Jun 2021 07:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id brwLKYaBlr-E for <>; Fri, 25 Jun 2021 07:37:50 -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 324B73A1AC1 for <>; Fri, 25 Jun 2021 07:37:50 -0700 (PDT)
Received: from (unknown [xx.xx.xx.69]) (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 4GBKNW16Q6z1ysj; Fri, 25 Jun 2021 16:37:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1624631867; bh=D4+B1tQ3fWGaej3q6OJAPvjYvarx86j8xYTtNlG3o5Q=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=iBTxyKMd8V1dtolSLECr+w/riaMLxabT4at4I/pZGvD75Mu16dRVfbL3vUOj0+SqW BVj7UbcPVeLcQDOCNNC1tM94AaO36ANSm6wseFW5KsL4t9r4jHpuM347rsVfNLgZ+x hQPvq8Wav6sAC3Jp/ypdtb857R4Hly/pFyEyeoqehEEJEMHrJXRXGtAI316IAz13gJ pfUW5uWOqO+shsqQvamtavC6uaBEzWuXkYo4dB3EP0FI4Z+Mx2jAMeXFMCwkHvgFIE uCyghmjE5y8lHn55EA3RSmdo+Hl1x5nFYaUQLjhZTTxzOoT60q9E+nhw6VyhrvFiRd InttHAFMeD95Q==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4GBKNW0WVszyQP; Fri, 25 Jun 2021 16:37:47 +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: AQHXacOuBhWOE97yjUy1ubZTOGj4F6skxeZA
Date: Fri, 25 Jun 2021 14:37:46 +0000
Message-ID: <20531_1624631867_60D5EA3B_20531_372_1_53C29892C857584299CBF5D05346208A4CDFAAF1@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> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A4CDFAAF1OPEXCAUBM43corp_"
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 14:38:02 -0000

Inline [Bruno]

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

Hi Bruno,

Your scenario would only require RR implementing RFC6774 to perform a common tie-breaking. So the bug/fix would rather be on RFC 6774 ;-)  (rather than on 7911)

That is debatable.

More seriously/importantly Path-Id is not guaranteed to be the same on both RR. Hence the output of the tie-breaking would not be common across those RR.

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.

Path_IDs are not ad hoc random numbers generated on the fly when you advertise. They are attached to paths and do not change regardless where the paths are advertised with add-path.

[Bruno] I’d assume that this would be the case on implementations as this seems more optimal.
However, this is not how this is specified in RFC 7911. There is no statement that the path_ID be ‘per plateform’ (rather than per-peer) and the RFC is clear that it’s a local choice of the sender and the receiver should not make any assumption. So you can’t make any claim on this.

So this will work fine for RFC6774.

For your use case, it seems it would be more effective to do the final tie-break on whatever criteria you want to be diverse. E.g. the BGP Next-Hop (which is both deterministic and diverse while Path-Id is not)

For the described case path_id will work. But in general case, surely selecting path with different next hop as 2nd best will be a good option. In fact some implementations already do that already :)
[Bruno] If you want diverse paths, better to compute for path diversity, rather than use a random BGP tie break (e.g. peer address, path-id, local_pref). You could have 3 paths, with 3 different path-id and only 2 NH (Next Hop Self on the ASBR advertising two path). Picking the diverse a second path from the same ASBR is less diverse and will not protect from ASBR failure.




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.