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

From: Alvaro Retana <[email-masked]>
Date: Thu, 9 Jan 2020 12:43:32 -0800

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/