Differences

This shows you the differences between two versions of the page.

--- mtrp:policies [2026/06/10 12:52] – mosh
+++ mtrp:policies [2026/06/10 13:35] (current) – mosh
@@ Line 1: / Line 1: @@
-====== Routing Policies ======
+====== 6. Routing Policies ======
-===== Outbound Path Selection =====
+===== 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.
-Supported modes:
+==== 6.2.1 FIRST_VALID ====
-  * ''FIRST_VALID'': keep the first usable candidate found
+The implementation MUST retain the first usable candidate encountered during evaluation.
-  * ''LAST_IN'': prefer the most recently seen candidate
-  * ''BEST_METRIC'': prefer the lowest metric candidate
-  * ''MOST_RELIABLE'': prefer the candidate with the best reliability score
-===== Learned Route Selection =====
+==== 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.
-Supported modes:
+==== 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
-  * ''FIRST_VALID'': keep the first usable forwarding candidate
+A candidate SHOULD be treated as meaningfully better only if it improves the preferred metric by at least the configured improvement delta.
-  * ''LAST_UPDATED'': prefer the most recently updated candidate
-  * ''BEST_METRIC'': prefer the lowest metric candidate
-  * ''STICKY_BEST_METRIC'': keep the current preferred route until a meaningfully better candidate appears
-===== Sticky Route Behavior =====
+===== 6.4 Hold-Down Behavior =====
-''STICKY_BEST_METRIC'' uses:
+When a preferred forwarding candidate changes, the implementation SHOULD update:
-  * preferred-route state
+  * selected time
-  * improvement delta
+  * hold-down expiration time
-  * hold-down timing
+  * preferred next hop
+  * preferred egress path
-This reduces route flapping when several similar candidates exist.
+The hold-down timer SHOULD NOT be refreshed merely because the same route was re-evaluated and selected again without change.
-===== Reliability Note =====
+===== 6.5 Reliability Scope =====
-Current reliability scoring is hop-local.
+Current reliability behavior is hop-local.
-It reflects local send success and failure behavior toward a next hop, not full end-to-end delivery confirmation.
+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.