IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Fri, 25 June 2021 13:12 UTC

Return-Path: <robert@raszuk.net>
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 531513A168C for <idr@ietfa.amsl.com>; Fri, 25 Jun 2021 06:12:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 ItmKP-dJPqQ9 for <idr@ietfa.amsl.com>; Fri, 25 Jun 2021 06:12:13 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B993A1685 for <idr@ietf.org>; Fri, 25 Jun 2021 06:12:13 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id u13so16230395lfk.2 for <idr@ietf.org>; Fri, 25 Jun 2021 06:12:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NVvUKW8yaTpJI3caY/hVqZo/JhgcwhjARKUDPY6TIBs=; b=Hz5KyW+WBn/sVID8NhvsD4x+trwEjeZO86lzBd8kTGxcRed1ga+2LyBZd81HEprPWM dkN7dwq+wbwl+/g+QdruQb1KsqYC6aIW2vQ02cTgPv4qP9wxNsuCEE6ce2SFnMhotVoI Du533b4ucZ/CR7YOFFnDa7kZBrukcFHoUSFx80MoOeXUXcr2UYV9KIxMptVgKLz3Y9z1 iAN03nbYarp0HXznfzU0s1ujBKUJmw0kjufF0Ra3WGewnEVeBboLoQBzqewszh21k9IO V03pBHZTuRMXHlk02Uk5ZBxE8DSf0fV9kESBg+HRjI528wcgk+ubDNkgbUSbkSH6NRJR vECg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NVvUKW8yaTpJI3caY/hVqZo/JhgcwhjARKUDPY6TIBs=; b=ofBnVfOH1yeZbFtPT2vH4PZktrmBOEFz0SW8At065BGOMY0qFGNZkVPbKRg70n/WV7 OtFao4W7U57zQdXTmUEw2KAAH9xfQvtbemSrVsy+rbVvABMpU1w5Uh4Ni4xFfuQ10S2e idifoaPZvF4rJiTIX1TZqsukbh9IeFruu5RN0wU+EgyvMPPRNaUbhE8UFc2bTFl3yDos q1y74UjUMau5gMmHzjL/3MnQoYA9zRpsvviZiwaeF7DOdHQ/OBcMx3j9CHqPwnbuMmor ZBF+Qe3Wk7zZ+Qw9ou3L4vxni1ODhUDyFhXe6HGQ4A9L4F0g3yikuWKw35fT/A4ZuBrC jQWA==
X-Gm-Message-State: AOAM532S4eekqL1hs4SReeThlDYe5PB51MpIBssgNlNouNg0r9fNb3Xk G2pKsqgo+L2Gp/rlcU5xa8sORR+QsGVIO78vIDywmw==
X-Google-Smtp-Source: ABdhPJwgTRbmCqgQHiZg77BMuyDaGEuZJAx5zsEbEHDMBPHwxikqONxoHVFYOooYz120BrWrT3oUwRvo6TUgqJsrMQU=
X-Received: by 2002:ac2:5feb:: with SMTP id s11mr7902790lfg.591.1624626730831; Fri, 25 Jun 2021 06:12:10 -0700 (PDT)
MIME-Version: 1.0
References: <F689CF63-236D-401D-9C8E-AC1C39CDE772@juniper.net> <20976_1624607831_60D58C57_20976_28_1_53C29892C857584299CBF5D05346208A4CDF9BB2@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <20210625083735.GB31038@diehard.n-r-g.com> <19431_1624612909_60D5A02D_19431_174_7_53C29892C857584299CBF5D05346208A4CDF9FB9@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAOj+MMFnge_s=_RNt06h=2s19JoSptetRo7cE+XoVDBSxFvL2g@mail.gmail.com> <6424_1624619306_60D5B92A_6424_261_1_53C29892C857584299CBF5D05346208A4CDFA365@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <6424_1624619306_60D5B92A_6424_261_1_53C29892C857584299CBF5D05346208A4CDFA365@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 25 Jun 2021 15:12:00 +0200
Message-ID: <CAOj+MMFjKdDdaJdMYb5i56Ha+D8At36PwL9dpxiLOxG_6DZVkw@mail.gmail.com>
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: Claudio Jeker <cjeker@diehard.n-r-g.com>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, "idr@ietf. org" <idr@ietf.org>, "dwalton76@gmail.com" <dwalton76@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000002f2ed305c596e3c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OVP2njTjrx_XbZs_-60Y2xTyqz8>
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: Fri, 25 Jun 2021 13:12:18 -0000

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.

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

Thx,
R.

v2.23.0 | Report a Bug | By Email