Early Review of draft-ietf-idr-bgp-bestpath-selection-criteria-13
review-ietf-idr-bgp-bestpath-selection-criteria-13-rtgdir-early-eastlake-2026-09-27-00

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