mtrp:policies
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| mtrp:policies [2026/06/10 13:10] – mosh | mtrp:policies [2026/06/10 13:35] (current) – mosh | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== | + | ====== |
| - | ===== 4.1 Purpose ===== | + | ===== 6.1 Purpose ===== |
| This document defines the policy controls that influence route selection behavior. | This document defines the policy controls that influence route selection behavior. | ||
| - | ===== 4.2 Outbound Path Selection ===== | + | ===== 6.2 Outbound Path Selection ===== |
| Outbound path selection applies to direct-neighbor candidates. | Outbound path selection applies to direct-neighbor candidates. | ||
| - | ==== 4.2.1 FIRST_VALID ==== | + | ==== 6.2.1 FIRST_VALID ==== |
| The implementation MUST retain the first usable candidate encountered during evaluation. | The implementation MUST retain the first usable candidate encountered during evaluation. | ||
| - | ==== 4.2.2 LAST_IN ==== | + | ==== 6.2.2 LAST_IN ==== |
| The implementation MUST prefer the most recently seen usable candidate. | The implementation MUST prefer the most recently seen usable candidate. | ||
| - | ==== 4.2.3 BEST_METRIC ==== | + | ==== 6.2.3 BEST_METRIC ==== |
| The implementation MUST prefer the usable candidate with the lowest metric. | The implementation MUST prefer the usable candidate with the lowest metric. | ||
| Line 23: | Line 23: | ||
| If multiple candidates share the same metric, the implementation SHOULD use a deterministic tie-breaker. | If multiple candidates share the same metric, the implementation SHOULD use a deterministic tie-breaker. | ||
| - | ==== 4.2.4 MOST_RELIABLE ==== | + | ==== 6.2.4 MOST_RELIABLE ==== |
| The implementation MUST prefer the usable candidate with the highest reliability score. | The implementation MUST prefer the usable candidate with the highest reliability score. | ||
| Line 29: | Line 29: | ||
| If multiple candidates share the same reliability score, the implementation SHOULD prefer the lower metric candidate. | If multiple candidates share the same reliability score, the implementation SHOULD prefer the lower metric candidate. | ||
| - | ===== 4.3 Learned Route Selection ===== | + | ===== 6.3 Learned Route Selection ===== |
| Learned route selection applies to forwarding-table candidates. | Learned route selection applies to forwarding-table candidates. | ||
| - | ==== 4.3.1 FIRST_VALID ==== | + | ==== 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. | The implementation MUST retain the first usable forwarding candidate once selected, until that preferred candidate becomes unusable or is otherwise replaced by policy. | ||
| - | ==== 4.3.2 LAST_UPDATED ==== | + | ==== 6.3.2 LAST_UPDATED ==== |
| The implementation MUST prefer the most recently updated usable forwarding candidate. | The implementation MUST prefer the most recently updated usable forwarding candidate. | ||
| - | ==== 4.3.3 BEST_METRIC ==== | + | ==== 6.3.3 BEST_METRIC ==== |
| The implementation MUST prefer the usable forwarding candidate with the lowest metric. | The implementation MUST prefer the usable forwarding candidate with the lowest metric. | ||
| Line 47: | Line 47: | ||
| If multiple candidates share the same metric, the implementation SHOULD prefer the candidate with the newer or stronger sequence context. | If multiple candidates share the same metric, the implementation SHOULD prefer the candidate with the newer or stronger sequence context. | ||
| - | ==== 4.3.4 STICKY_BEST_METRIC ==== | + | ==== 6.3.4 STICKY_BEST_METRIC ==== |
| The implementation MUST retain the currently preferred forwarding candidate unless one of the following is true: | The implementation MUST retain the currently preferred forwarding candidate unless one of the following is true: | ||
| Line 57: | Line 57: | ||
| A candidate SHOULD be treated as meaningfully better only if it improves the preferred metric by at least the configured improvement delta. | A candidate SHOULD be treated as meaningfully better only if it improves the preferred metric by at least the configured improvement delta. | ||
| - | ===== 4.4 Hold-Down Behavior ===== | + | ===== 6.4 Hold-Down Behavior ===== |
| When a preferred forwarding candidate changes, the implementation SHOULD update: | When a preferred forwarding candidate changes, the implementation SHOULD update: | ||
| Line 68: | Line 68: | ||
| The hold-down timer SHOULD NOT be refreshed merely because the same route was re-evaluated and selected again without change. | The hold-down timer SHOULD NOT be refreshed merely because the same route was re-evaluated and selected again without change. | ||
| - | ===== 4.5 Reliability Scope ===== | + | ===== 6.5 Reliability Scope ===== |
| Current reliability behavior is hop-local. | 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. | 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. | ||
/var/www/wiki.moshnetworks.com/data/attic/mtrp/policies.1781097038.txt.gz · Last modified: by mosh