====== 6. Routing Policies ======

===== 6.1 Purpose =====

This document defines the policy controls that influence route selection behavior.

===== 6.2 Outbound Path Selection =====

Outbound path selection applies to direct-neighbor candidates.

==== 6.2.1 FIRST_VALID ====

The implementation MUST retain the first usable candidate encountered during evaluation.

==== 6.2.2 LAST_IN ====

The implementation MUST prefer the most recently seen usable candidate.

==== 6.2.3 BEST_METRIC ====

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.

==== 6.2.4 MOST_RELIABLE ====

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.

===== 6.3 Learned Route Selection =====

Learned route selection applies to forwarding-table candidates.

==== 6.3.1 FIRST_VALID ====

The implementation MUST retain the first usable forwarding candidate once selected, until that preferred candidate becomes unusable or is otherwise replaced by policy.

==== 6.3.2 LAST_UPDATED ====

The implementation MUST prefer the most recently updated usable forwarding candidate.

==== 6.3.3 BEST_METRIC ====

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.

==== 6.3.4 STICKY_BEST_METRIC ====

The implementation MUST retain the currently preferred forwarding candidate unless one of the following is true:

  * the preferred candidate is no longer usable
  * the hold-down period has expired and a meaningfully better candidate exists
  * no preferred candidate exists

A candidate SHOULD be treated as meaningfully better only if it improves the preferred metric by at least the configured improvement delta.

===== 6.4 Hold-Down Behavior =====

When a preferred forwarding candidate changes, the implementation SHOULD update:

  * selected time
  * hold-down expiration time
  * preferred next hop
  * preferred egress path

The hold-down timer SHOULD NOT be refreshed merely because the same route was re-evaluated and selected again without change.

===== 6.5 Reliability Scope =====

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.