Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12

Alvaro Retana <> Thu, 09 January 2020 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0B84120853; Thu, 9 Jan 2020 12:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PvNufFqjdJnN; Thu, 9 Jan 2020 12:43:38 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37EDA12082E; Thu, 9 Jan 2020 12:43:35 -0800 (PST)
Received: by with SMTP id e10so6799989edv.9; Thu, 09 Jan 2020 12:43:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=V7Z/1bvUgL+0d/pTAHvCvwNgYl01hBMdM1D6C95q5VY=; b=Orc+LiXeOWRThRLgHKeo/fEyhSRqwPuN4hpxdtMUjauhtIv4OgsVCMmyLpgOxXnhVS ZJ/JPxHmQwDiMet1f2RDGmJdK8w+zQpGZR/RAFzVnH7jDKIsbPE/F8JeHoAILBXqdeFN 0xwgKsrPya15TbnPiy+m4wqmdUjigR6/uXnqLuC6FnJqQRhWj0zmIEknaCqU18VKQch/ b5JT2Y5W8i5ZSGlV1Dw00RDFxn0qdNZFnF8VWm452ngu/Igc7KO+2TK94SmB5LGuOafP IDJ8MsTBVBvGmmFgJKEKZ5DUbmMSWOJCYhKZzoA6wtd6qf3w3oQtMu7OynYzkGME3xig OzeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=V7Z/1bvUgL+0d/pTAHvCvwNgYl01hBMdM1D6C95q5VY=; b=sZbyGpjhFvnP9ktf9ae2apBq9nxLKInscaEQzFN+l8ul+rjcSNn30qhz9WjFvMkBfI PisqE+NFCFfuRbqjvsmyhBJeQV2XaS+Q9xdd2kpCEf44wlWVXpbj0/CfK3QRkzk02gEf erR5nlo5N8hnvTX9nchD/86M2zMbMn+jmZ9BrFsvxVdedxxZZnpFMo0E1y7xELAbr8z+ 6xeJYh5OVkEG4v9+UuHQ9B3x9RE87nV7pqRzensqy2r2nGFCcS7Wj5wmbJ8OPYrPxuqI gSsHz70Sip9Xw0EkU7U9Zz4EwVIPuT2g5XraVhDVwzrfIn1HayEgRyjJRbAfP+zG9BJm +jnQ==
X-Gm-Message-State: APjAAAWP6KJ0CmgIAJp7k1bJ9f4nhXb3QKzGz4uRkbILMvWFe9Cn2CYU VCnl7mFHWL3K4c3GEWydvOz7cwKRYSKYd5yY3Hi6hQ==
X-Google-Smtp-Source: APXvYqyh5ckeyPAJSPc6IIqeHYiQ4T2FLkSwdBYii3FVfMbkIXGfhWAiTJhGnhzkfuy9YtmlY8ubzP7O3iDRguKMwGU=
X-Received: by 2002:a50:ef1a:: with SMTP id m26mr13100328eds.289.1578602613384; Thu, 09 Jan 2020 12:43:33 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 9 Jan 2020 12:43:32 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Date: Thu, 09 Jan 2020 12:43:32 -0800
Message-ID: <>
To:, "idr@ietf. org" <>
Cc: Susan Hares <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12
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: Thu, 09 Jan 2020 20:43:41 -0000

Dear Chairs/WG:

Happy New Year!

I am returning this document to the WG for further discussion.

Rajiv, Sue and I had a very fruitful conversation while in Singapore
at the last IETF.  We agree on the technical issues, but (as explained
in my review -- I left the header below [*]) my concerns go beyond the
content and into the Status of the document and the general interest
from the WG in this work.

Sue/John:  I need you to explicitly collect feedback from the WG and
reevaluate support for the document's content and status.
Specifically, we need a *discussion* about the first two points
mentioned below.

Thank you!!


[*] The full review is here:

On July 17, 2019 at 4:15:57 PM, Alvaro Retana wrote:

> Rajiv:
> Hi! How are you? I just finished reading this document.
> First of all, thank you for your patience and perseverance in sticking with
> this document for so long!
> Having said that, I have significant issues with the document. I have
> specific in-line comments below, but I want to highlight some of the bigger
> issues now -- please note that while you are the Author, the issues called
> out here are directed at the WG/Chairs/Shepherd as well.
> (1) What is the Update to rfc4271?
> The document presents two amendments to the Route Resolvability Condition
> (§ The first one is straight forward and obvious: resolve
> the next-hop using the correct Routing Table.
> The second one is to check the "path availability" to the next-hop. While a
> good thing to do, and optional, it introduces in the BGP Decision Process
> unspecified functionality that depends on external mechanisms...which, in my
> opinion, should be used to maintain the Routing Table and not be specifically
> a part of BGP.
> Both the policy to drive Amendment 1 and the expectations of the check in
> Amendment 2 are not specified and declared out of scope. IOW, the
> specification is to do something that is not specified. Back to my question:
> what is the Update to rfc4271?
> I didn't find a discussion on the list about the Update: either about
> formally Updating rfc4271, *or* what the Update would be. I did find a note
> [1] that says "our AD requested we move the document from Informational to
> Standards track, and add 'Updates: RFC 4271'"...but there was no discussion;
> in fact, no reply at all.
> [Disclaimer: I was not the AD in 2011.]
> Related to this point, and specifically to the "path availability"
> functionality... In the Implementation Report [2], one of the implementers
> reports support for "path availability check in several variations, but not
> all. For example, BFD may be used to protect MPLS generated nexthops for LDP
> and RSVP. For IP nexthops distributed via an IGP, the IGP may be protected
> using BFD." Because the "path availability" functionality is not specified in
> this document, then I'm not sure whether either of these satisfies this
> document...but both mechanisms described are about protecting the next-hops
> (and presumably triggering FRR, for example), and not specifically about
> providing BGP with an indication of availability to forward traffic (which is
> my interpretation of "path availability").
> To be clear: I mention this text from the Implementation Report not to
> criticize the implementation...but to support the points that (1) the
> specification in this document is incomplete, and (2) that the OAM mechanisms
> should be used to maintain the Routing Table (and not just interact directly
> with BGP). IOW, I believe that the implementation is doing the right
> thing...but that is not what is described in the document.
> [See more related comments in §3, after Amendment 2.]
> (2) WG Discussion (...or lack of...)
> As I mentioned above, there was no discussion of the Update in the WG. In
> fact, the only significant discussion was during adoption [3] -- at that
> point the draft was Informational and it didn't Update anything.
> The WGLCs [4][5] show only 1 comment, and no other explicit show of support.
> Not even the usual "support...+1...+1...".
> I went back and looked at the minutes from IETF 73 [6], which is where the
> draft was presented for the first time, but there was no feedback there.
> draft-asati-bgp-mpls-blackhole-avoidance, which was presented at IETF 68, was
> the precursor of this document. The minutes from that meeting [7] show not a
> lot of excitement and minor support for perhaps an Informational one-page
> document saying "please be careful about selecting a next hop".
> One last note on this point. The Shepherd's writeup [8] reads:
>    (9) How solid is the WG consensus behind this document? Does it
>    represent the strong concurrence of a few individuals, with others
>    being silent, or does the WG as a whole understand and agree with it?
>    Solid in 2009. As time goes on waiting for implementation reports,
>    the memory of those days weakens. However, since 2 major vendors
>    have implemented and deployed this RFC - the solid WG
>    support from 2009 has been validated.
> The draft was adopted with rough consensus [3], so I don't interpret
> implementations in this case as strong validation mainly because I don't see
> a clear specification.
> All this leads me to ask: Is this work (many years later!) still something
> the WG wants to progress? Or has it been taken over by events? Is the
> document in it's current form what the WG thought it was adopting?
> I am looking for discussion and specific opinions (not +1s!). I would be very
> happy if someone pointed me to discussions I missed in my search.
> (3) Terminology
> In general, I think that most idr participants would clearly understand the
> terminology used in this document. However, the audience is wider than that,
> and the terminology used doesn't correspond to that in other work.
> For example, the first sentence in the Abstract reads:
>    BGP specification (RFC4271) prescribes 'BGP next-hop reachability'
>    as one of the key 'Route Resolvability Condition' that must be
>    satisfied before the BGP bestpath candidate selection.
> rfc4271 doesn't talk anywhere about reachability or a bestpath.
> Please be consistent with the terminology in other RFCs, specially rfc4271.
> Introducing new terms is fine, if they are needed and properly explained.
> Given the points above, I am inclined to return this document to the WG for
> further discussion. I really don't want to do that given its long history, so
> perhaps we can use some time next week in Montreal to talk face-to-face.
> Thanks!
> Alvaro.
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]
> [7]
> [8]