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

Robert Raszuk <robert@raszuk.net> Thu, 24 June 2021 20:40 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 2C18C3A2A67 for <idr@ietfa.amsl.com>; Thu, 24 Jun 2021 13:40:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 xcqisVDBhA0c for <idr@ietfa.amsl.com>; Thu, 24 Jun 2021 13:40:15 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 64CFB3A2A68 for <idr@ietf.org>; Thu, 24 Jun 2021 13:40:15 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id a11so12432911lfg.11 for <idr@ietf.org>; Thu, 24 Jun 2021 13:40:15 -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=cvZrokp1pUkorE0AFLy95Z0rAANxgDje8Qn2AAOmcuE=; b=ONzVlwh36fSlvXHT9w+U2doilcDoV9qmF+UMw5Kxalamvn06SmHXiC6s75Z6heFy/i jRXv98RfWsJJ6r5xuFdswhOoqwd2mxQvm4NPzAiV6C79Uj8iY4KbRcs40rX8dPffhVxr V/1WPI7D8Zu/zlrrUb0Kb1Us6D9UyCHWv7Oj7SJfvq70sBBFi5EqvtHZ/UIncb40PLf3 3b3gI8sI0YjQWkXQlc5p0HUuTVFHH6SqIFnz6sR8aitW6tI1BEvIecSzkA36NKI0vlNN FQP8ubsZl2dFExiJkUj8DgDzw551vHM+kD4en74MhCR+yOw1aUusFapM42jXZIJv25y4 kozA==
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=cvZrokp1pUkorE0AFLy95Z0rAANxgDje8Qn2AAOmcuE=; b=j3utQ3H6pALbH5Joglkt4rHZe4caZIlKah4QllOtGX/jqERoidTUhLvrw/QBy8Xo2l 4d5WdHWy6itlfpOcdPkBsdVYkK2xbqTyvfodnzc9lkKGuTOKgGkrpg84gAdnincHlSBQ mY7jwlMoaVEVTVjOcYUFJmwcOLI1RO82iYr3bZaoihP5m2wejf3rTNm0CwhwHMfQWfQu Lp5l0HGrk1xS/Wq4TbQIjYxVyheerf0VKBYUhzOxdgkoQi15bhd/M7R1cSJ5OF8qdqsE 5S6hvj9ptz3OyCtNZxHyqKLNHYOVoJ285N0z8pm9fJ720EhAAnG3/ePlIGQ5ku9MX/Si hWww==
X-Gm-Message-State: AOAM533mdvIqDH2+QNmbFJYdC5H2C04iA2FXrIYeZLntjWyn9Jn/XiNT ZxLOEfSJy9dfikvrmhlJjqUjEORWyqbHVKu6Qfa8o56beZi8CZvR
X-Google-Smtp-Source: ABdhPJxOdluLE28blfixSWERaXk1XmeUNQXHYmY3mOQk88/0KNJyv9aPOyIGblpPsXmMogaLjXJyHjNcU6SohO7TMns=
X-Received: by 2002:a19:ef0e:: with SMTP id n14mr5287686lfh.36.1624567208450; Thu, 24 Jun 2021 13:40:08 -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: Robert Raszuk <robert@raszuk.net>
Date: Thu, 24 Jun 2021 22:39:57 +0200
Message-ID: <CAOj+MMHg1f2rFNHZLM-j7Jx-ji_zWLhesmrNdS5LWfsNk_x9sw@mail.gmail.com>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: "idr@ietf. org" <idr@ietf.org>, "dwalton76@gmail.com" <dwalton76@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005fb7a605c5890753"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Y2c9pgopkWZmymkzYETlabR79KY>
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 20:40:20 -0000

John,

> 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

While this is not about risk of loops, those paths may possibly contain
different optional attributes otherwise they would be rather duplicates.

More specifically one of them may contain additional optional attributes
while the other may not.

Perhaps with add-paths while we are at this discussion it may make sense to
choose the path with a longer list of BGP path attributes as such path may
be more useful to receivers.

Only then when the number of such attributes  is the same fall to path_id
as tie-break.

Thx,
Robert


On Thu, Jun 24, 2021 at 8: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
>