Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12
Alvaro Retana <aretana.ietf@gmail.com> Thu, 09 January 2020 20:43 UTC
Return-Path: <aretana.ietf@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 A0B84120853; Thu, 9 Jan 2020 12:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: 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 PvNufFqjdJnN; Thu, 9 Jan 2020 12:43:38 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 37EDA12082E; Thu, 9 Jan 2020 12:43:35 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id e10so6799989edv.9; Thu, 09 Jan 2020 12:43:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 gmailapi.google.com with HTTPREST; Thu, 9 Jan 2020 12:43:32 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAMMESsz1R9u4fJUkFr0wxd8OF3u==PvPkr+6t7sXHNGaPR2-tQ@mail.gmail.com>
References: <CAMMESsz1R9u4fJUkFr0wxd8OF3u==PvPkr+6t7sXHNGaPR2-tQ@mail.gmail.com>
MIME-Version: 1.0
Date: Thu, 09 Jan 2020 12:43:32 -0800
Message-ID: <CAMMESsxbetZAWvSSaYU3DS0W_CASzP7YeCnEpFyoURfd1uZRgg@mail.gmail.com>
To: idr-chairs@ietf.org, "idr@ietf. org" <idr@ietf.org>
Cc: Susan Hares <shares@ndzh.com>, draft-ietf-idr-bgp-bestpath-selection-criteria@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/gvMuPQQU29-5VLLLOiNJlYcAOK4>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12
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, 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!! Alvaro. [*] The full review is here: https://mailarchive.ietf.org/arch/msg/idr/85qTCgN4k6oAbSlKmpyi8stxZz0 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 > (§9.1.2.1/rfc4271). 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] https://mailarchive.ietf.org/arch/msg/idr/jWNhfTvHbaY3rEk5nTYahS5w6_Q > [2] https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria > [3] https://mailarchive.ietf.org/arch/msg/idr/Yr9u6V2HKrHEuQLtFw7aDstMPzg > [4] https://mailarchive.ietf.org/arch/msg/idr/kiTwL6ApC_k9QFrfhaMA_qC8BcA > [5] https://mailarchive.ietf.org/arch/msg/idr/OqsCexPPmtvKjHNJzf4EcpwPhtQ > [6] https://mailarchive.ietf.org/arch/msg/idr/OVg6Cfr3EUwIRcQS6cIkwq_dUtI > [7] https://mailarchive.ietf.org/arch/msg/idr/lezFHSGaOzvL2h16M883beeHcjI > [8] https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bestpath-selection-criteria/shepherdwriteup/
- [Idr] AD Review of draft-ietf-idr-bgp-bestpath-se… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpat… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpat… Rajiv Asati (rajiva)
- Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpat… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpat… Rajiv Asati (rajiva)
- Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpat… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpat… Rajiv Asati (rajiva)