This document defines the policy controls that influence route selection behavior.
Outbound path selection applies to direct-neighbor candidates.
The implementation MUST retain the first usable candidate encountered during evaluation.
The implementation MUST prefer the most recently seen usable candidate.
The implementation MUST prefer the usable candidate with the lowest metric.
If multiple candidates share the same metric, the implementation SHOULD use a deterministic tie-breaker.
The implementation MUST prefer the usable candidate with the highest reliability score.
If multiple candidates share the same reliability score, the implementation SHOULD prefer the lower metric candidate.
Learned route selection applies to forwarding-table candidates.
The implementation MUST retain the first usable forwarding candidate once selected, until that preferred candidate becomes unusable or is otherwise replaced by policy.
The implementation MUST prefer the most recently updated usable forwarding candidate.
The implementation MUST prefer the usable forwarding candidate with the lowest metric.
If multiple candidates share the same metric, the implementation SHOULD prefer the candidate with the newer or stronger sequence context.
The implementation MUST retain the currently preferred forwarding candidate unless one of the following is true:
A candidate SHOULD be treated as meaningfully better only if it improves the preferred metric by at least the configured improvement delta.
When a preferred forwarding candidate changes, the implementation SHOULD update:
The hold-down timer SHOULD NOT be refreshed merely because the same route was re-evaluated and selected again without change.
Current reliability behavior is hop-local.
A reliability score currently reflects observed local send success and failure toward a next hop. It does not, by itself, imply end-to-end application delivery.