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

Claudio Jeker <> Fri, 25 June 2021 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 948493A090B for <>; Fri, 25 Jun 2021 09:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xkh0tEURE5-9 for <>; Fri, 25 Jun 2021 09:26:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C57A53A0906 for <>; Fri, 25 Jun 2021 09:26:02 -0700 (PDT)
Received: (qmail 4874 invoked by uid 1000); 25 Jun 2021 16:25:56 -0000
Date: Fri, 25 Jun 2021 18:25:55 +0200
From: Claudio Jeker <>
To: Robert Raszuk <>
Cc: Bruno Decraene <>, John Scudder <>, "idr@ietf. org" <>, "" <>
Message-ID: <>
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> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
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 16:26:08 -0000

On Fri, Jun 25, 2021 at 03:12:00PM +0200, Robert Raszuk wrote:
> 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. 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.

RFC7911 has no such requirement. At least Section 2 allows to assign
different path-ids for the same path sent to different peers.
It would be perfectly fine to use random path ids as long as all
updates and the final withdraw of this path use the same id.
Once the path has been withdrawn a new path_id could actually be selected
again.  This is how I interpret Section 2 of RFC7911 especially this bit:

   The assignment of the Path Identifier for a path by a BGP speaker is
   purely a local matter.  However, the Path Identifier MUST be assigned
   in such a way that the BGP speaker is able to use the (Prefix, Path
   Identifier) to uniquely identify a path advertised to a neighbor.  A
   BGP speaker that re-advertises a route MUST generate its own Path
   Identifier to be associated with the re-advertised route.  A BGP
   speaker that receives a route should not assume that the identifier
   carries any particular semantics.

> 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 :)

In my opinon it would be great to have this documented somewhere so that
all implementations are able to behave the same.
Using the nexthop as a tie-breaker makes sense to me. I agree that path-id
is not the best criteria but it is the only one that can actually
distinguish two paths that are equal. RFC7911 does not specify that a
peer MUST NOT send paths with equivalent attributes over add-path.
So I guess one has to assume that a system may actually do that.

:wq Claudio