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

Gyan Mishra <hayabusagsm@gmail.com> Thu, 24 June 2021 19:44 UTC

Return-Path: <hayabusagsm@gmail.com>
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 A038E3A28F2 for <idr@ietfa.amsl.com>; Thu, 24 Jun 2021 12:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5iIdNBxUvu1I for <idr@ietfa.amsl.com>; Thu, 24 Jun 2021 12:44:29 -0700 (PDT)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 38DEC3A28F0 for <idr@ietf.org>; Thu, 24 Jun 2021 12:44:29 -0700 (PDT)
Received: by mail-pj1-x1036.google.com with SMTP id bb10-20020a17090b008ab029016eef083425so6550026pjb.5 for <idr@ietf.org>; Thu, 24 Jun 2021 12:44:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=acSTMueS6cyjiCs/J6TFqsXqZFCm2p1K/nbONKGsIUo=; b=Dd/Ak1G7Bp2VRwXLO652+hQGgVaAHezOzoStgkCLdPHbAnvUW+ZaazmpoLwIjnbthz l6i2j2JRjgA8tov2ZW6NI9P9s9yTdjWMXRH6gIBma7KswYbQN2bo2ATplsrmxlgTg2z6 so7LkUYulENzhGbjNULBSHowDqriB1qF8vDut263FjqvqESfXQSP8RsNnPFBi1VRQigm 9qd+S17NlvnINTgtDGj3IB6hlMuvLnKlwX1/afZoACMxlcRnhCDIFraKvRKMOgN8/39X trPpx/i/V11NEzps2arLDOwnbBREgonogboOqCv4UKxTeaqhVKksnQ92F7/p3nHBx8jh dJBg==
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=acSTMueS6cyjiCs/J6TFqsXqZFCm2p1K/nbONKGsIUo=; b=N98Uz3uYMUjQRPDOM29eTiyeSiDtlif9LgRk3O1yd/va1d1eyzdbS8FFgfHI5qvT77 zkgKKMLbRZH+6c8+Mkg6Cu4YCo0qK73t9Wix3uxTADma09bosLe4rroBFMIALbofzAz4 tRIeVCUzapmZjZc7LWaLpxWLQgKpD3vTzo8UPBtTZh14+mvApjSung4R0VCWIsGH95l4 ELdAdapx+AypjIxVIEnZduUQqXwqMxV0+pgiQJ8P6WJ3COC42Chru4Ud6xMAfd1z1IZu NISMu3Td7kGc8WwryiRDs1m+jF+3G1JWX2npGs9hXk3Qpdc81Ifkp3l8Y8VdRwwoxexu rwVA==
X-Gm-Message-State: AOAM531XFGxoSnFikTk8yGErRl6nqITtBvfbQYAs3AKbfTJtFqDKWYoB Du8hvYD6bBgWwwjUI6Xd4tiPqmIxv8MnIIObihk=
X-Google-Smtp-Source: ABdhPJyjyKqvK2DCccWM2QM0a3BQ6y9FTy8z/5r9lordkNY4W6fdYefhqh+EtkNZh7TUoP1gTDh77NbRHC/9xXmz/+8=
X-Received: by 2002:a17:90a:4592:: with SMTP id v18mr7067290pjg.132.1624563867934; Thu, 24 Jun 2021 12:44:27 -0700 (PDT)
MIME-Version: 1.0
References: <F689CF63-236D-401D-9C8E-AC1C39CDE772@juniper.net>
In-Reply-To: <F689CF63-236D-401D-9C8E-AC1C39CDE772@juniper.net>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 24 Jun 2021 15:44:17 -0400
Message-ID: <CABNhwV2FcbXhj+RwDH_a9dWuR0yCgPdmT6U+kdbeB497D+DnvA@mail.gmail.com>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: "dwalton76@gmail.com" <dwalton76@gmail.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000043624205c58840b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0jyw-fRSzo1Flcjb7IYo1ZLAWeE>
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: Thu, 24 Jun 2021 19:44:34 -0000

Hi John

I agree that the tie breaking bug won’t form a loop as you stated as the
lowest IGP metric in the PE receiving the additional paths will ensue that
no loop will form.

So even though the tie breaker is not specified with RFC 7911, with all
attributes equal scenario, the oldest versus newest, first path received is
as you mentioned is the way most vendors implement the tie breaker.
However, even if done differently or arbitrarily it won’t form a loop due
to lowest IGP metric further up in the best path selection process.

Using the path-id as the tie breaker for add paths from the same peer makes
sense for the bis update.

Kind Regards

Gyan

On Thu, Jun 24, 2021 at 2:15 PM John Scudder <jgs=
40juniper.net@dmarc.ietf.org> wrote:

> Hi Folks,
>
> Claudio recently pointed out a bug in RFC 7911 to the authors, and we
> thought we should let the WG know. The gist of the bug is that the
> tie-breaking process is underspecified, because it’s technically possible
> to receive two routes for the same destination, from the same peer, with
> different path-id, and with all tie-break metrics the same (all the way
> down to peer address). My guess — but it’s only a guess, I haven’t checked
> — is that implementations may mostly have chosen to prefer the first path
> received.[*] But the only thing we can say with confidence is “it’s
> underspecified and therefore implementation-dependent.”
>
> When I worked through this, my conclusion was that whatever option an
> implementation chooses should be safe, since by definition the paths are
> equivalent all the way down. I don’t see a way to form a loop even if every
> router in the network makes arbitrary — and conflicting — choices in this
> situation, since by definition of IGP distance, if a given router A makes
> an arbitrary choice, none of its neighbors when presented with the same set
> of routes will make a conflicting arbitrary choice, since the options are:
>
> - The peer is closer to both destinations, in which case it can make any
> choice it wants, the traffic will not loop back to A,
> - The peer is further from both destinations, in which case it can make
> any choice it wants, the traffic will not loop back from A,
> - The peer is closer to one and further from the other destination, in
> which case it isn’t faced with a dilemma, it will choose the closer (and
> the traffic won’t go back towards A).
>
> I guess if you’re in a network that doesn’t have IGP distances at all
> (maybe everything is static routed?) or if IGP distances don’t follow the
> usual rules of IGP “physics”, then you could create a problem. But those
> are pathological cases where we’d expect BGP not to work very well anyway.
>
> Claudio suggested that path-id would be a good final tie-break; that makes
> sense to me. We could do a quick update to 7911 to standardize this new
> tie-break, we could do a bis of 7911 to include the new tie-break, or we
> could just leave things as they are, relying on my argument above that says
> there is no strong need to standardize a tie-break since any choice is OK.
>
> For the moment, this is just an FYI for the WG. Thanks very much to
> Claudio for pointing out the bug!
>
> —John
>
> [*] You may notice that it’s possible to have two such paths packed into
> the same update in some circumstances, which makes the choice even more
> arbitrary since it’s pretty notional to say one has arrived before the
> other.
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*