Skip to content

RFC 9860 - MoFRR Based on TI-LFA

Field Value
Title Multicast-Only Fast Reroute (MoFRR) Based on Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute
Authors Y. Liu, M. McBride, Z. Zhang, J. Xie, C. Lin
Date October 2025
Status Informational
Link datatracker.ietf.org/doc/rfc9860

Summary

MoFRR (RFC 7431) protects PIM multicast by joining the same (S,G) on two upstream paths and switching to the standby stream on failure. Its weakness is how it picks the secondary upstream hop: it relies on classic LFA, so in many topologies no loop-free secondary exists and MoFRR simply cannot protect the flow.

RFC 9860 borrows the repair path that TI-LFA already computes for unicast — which has full topology coverage — and uses it to build the standby multicast tree. The catch is that PIM joins must be processed hop by hop to create state on every router, so they cannot just be tunneled along the repair segment list. Instead, the receiver-side router translates the repair segments into existing PIM RPF Vector attributes:

  • a Node SID / End SID (the P-node or PQ-node) becomes an RPF Vector (RFC 5496) carrying that node's address;
  • an Adjacency SID / End.X SID (P-node → Q-node link) becomes an Explicit RPF Vector (RFC 7891) carrying the far-end interface address.

The secondary join follows these vectors hop by hop, creating PIM state along the TI-LFA path. It works for both SR-MPLS and SRv6 IGP SIDs, and needs no new protocol extensions — only that every router on the backup join path supports RPF Vectors.

Key Sections

Section Topic Description
2.1 LFA for MoFRR Why LFA-based secondary UMH fails in common topologies
2.2 TI-LFA for MoFRR Why a segment list cannot be used directly for PIM joins
3 Solution Mapping Node/Adjacency SIDs to RPF Vector and Explicit RPF Vector
4 Illustration Worked SR-MPLS and SRv6 example
5 Operations RPF Vector support requirements and debugging with mtrace

SID-to-PIM Mapping

TI-LFA repair element PIM Join attribute Effect
Node SID / SRv6 End SID of P (or PQ) node RPF Vector (Type 0) with node address Join is routed toward the P-node instead of the source
Adj-SID / SRv6 End.X SID from P to Q Explicit RPF Vector (Type 4) with remote interface address P-node sends the join across that specific link
(after last vector) No vector Normal RPF toward the source from the Q-node

When a single PQ-node exists, only one RPF Vector is needed.

Common Pitfalls

  • Every router on the backup join path must understand RPF Vectors. A router that does not must strip them — leaving them in can loop the join back.
  • Scope is a single IGP area; exit routers and inter-domain links are not protected.
  • Micro-loops during reconvergence are not addressed for PIM.
  • This protects PIM trees. It does not apply to SRv6-native replication (RFC 9524 / RFC 9960) or BIER.
  • It is Informational and optional: deployments must explicitly configure when secondary joins with vectors are sent.
Document Relationship Description
draft-ietf-pim-mofrr-tilfa Draft lineage Draft that became RFC 9860
RFC 7431 Base mechanism Multicast-Only Fast Reroute

References

  1. RFC 9860 - MoFRR Based on TI-LFA Fast Reroute
  2. RFC 7431 - Multicast-Only Fast Reroute
  3. RFC 5496 - The RPF Vector TLV
  4. RFC 7891 - Explicit Reverse Path Forwarding (RPF) Vector