Summary

  • Revision 13 would make BGP path eligibility depend on a forwarding entry in the policy-selected data plane and, optionally, an OAM liveness result for that same plane.
  • The check can reject an IP-reachable but MPLS-broken next hop. A false or stale negative can also reject a healthy path and export the measurement error as a BGP routing change.
  • Operators need an explicit evidence record for plane, table, policy, method, freshness and exclusion reason, followed by independent forwarding and service-outcome checks.

The LSP was carrying production traffic. Its counters advanced, sampled packets reached the remote provider edge, and the customer application had not yet reported loss. The OAM session nevertheless timed out. BGP treated that negative as a reason to remove the path from consideration, selected the other next hop and advertised the change. The alternate was the path with the forwarding defect.

The safeguard created the outage it was designed to avoid.

That scenario is not a claim about a named implementation or incident. It is the inverse failure mode exposed by current expert review of draft-ietf-idr-bgp-bestpath-selection-criteria-13. The document, dated 14 September 2026, is an active IETF IDR Working Group Internet-Draft intended for Proposed Standard. It proposes to update RFC 4271 if approved; it is not an RFC. Datatracker says issues raised in expert review need resolution and a revised draft. The Routing Directorate rates it not ready, the Operations and Security directorates find issues, and the BGP Directorate considers it on the right track but not ready to advance.

The proposal starts from a genuine operational gap. RFC 4271 requires a route to satisfy its Route Resolvability Condition before it can enter the Phase 2 decision function. In a network that actually forwards to the BGP next hop over MPLS, ordinary IP reachability may be the wrong test. The IP routing table can still find the next hop while an MPLS forwarding entry is absent, a label binding is defective or the LSP fails somewhere between provider edges. The router keeps attracting customer traffic because control-plane reachability survives, while the selected data plane drops the packets.

Revision 13 proposes two refinements. First, next-hop reachability should be resolved in a forwarding database for the data-plane protocol selected by policy. If the intended plane is MPLS, examine MPLS forwarding state; if it is IP, examine the IP forwarding database. Second, a path-availability check may use an OAM liveness mechanism associated with that same plane.

This is a useful separation. It is also the moment at which a measurement crosses into authority.

A negative result is an instruction only after policy interprets it

The draft says the OAM check may be performed. It leaves the mechanism, the selected plane and the policy outside scope. It permits an on-demand check or a result established in advance. Its conclusion describes continuing to advertise or withdrawing reachability according to next-hop reachability or availability, yet the normative core does not state precisely what a failed check does. Current reviewers have asked for that relationship to RFC 4271 to be explicit.

That gap matters because “probe failed” is not one state. The path may be down. The probe process may be overloaded. Authentication may fail. A control packet may take a different fate from production traffic. A stored result may be older than the forwarding change it is being asked to judge. A session may not yet have converged after startup. An attacker may drop, delay, replay or spoof the observation. An ECMP member can fail while the member tested by the probe still works, or the probe can fail while other members continue to forward.

Collapsing all those cases into unresolvable gives an uncertain observation a deterministic consequence. A safer decision model needs at least three states: positive, negative and indeterminate. It needs a declared rule for how long each result remains valid, what evidence can override it, and what happens during initialization or disagreement. Those are operator controls, not requirements supplied by revision 13.

The Security review makes the authority transfer plain. If a liveness mechanism can remove a next hop from candidacy, anyone who can disrupt that mechanism can affect every route using the next hop under the enabled policy. BGP may propagate the local observation beyond the point where it was made. In a dual-homed network, selective disruption can steer traffic to the other provider edge, not merely deny service. A false positive produces the original blackhole; a false negative can withdraw a good route. Both directions matter.

BFD and LSP Ping illustrate the point, although the draft does not select either. RFC 5880 discusses false up and false down declarations as BFD security risks. RFC 8029 discusses spoofing, replay and tampering around MPLS LSP diagnostics. Authentication can protect some message integrity and origin properties. It cannot force an on-path adversary to deliver the probe, nor prove that production packets sharing only part of the path receive identical treatment.

“The forwarding database” is not a sufficient address

The first criterion sounds simpler because it asks for state already held by the router. Yet a large provider edge does not have one self-explanatory table. A customer destination can be resolved in a VRF while a tunnel endpoint is resolved elsewhere. There may be multiple instances, address families, label tables and recursive steps. Policy may choose a data plane per neighbor, per SAFI or both.

The Operations review therefore asks which table has authority when the destination and tunnel endpoint live in different places. The current text says a forwarding database of a particular data-plane protocol, not the exact context. That leaves room for two implementations to answer the same route differently while each believes it followed the document.

For an operational decision, the evidence key must be specific: route and path identity; peer; AFI/SAFI; VRF or routing instance; selected plane; selected table; recursive endpoint; policy version; forwarding-entry generation; optional OAM method; result; result time; and decision reason. Without those fields, “MPLS unavailable” cannot be reproduced. A later policy change can make yesterday's decision unintelligible even if the log itself survives.

The reference chain also needs modernization. Revision 13 still cites RFC 5512 for tunnel encapsulation, although RFC 9012 obsoletes it and itself changes aspects of resolvability. Reviews point to SR Policy and later colored-resolution work as further context. This is not editorial housekeeping. Precedence among resolution mechanisms determines which state gains authority when they disagree.

Liveness is not delivered service

A successful same-plane check is valuable. It can show that a defined mechanism received the response it expects for a next hop in a bounded interval. It may corroborate a forwarding entry. It does not prove that every equal-cost member works, that every FEC maps correctly, that the customer VRF lookup succeeds, that the destination accepts the packet or that an application completed its transaction.

The evidence chain is longer:

  1. BGP received a path and next hop.
  2. local policy selected the data plane and table context;
  3. the forwarding state existed under a named generation;
  4. an optional liveness method produced a time-bounded result;
  5. policy interpreted those inputs as eligible, ineligible or indeterminate;
  6. BGP reran selection and recorded the reason;
  7. the router installed forwarding state and sent any update;
  8. neighbors processed the update; and
  9. independent traffic or application evidence established the outcome.

No one step proves all the others. A withdrawal is a control-plane act, not proof that traffic stopped at the intended boundary. A positive OAM reply is a liveness receipt, not a service receipt. An alternate best path is a selected candidate, not a delivered customer session.

Reversibility is part of correctness

The draft says convergence is not expected to be harmed, apart from implementation specifics. The reviews challenge that assurance. Per-next-hop sessions across a provider-edge mesh have cost. A flapping result can repeatedly remove and restore many routes. Withdrawals and readvertisements can escape toward customer edges and perhaps farther. Mixed deployments can give adjacent speakers different candidate sets. The observation system becomes a feedback loop inside routing.

An enablement plan therefore needs a shadow phase. Compute the proposed eligibility result without allowing it to change best-path selection. Compare it with forwarding counters, independent probes and application outcomes. Record how often the result would have excluded the selected path, how often it disagrees with traffic, how stale it becomes, and how many routes share the judged next hop. Only then can an operator define activation thresholds, hysteresis and rollback.

Rollback must restore a known policy and trigger reevaluation of affected routes. Merely stopping the probe can leave ambiguous cached state or cause another transition. The operator needs an inventory of routes disqualified by the mechanism and a reason code that distinguishes missing forwarding state, negative OAM, expired evidence, unavailable method and administrative override.

Revision 13's deepest value is that it refuses to let an IP route stand in for a data plane it cannot describe. Its unresolved risk is the symmetrical substitution: letting one data-plane signal stand in for forwarding truth, route policy and service outcome at once. The standardization task is not to choose optimism or pessimism. It is to make the authority, evidence and failure mode explicit enough that a wrong measurement can be seen and reversed before BGP carries it elsewhere.

Sources