Hello, I have been selected to do a Routing Directorate "early" review of draft-ietf-idr-bgp-bestpath-selection-criteria. The routing directorate will, on request from the working group chair, perform an "early" review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. The state of this draft is a bit unusual in that it did pass WG Last Call and had an AD review six years ago but did not advance further at that time. Since then the WG has re-chartered and requested that it be given an early review. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Document: draft-ietf-idr-bgp-bestpath-selection-criteria-13 Reviewer: Donald Eastlake 3rd Review Date: 25 September 2026 Intended Status: Standards Track Summary: I have significant concerns about this document. It needs more work before being submitted to the IESG. Overview: The problem addressed is real: A BGP speaker can blackhole traffic if it selects and re-advertises a path whose next hop is reachable in the IP RIB, but not usable in the data plane that would actually be used to reach it. The document is short and readable although the English should be improved. The normative core (Section 3) is two sentences related to the RFC 4271 resolvabilty condition. One is a SHOULD, the other a MAY, and both defer the details to "policy" and "out of scope". Neither states what happens when the check fails. The document also predates significant later work such as RFC 9012, which obsoletes the cited RFC 5512 and already modifies the resolvability condition, and SR Policy. The text shows its 2019 origins in dates, boilerplate, and references and needs to be updated. Comments and Questions: 0. The second sentence of the Abstract seems unclear. I think it would be improved by just removing that sentence and making the first and third sentence into a one paragraph, two sentence Abstract. But it could probably be further improved beyond that change. 1. The consequence of a failed check is not clearly specified (Section 3). RFC 4271 Section 9.1.2.1 says an unresolvable route MUST be excluded from the Phase 2 decision function. This document doesn't say that a route failing check (1) or check (2) is to be treated as unresolvable for the purposes of Section 9.1.2.1. It only implies it in Section 4 ("continue to advertise ... or withdraw"). Perhaps add something like: "If a route fails either check below, it MUST be considered unresolvable for the purposes of Section 9.1.2.1 of [RFC4271]." 2. The update to RFC 4271 should be more explicit. For example, giving OLD/NEW text for Section 9.1.2.1, or at least state precisely which sentence is being changed and how. Currently a reader has to infer the relationship. Section 9.1.2.1 already speaks of an address that "is not resolvable", without defining resolvability in terms of a particular table. What is this document's effect on that notion? 3. What "resolved in a forwarding database of a particular data plane protocol" means is not specified (Section 3, item 1). Within a single data plane there are several distinct things this could test. For MPLS, for instance: an LDP-derived label forwarding entry for the next hop; a Segment Routing prefix SID; an RSVP-TE or SR Policy tunnel terminating on the next hop; or, for a directly connected next hop advertising implicit null, no labeled entry at all. Where the next hop is itself reached via a BGP labeled unicast route, resolution recurses, and the document does not say how far. These are not equivalent, and two implementations reading this text differently will make different best-path decisions on identical inputs. I suggest the document state the underlying requirement rather than enumerate cases: once policy has selected the data plane, the check MUST be made against the forwarding state the speaker will actually use to forward traffic to that next hop, including the specific label distribution or tunneling mechanism, and following the same recursion as forwarding. A few of the above as illustrative examples would help. Separately, why is item (1) a SHOULD rather than a MUST once a data plane has been selected by policy? When is it acceptable not to perform the check? Here is some possible text to be used in item(1): "Once policy has selected the data plane protocol for a given neighbor/SAFI, the check specified above MUST be made against the forwarding state that the BGP speaker will actually use to forward traffic to that next hop, including the particular label distribution or tunneling mechanism involved. For example, in an MPLS data plane the relevant state may derive from LDP, from Segment Routing prefix SIDs, from an RSVP-TE or SR Policy tunnel terminating on the next hop, or from a BGP labeled unicast route (in which case the check follows the same recursion as forwarding). Where the next hop is directly connected and the neighbor has advertised implicit null, the relevant state is the unlabeled entry that will carry the traffic. A check made against forwarding state other than that which will be used is not sufficient to satisfy this condition." 4. Relationship to RFC 9012 and newer transport-selection work: RFC 9012 Section 7.1 already states that a route whose Tunnel Encapsulation attribute contains no feasible tunnel MUST NOT be considered resolvable for the purposes of RFC 4271 Section 9.1.2.1, and Section 6 of RFC 9012 defines tunnel feasibility, including reachability of the tunnel egress endpoint. That overlaps item (1) whenever the data plane is signaled via the Tunnel Encapsulation attribute. The document should explain what it adds beyond RFC 9012 and ensure the two are consistent. Similarly, SR Policy (RFC 9256 and its BGP signaling) and the WG's transport-class / colored-resolution work all define how a BGP next hop is resolved. The document probably should say how it relates to them: is it a general framework that these mechanisms instantiate? If so, say so, and consider whether they should reference it. 5. Operational considerations are missing, particularly for item (2). Making best-path selection depend on OAM liveness (BFD, LSP Ping, etc.) may introduce risks the document does not mention: - Route churn and oscillation when liveness flaps. This includes propagation of withdraw/re-advertise churn to CEs and possibly beyond the AS. Should there be guidance on hold-down, hysteresis, or damping, and on interaction with route flap damping? - Scale: per-next-hop liveness sessions on a PE with many remote PEs. - False negatives (control-plane-limited OAM failing while the data plane works) and false positives (OAM succeeding while some ECMP members or FECs are broken). - Behavior when the selected OAM mechanism is unavailable or not yet converged at startup. Is the route resolvable or not in the interim? - Re-evaluation: RFC 4271 requires the decision process to be re-run when resolvability changes. It should be stated that a change in check (1) or (2) status triggers re-evaluation. The claim in Section 4 that the amendments are "not expected to negatively impact BGP convergence" is unsupported and should be removed or justified. An Operational/Manageability Considerations section (see RFC 5706) is probably warranted. (Some people believe that all IETF drafts should have an Operational Consideratons section.) 6. Consistency and loops in hop-by-hop IP forwarding: When the chosen data plane is tunneled (MPLS, MPLS-in-IP), a PE's local exclusion of a path mostly affects that PE. But when this change is applied to plain IP networks, and routers within an AS apply different resolvability criteria, or see different liveness results, they can make inconsistent hop-by-hop routing decisions, which can create loops. 7. Security Considerations seem inadequate. The section says the document imposes no additional security constraints and claims a benefit (rejecting routes with arbitrary next hops). That benefit already exists under base RFC 4271. More importantly, item (2) creates a new attack surface: an attacker able to disrupt, block, or spoof the liveness mechanism can cause routes to be withdrawn, i.e., a DoS that is amplified by BGP propagation. Conversely, spoofed liveness could keep a broken path selected. The security properties of the chosen OAM mechanism become relevant. A reference to RFC 4272 would also be appropriate. 8. Section 3, item (2): "The data plane protocol for this criterion MUST be the same as the one selected by the previous criterion." Since item (1) is only a SHOULD, what is required when item (1) was not performed? 9. Section 3: the per-neighbor / per-SAFI policy discussion only covers IPv4/v6 and VPNv4/v6. Please say whether the mechanism is intended to apply to other AFI/SAFIs (EVPN, BGP-LU, L2VPN, MVPN, Flowspec redirect-to-IP next hops, etc.) or is limited to those listed. 10. Section 3 cites RFC 5512 as a way to convey the chosen data plane. RFC 5512 is obsoleted by RFC 9012. Replace it, and see point 4. 11. The problem statement (Appendix, Section 8) seems like important motivation, not supplementary material. I suggest moving it into the body as a "Problem Statement" section after the Introduction. (Also, by convention, appendices follow the References.) 12. Section 8.1.2: "Unless PE2 withdraws the route via the routing protocol used on the PE-CE link, CE1 will not be able to activate the backup link." I believe this should be PE1. PE1 is the PE attached to CE1. 13. Section 3, item (2) says the path availability mechanism is out of scope. That is reasonable, but please give a few informative examples with references: BFD (RFC 5880/5883), BFD for MPLS LSPs (RFC 5884), LSP Ping (RFC 8029). 14. Boilerplate, header, author info: Normally these would just be nits but there are sufficinetly numerous that I think they qualify as a minor issue. The page headers say "June 5, 2019" while the front page says Sep 14, 2026. The copyright year claimed is 2019 which may make the copyright notice invalid. The legal boilerplate is outdated. The draft name line includes ".txt". Author affiliation is missing ("Independent" or the like can be used if appropriate). The running title ("Enhanced") does not match the document title ("Enhancement"). I suggest moving to xml v3 (RFC 7991) and running the nits checks. NITS - References: - [RFC4978] is the IMAP COMPRESS extension. The 6PE RFC is RFC 4798. - RFC 4364 is only used in the Appendix and should probably be - Informative. - Replace RFC 5512 with RFC 9012 (see above). - Use the current BCP 14 boilerplate (RFC 2119 plus RFC 8174). - Abstract: should state "This document updates RFC 4271." Should not reference the Appendix. "one of the key 'Route Resolvability Condition'" -> "one of the key 'Route Resolvability Condition' criteria". "would desire further granularity" -> "needs further granularity". "This document defines enhances" -> "This document enhances". - Section 1: "(section#9.1.2.1 of RFC4271]" -> "(Section 9.1.2.1 of [RFC4271])". "neigbhor" -> "neighbor". "data plane protocol other than IP" -> "a data plane protocol other than IP". - Section 3: "This document proposes" -> "This document specifies". Inconsistent "next-hop" / "Next Hop" / "nexthop". Pick one. - Section 4: "discussed in section 2" -> "Section 3". Consider removing the "Conclusions" section, folding useful content into the Introduction. - Section 6: I think the usual thing to say is "This document does not request any IANA actions." - Section 8.1.1: "a.b.c.d." has an extra period at the end. "mal-functioning" -> "malfunctioning". "in the context of figure 2" is redundant after "as shown below in Figure 2". - Section 8.1.1: "select an alternate bestpath via that next-hop (such as PE3)" reads oddly. Suggest "select an alternate best path via another next hop (such as PE3) whose LSP is functioning correctly." Thanks, Donald =============================== Donald E. Eastlake 3rd d3e3e3@gmail.com