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

Robert Raszuk <> Fri, 25 June 2021 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BA223A0D4A for <>; Fri, 25 Jun 2021 10:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 c8TJwU8Bs5Qr for <>; Fri, 25 Jun 2021 10:45:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1DBC3A0D48 for <>; Fri, 25 Jun 2021 10:45:42 -0700 (PDT)
Received: by with SMTP id f13so13543147ljp.10 for <>; Fri, 25 Jun 2021 10:45:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YCfE9Lg4LDU/g5XnG00JmCSfe7L883ni9ZqhvKodx6Y=; b=NYe/IsnibuffVrZRzFWtpRCwZSCLzwwFJJGfE9fYvV7G1W9mlo22Rj9tKAug6ia6GM FT/CKjIfW3DtNfXB8KfMeSKl4WLGi6m3y4RGAiUqlCCO04VkG1Z9CmjBULiEgEtyynf1 FwQ8dRmZPhm6T48hRgRk8cnP9rrW1IlJNR/O3V4OuBIfrHnbYN72+nscObzhxGvzT0GK zahOI8SNnsX4q+hEx8S9uTWMIBd3TpEhm/wgAn1K4KSAxAKf3Zk7F0ns7XYcFLEzr7Zp L140AfshKUQ9zCxJ4ow+3Q/XTn9BcDlQSq9YuL5C1Za/F3qQi7nEIOZBgnVBKuz/obEy 0/nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YCfE9Lg4LDU/g5XnG00JmCSfe7L883ni9ZqhvKodx6Y=; b=jeym187b2kkdXQYZc5AO5SuWk9zeu5DR9/sgGRxHLBPpyyaWF5RhfBixKCwKsvjv/J yf4HgZuFuqr4sWX4v/UJCBmaRqV+uEjY25tF0uq6Fxs4k5GlvhPcDDQLEdh4yYAcg+Hm xkWJ5gqsFboQgPfBF7W4WyiwYEtbDNl9nwx3qbLRK8so44Nf2nV1hL2TqzIp3f+b8MET jLITi0nJGnFei75xxlcDR/WVpvkAuOEHakfUVFT0um8v8TwdjuRcHa1w+ycxCf0BoDp8 Bw9+usFphHiLEuoO30b3Oj7Oeu4p2tZpspZFkEQIuR5+p2znQWuHHRp9bONTLYSS/1xg OWyw==
X-Gm-Message-State: AOAM531OrX1HjbW3avFgjO/0+72ejVmo02KlFyCWSeCkOH75d/wKqHER XK7BQ53Fs14ra6tYuKTOfJpyhXBmDW6SxHcCgDAGkQ==
X-Google-Smtp-Source: ABdhPJxpaUH7h+OL5oHUgg3EQj98ntuMvtM7aMcFi44/4Y5aPZqqQhXQ7sBch1X81u7tjUcCIsZmjsaaoC54EoeJfAA=
X-Received: by 2002:a2e:a30a:: with SMTP id l10mr9382038lje.318.1624643140537; Fri, 25 Jun 2021 10:45:40 -0700 (PDT)
MIME-Version: 1.0
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: <>
From: Robert Raszuk <>
Date: Fri, 25 Jun 2021 19:45:29 +0200
Message-ID: <>
To: Claudio Jeker <>
Cc: Bruno Decraene <>, John Scudder <>, "idr@ietf. org" <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000047606305c59ab5a4"
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 17:45:48 -0000

Hi Claudio,

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

Right I was referring to some implementations then the spec.

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

FWIW we did document it clearly in RF6774.

The "Nth best path" really
describes set of N paths with different BGP next hops.

But I realize this discussion is about RFC7911.

I recall the intention was to keep the spec short but provide guidelines in
separate document:

Namely in draft-ietf-idr-add-paths-guidelines-08.

There you can see section is very clear on what paths should be
selected based on the three criteria:

     (a) not selected during a previous iteration

     (b)_diverse with respect to previously selected paths (see
section <>
     2 <>
for the definition of a diverse path)
     (c) not rejected by route filters or split horizon advertisement

for us key is (b) and diverse path definition says:

   Diverse path: A BGP path associated with a different BGP next-hop and
   BGP router than some other set of paths. The BGP router associated
   with a path is inferred from the ORIGINATOR_ID attribute or, if there
   is none, the BGP Identifier of the peer that advertised the path.

making it clear that sending N paths should have different next hops.

I am not sure why this draft was not progressed though. At least it is WG

Many thx,

> 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