This document defines how MTRP learns, stores, and selects routes.

A destination that is reachable directly on a registered local path MUST be treated as a neighbor candidate.

Direct-neighbor state MUST be stored in the neighbor table.

A route advertisement received from another node MAY create or update a learned forwarding candidate.

Learned candidates MUST be stored in the forwarding table.

Multiple forwarding candidates for the same destination MAY exist simultaneously.

For unicast traffic, MTRP MUST resolve egress in the following order:

1. explicit valid egress path, if already present
2. direct-neighbor resolution
3. forwarding-table resolution
4. unroutable result if no valid candidate exists

Metrics are additive across relayed advertisements.

A directly reachable destination SHOULD have a lower metric than the same destination learned through one or more relays, assuming all constituent path metrics are positive.

Preferred-route entries are populated at send-time route selection.

Preferred-route entries are not required to be created when a learned route is first stored.

As a result, the preferred route table MAY remain empty even when the forwarding table contains valid learned routes.

If all participating nodes are direct neighbors of one another, MTRP MAY still learn indirect candidates through re-advertisement. In such a topology, direct routes SHOULD normally be preferred over indirect candidates with worse metrics.