Differences

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

--- mtrp:policies [2026/06/10 12:47] – created 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 =====
-Outbound path selection controls how MTRP chooses among direct-neighbor candidates.
+This document defines the policy controls that influence route selection behavior.
-Supported options:
+===== 6.2 Outbound Path Selection =====
-  * ''FIRST_VALID'': keep the first usable candidate found
+Outbound path selection applies to direct-neighbor candidates.
-  * ''LAST_IN'': prefer the most recently seen candidate
-  * ''BEST_METRIC'': prefer the candidate with the lowest metric
-  * ''MOST_RELIABLE'': prefer the candidate with the best reliability score
-===== Learned Route Selection =====
+==== 6.2.1 FIRST_VALID ====
-Learned route selection controls how MTRP chooses among forwarding candidates.
+The implementation MUST retain the first usable candidate encountered during evaluation.
-Supported options:
+==== 6.2.2 LAST_IN ====
-  * ''FIRST_VALID'': keep the first usable learned candidate
+The implementation MUST prefer the most recently seen usable candidate.
-  * ''LAST_UPDATED'': prefer the most recently updated candidate
-  * ''BEST_METRIC'': prefer the candidate with the lowest metric
-  * ''STICKY_BEST_METRIC'': keep the current preferred route until a meaningfully better route appears
-===== Sticky Behavior =====
+==== 6.2.3 BEST_METRIC ====
-''STICKY_BEST_METRIC'' uses:
+The implementation MUST prefer the usable candidate with the lowest metric.
-  * improvement delta
+If multiple candidates share the same metric, the implementation SHOULD use a deterministic tie-breaker.
-  * hold-down timer
-  * preferred-route state
-This reduces unnecessary route flapping.
+==== 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.