Summary

  • RFC 9917 is an IETF Standards Track Proposed Standard published in January 2026. It updates RFC 9350 and RFC 9843.
  • Its central mechanism is directional: a receiver can report a condition on the far end of a link, and reverse-direction Administrative Group information can cause path computation to exclude the corresponding forward edge.
  • The feature is not an automatic fault detector, a guarantee of bidirectional forwarding, or proof that a physical link has become symmetric. The telemetry source, threshold, encoding, policy order and implementation support remain operational questions.

The mechanism in practice

The useful distinction is between the directed edge used to send traffic and the directed edge representing what the far end observes. RFC 9917 describes a case in which a receiver detects input errors, with CRC errors as the RFC's example. An operator may define a threshold; once the measured condition crosses it, the receiver can set an Extended Administrative Group on the reverse-direction edge. A Flex-Algorithm then evaluates that reverse affinity while computing paths through the forward topology.

The threshold is not supplied by the RFC as a universal operating value. Operators must decide how telemetry is owned, how a set event is encoded, and how a clear event is recognized. Distinct set and clear thresholds can prevent a borderline counter from repeatedly changing policy. IGP flooding throttles and ordinary convergence controls can also limit the cost of repeated updates and path recalculation. Those controls reduce churn; they do not establish a safe threshold for every network.

RFC 9917 defines three reverse Admin Group constraint families for both IS-IS and OSPF: exclude, include-any and include-all. Exclude rejects a candidate whose reverse edge carries a prohibited group. Include-any requires at least one requested group, while include-all requires every requested group. The exact sub-TLV and receiver processing matter. Malformed reverse-affinity sub-TLV lengths are ignored, and duplicate occurrences invoke the receiver behavior specified for the relevant IS-IS or OSPF encoding; the specification should not be expanded into an invented “last one wins” or “merge them” rule.

Ordered pruning is part of the contract

The new constraints are path-computation rules 8, 9 and 10. They extend the ordered pruning registry established by the Flex-Algorithm work in RFC 9350 and RFC 9843. The order is not a cosmetic list: existing relative order must remain unchanged, and registry rules cannot be deleted, merged or repeated. A deployment therefore has to compare the winning FAD and the complete ordered rule set, not merely check whether a router recognizes a reverse-affinity field.

Mixed support is a practical risk. RFC 9917 does not mandate that every router support every Flex-Algorithm constraint, and the source packet provides no basis for claiming vendor deployment. A syntactically accepted FAD can still produce inconsistent pruning if devices differ in support, duplicate handling or encoding validation. Acceptance should show the forward and reverse attributes, the winning FAD, the resulting pruned topology and the behavior during both setting and clearing.

Analysis — Theo March

The strategic change is that a one-way receive defect can become a routing-policy input without pretending that the underlying link is physically symmetric. That is powerful precisely because it is conditional. The operator owns the chain from telemetry to threshold, reverse Administrative Group, ordered pruning and convergence. Breaking observability at any point turns a useful signal into an unexplained topology change.

The decision is therefore narrower than “enable RFC 9917.” Enable a particular constraint only when telemetry ownership is explicit, set and clear thresholds are tested, RFC 7308 encoding is validated, the winning FAD and rule order are consistent, support coverage is known, convergence is measured, and rollback is rehearsed. If those conditions are missing, leave the feature disabled or isolate it to a controlled Flex-Algorithm until evidence is complete.

This thesis is distinct from RFC 9916 PCEPS replay, RFC 9915 DHCPv6 lease lifecycle, RFC 9914 RPL route projection and RFC 9912 RAW recovery. Those subjects address different protocol boundaries; this briefing addresses reverse-direction link evidence as an ordered IGP Flex-Algorithm pruning input.

Operator acceptance decision path

  1. Identify the receiver telemetry owner and document the input-error signal; treat CRC errors only as the RFC's example, not as a universal detector.
  2. Choose and test separate set and clear thresholds, then measure flooding and repeated path recalculation under noisy input.
  3. Validate the Extended Administrative Group encoding against RFC 7308, including malformed lengths and duplicate-occurrence behavior.
  4. Confirm the winning FAD, rules 8–10 and all preceding rules, preserving registry order without deletion, merging or repetition.
  5. Check IS-IS and OSPF support across every participating node; do not assume universal constraint support or vendor deployment.
  6. Observe forward and reverse attributes, FAD selection, pruned paths, convergence and rollback in a staged trial. Accept only if the evidence is explainable end to end.

Claim-to-RFC evidence ledger

Claim Evidence
Reverse-direction Administrative Groups can prune a forward edge RFC 9917, abstract and Sections 1, 3
Far-end input errors and the threshold-driven reverse signal RFC 9917, Section 3
Exclude, include-any and include-all for IS-IS and OSPF RFC 9917, Sections 5–10
Malformed lengths and duplicate occurrences RFC 9917, Sections 5–10
Existing Flex-Algorithm model and winning FAD RFC 9350
Earlier pruning rules and extensions RFC 9843
Extended Administrative Group encoding RFC 7308
Rules 8, 9 and 10; immutable registry order RFC 9917, Sections 11 and 12.3–12.3.1

Sources