Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft.

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.


- Document: draft-ietf-idr-bgp-bestpath-selection-criteria-13

- Reviewer: Venkata Ramanaiah Chintha

- Review Date: 2026-09-30

- Intended Status: Standards Track (Updates: 4271)


---

## Summary

Has Issues: I have some concerns about this document that I think should be resolved before publication.

The problem is real and well described. I have seen this failure in live MPLS VPN networks - a PE keeps attracting traffic over an LSP that is not actually forwarding - and the Appendix makes the case clearly. Three implementations exist.

My difficulty is that -13 is identical to -12 apart from the dates, and -12 is the version that went to AD Evaluation in 2019 and was returned to the working group. The questions raised then were operational ones, and as far as I can tell they are still open.


## General Operational Comments / Alignment with RFC 5706bis

This document changes BGP path selection so that a path's eligibility depends on data plane forwarding state and, optionally, on an OAM liveness result. That is a sound response to a real failure, but it introduces a new dependency into the decision process, and the document does not discuss what happens when that dependency is itself wrong.

There is no Operational Considerations section. draft-ietf-opsawg-rfc5706bis, currently with the IESG as a proposed BCP, requires one for new protocol RFCs. For a routing document, RFC 6123 is a reasonable model for what such a section should contain.

Against the RFC 5706 checklist:

| Review Item                    | Assessment
|--------------------------------|----------------------------------------------------------------------------------------------------
| Deployment                     | Not addressed. Data plane selection policy is out of scope, so there is no description of how an operator enables or manages the check.
| Installation and Initial Setup | Not addressed. No configuration parameters or defaults. Criterion 1 is SHOULD and criterion 2 is MAY, with no guidance on when to enable either.
| Migration Path                 | Not addressed. No discussion of incremental deployment, or of behaviour in a network where only some speakers apply the check.
| Requirements on Other Protocols| Partially addressed. Depends on an OAM data plane liveness mechanism, but none is named and no requirements are stated on it.
| Impact on Network Operation    | Not addressed. A per-next-hop liveness check at PE mesh scale carries a cost that is not discussed.
| Verifying Correct Operation    | Not addressed. This is my principal concern - see Major Issue 3.


## Major Issues

> Section 3: the document does not say which forwarding table the resolution is performed in. The AD review of -12 asked how reachability is determined and observed that the destination address and the tunnel endpoint address may be resolvable in different tables. Section 3 still says only that the next hop "SHOULD be resolved in a forwarding database of a particular data plane protocol". Since the policy selecting the data plane is out of scope, an operator has no basis for deciding which table applies in a VRF, in a multi-instance deployment, or where the endpoint and the prefix resolve in different tables.

> Section 3, criterion 2: the inverse failure mode is not discussed. Path eligibility now depends on an OAM result. If the OAM mechanism is broken or returns a false negative while the data plane is healthy, the speaker withdraws a good path - producing the same blackhole this document exists to prevent, arrived at from the opposite direction. Nothing in the document addresses that case.

> The outcome of the check is not observable (RFC 5706 Section 3.3). An operator looking at a path that was not selected has no way to determine that this criterion was the reason. Exposing the data plane chosen, the check result per next hop, and a count of paths disqualified by this mechanism would make the feature supportable in production. Relatedly, Section 4 states that convergence is "not expected" to be negatively impacted, "barring any implementation specifics" - given a per-next-hop liveness check at PE mesh scale, I would like that claim either supported or softened.


---

## Minor Issues

> "Updates: 4271" appears in the header, but the body never states what in RFC 4271 Section 9.1.2.1 is being updated, or how. For a document that modifies the Route Resolvability Condition, this should be explicit.


---

## Nits

> Abstract: "This document defines enhances the Route Resolvability Condition" - grammar.

> Section 4 refers to the amendments "discussed in section 2"; they are in section 3.


---

Thanks for a clearly motivated document.

Regards,
Venkata Ramanaiah Chintha