rfc9860v1.txt   rfc9860.txt 
skipping to change at line 88 skipping to change at line 88
8.2. Informative References 8.2. Informative References
Contributors Contributors
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
Multicast-only Fast Reroute (MoFRR), as defined in [RFC7431], offers Multicast-only Fast Reroute (MoFRR), as defined in [RFC7431], offers
a mechanism to reduce multicast packet loss in the event of node or a mechanism to reduce multicast packet loss in the event of node or
link failures by introducing simple enhancements to multicast routing link failures by introducing simple enhancements to multicast routing
protocols, such as Protocol Independent Multicast (PIM) [RFC7761]. protocols, such as Protocol Independent Multicast (PIM) [RFC7761].
However, the [RFC7431] MoFRR mechanism, which selects the secondary However, the MoFRR mechanism [RFC7431], which selects the secondary
multicast next hop based solely on the Loop-Free Alternate (LFA) FRR multicast next hop based solely on the Loop-Free Alternate (LFA) FRR
defined in [RFC7431], has limitations in certain multicast deployment defined in [RFC7431], has limitations in certain multicast deployment
scenarios (see Section 2). scenarios (see Section 2).
This document introduces a new mechanism for MoFRR using FRR for This document introduces a new mechanism for MoFRR using FRR for
Topology Independent Loop-Free Alternate (TI-LFA) [RFC9855]. Unlike Topology Independent Loop-Free Alternate (TI-LFA) [RFC9855]. Unlike
conventional methods, TI-LFA is independent of network topology, conventional methods, TI-LFA is independent of network topology,
enabling broader coverage across diverse network environments. This enabling broader coverage across diverse network environments. This
mechanism is applicable to PIM networks, including cases where PIM mechanism is applicable to PIM networks, including cases where PIM
operates natively over IP in Segment Routing (SR) networks. operates directly over IP in Segment Routing (SR) networks.
The TI-LFA mechanism is designed for standard link-state Interior The TI-LFA mechanism is designed for standard link-state Interior
Gateway Protocol (IGP) shortest path and SR scenarios. For each Gateway Protocol (IGP) shortest path and SR scenarios. For each
destination advertised by the IGP in a network, TI-LFA pre-installs a destination advertised by the IGP in a network, TI-LFA pre-installs a
backup forwarding entry for the protected destination, which is ready backup forwarding entry for the protected destination, which is ready
to be activated upon the detection of a link failure used to reach to be activated upon the detection of a link failure used to reach
that destination. This document leverages the backup path computed that destination. This document leverages the backup path computed
by TI-LFA through the IGP as a secondary Upstream Multicast Hop (UMH) by TI-LFA through the IGP as a secondary Upstream Multicast Hop (UMH)
for PIM. By sending PIM secondary Join messages hop by hop on the for PIM. By sending PIM secondary Join messages hop by hop on the
TI-LFA backup path, a FRR backup path can be created for PIM TI-LFA backup path, a FRR backup path can be created for PIM
skipping to change at line 158 skipping to change at line 158
Section 3 of [RFC7431] specifies that a secondary UMH in PIM for Section 3 of [RFC7431] specifies that a secondary UMH in PIM for
MoFRR is a Loop-Free Alternate (LFA). However, the conventional LFA MoFRR is a Loop-Free Alternate (LFA). However, the conventional LFA
mechanism requires that at least one neighbor's next hop to the mechanism requires that at least one neighbor's next hop to the
destination node is a loop-free next hop. Due to existing destination node is a loop-free next hop. Due to existing
limitations of the LFA mechanism in network deployments, such as limitations of the LFA mechanism in network deployments, such as
topology dependency and incomplete destination coverage, the LFA topology dependency and incomplete destination coverage, the LFA
mechanism can only be deployed in certain network topology mechanism can only be deployed in certain network topology
environments. In specific network topologies, the secondary UMH environments. In specific network topologies, the secondary UMH
cannot be computed in PIM for MoFRR, preventing PIM from establishing cannot be computed in PIM for MoFRR, preventing PIM from establishing
a standby multicast tree, and thus preventing the implementation of a standby multicast tree, and thus preventing the implementation of
MoFRR protection. Consequently, the [RFC7431] MoFRR functionality in MoFRR protection. Consequently, the MoFRR functionality [RFC7431] in
PIM is applicable only in network topologies where LFA is feasible. PIM is applicable only in network topologies where LFA is feasible.
The limitations of the [RFC7431] MoFRR applicability can be The limitations of the MoFRR applicability [RFC7431] can be
illustrated using the example network depicted in Figure 1. In this illustrated using the example network depicted in Figure 1. In this
example, the metric of the R1-R4 link is 20, the metric of the R5-R6 example, the metric of the R1-R4 link is 20, the metric of the R5-R6
link is 100, and the metrics of the other links are 10. All link link is 100, and the metrics of the other links are 10. All link
metrics are bidirectional. metrics are bidirectional.
For multicast source S1 and receiver R, the primary path of the PIM For multicast source S1 and receiver R, the primary path of the PIM
Join packet is R3->R2->R1, and the secondary path is R3->R4->R1, Join packet is R3->R2->R1, and the secondary path is R3->R4->R1,
which corresponds to the LFA path of unicast routing. In this which corresponds to the LFA path of unicast routing. In this
scenario, the [RFC7431] MoFRR operates effectively. scenario, MoFRR [RFC7431] operates effectively.
For multicast source S2 and receiver R, the primary path of the PIM For multicast source S2 and receiver R, the primary path of the PIM
Join packet is R3->R2. However, an LFA does not exist. If R3 sends Join packet is R3->R2. However, an LFA does not exist. If R3 sends
the packet to R4, R4 will forward it back to R3 because the IGP the packet to R4, R4 will forward it back to R3 because the IGP
shortest path from R4 to R1 is R4->R3->R2. In this case, the shortest path from R4 to R1 is R4->R3->R2. In this case, MoFRR
[RFC7431] MoFRR cannot calculate a secondary UMH. Similarly, for [RFC7431] cannot calculate a secondary UMH. Similarly, for multicast
multicast source S3 and receiver R, the [RFC7431] MoFRR mechanism is source S3 and receiver R, the MoFRR mechanism [RFC7431] is
ineffective. ineffective.
10 20 10 20
[S1]----(R1)-------------(R4) [S1]----(R1)-------------(R4)
| | | |
| | | |
|10 |10 |10 |10
10 | | 10 | |
[S2]----(R2)-------------(R3)----[R] [S2]----(R2)-------------(R3)----[R]
| 10 | 10 | 10 | 10
skipping to change at line 199 skipping to change at line 199
|10 |10 |10 |10
10 | | 10 | |
[S3]----(R5)-----(R6)----(R7) [S3]----(R5)-----(R6)----(R7)
100 10 100 10
Figure 1: Example Network Topology Figure 1: Example Network Topology
2.2. TI-LFA for MoFRR 2.2. TI-LFA for MoFRR
The alternate path provided by the TI-LFA mechanism is represented as The alternate path provided by the TI-LFA mechanism is represented as
a Segment List, which includes the NodeSID of the P-space node and a segment list, which includes the Node SID of the P-space node and
the Adjacency SIDs of the links between the P-space and Q-space the Adjacency SIDs of the links between the P-space and Q-space
nodes. When a remote PQ node exists in both P-space and Q-space, the nodes. When a remote PQ node exists in both P-space and Q-space, the
Segment List requires only the PQ node's NodeSID. segment list requires only the PQ node's Node SID.
PIM can look up the corresponding node's IP address in the unicast PIM can look up the corresponding node's IP address in the unicast
route base according to the NodeSID and the IP addresses of the route base according to the Node SID and the IP addresses of the
endpoints of the corresponding link in the unicast route base endpoints of the corresponding link in the unicast route base
according to the Adjacency SIDs. However, multicast protocol packets according to the Adjacency SIDs. However, multicast protocol packets
cannot be directly forwarded along the path of the Segment List. cannot be directly forwarded along the path of the segment list.
To establish a standby multicast tree, PIM Join messages need to be To establish a standby multicast tree, PIM Join messages need to be
transmitted hop by hop. However, not all nodes and links on the transmitted hop by hop. However, not all nodes and links on the
unicast alternate path are included in the Segment List. If PIM unicast alternate path are included in the segment list. If PIM
protocol packets are transmitted solely in unicast mode, they protocol packets are transmitted solely in unicast mode, they
effectively traverse the unicast tunnel like unicast traffic and do effectively traverse the unicast tunnel like unicast traffic and do
not pass through the intermediate nodes of the tunnel. Consequently, not pass through the intermediate nodes of the tunnel. Consequently,
the intermediate nodes on the alternate path cannot forward multicast the intermediate nodes on the alternate path cannot forward multicast
traffic because they lack PIM state entries. PIM must create entries traffic because they lack PIM state entries. PIM must create entries
on each device hop by hop, generating an incoming interface and an on each device hop by hop, generating an incoming interface and an
outgoing interface list, to form a complete end-to-end multicast tree outgoing interface list, to form a complete end-to-end multicast tree
for forwarding multicast traffic. Therefore, simply sending PIM Join for forwarding multicast traffic. Therefore, simply sending PIM Join
packets using the Segment List, as done with unicast traffic, is packets using the segment list, as done with unicast traffic, is
insufficient to establish a standby multicast tree. insufficient to establish a standby multicast tree.
3. A Solution 3. A Solution
3.1. Overview 3.1. Overview
A secondary UMH serves as a candidate next hop that can be used to A secondary UMH serves as a candidate next hop that can be used to
reach the root of a multicast tree. In this document, the secondary reach the root of a multicast tree. In this document, the secondary
UMH is derived from unicast routing, utilizing the Segment List UMH is derived from unicast routing, utilizing the segment list
computed by TI-LFA. computed by TI-LFA.
The path information from the Segment List is incorporated into the The path information from the segment list is incorporated into the
PIM packets to guide hop-by-hop RPF selection. The IP address PIM packets to guide hop-by-hop RPF selection. The IP address
corresponding to the Node SID can be used as the segmented root node, corresponding to the Node SID can be used as the segmented root node,
while the IP addresses of the interfaces at both endpoints of the while the IP addresses of the interfaces at both endpoints of the
link associated with the Adjacency SID can be used as the local link associated with the Adjacency SID can be used as the local
upstream interface and upstream neighbor. upstream interface and upstream neighbor.
[RFC5496] defines the PIM RPF Vector Attribute, which can carry the [RFC5496] defines the PIM RPF Vector Attribute, which can carry the
node's IP address corresponding to the Node SID. Additionally, node's IP address corresponding to the Node SID. Additionally,
[RFC7891] defines the Explicit RPF Vector, which can carry the peer's [RFC7891] defines the Explicit RPF Vector, which can carry the peer's
IP address corresponding to the Adjacency SID. IP address corresponding to the Adjacency SID.
For instance, in the network illustrated in Figure 1, the secondary For instance, in the network illustrated in Figure 1, the secondary
path for the PIM Join packet towards multicast source S2 cannot be path for the PIM Join packet towards multicast source S2 cannot be
computed by [RFC7431] MoFRR, as previously described. Using TI-LFA, computed by MoFRR [RFC7431], as previously described. Using TI-LFA,
R3 sends the packet to R4 while including an RPF Vector that contains R3 sends the packet to R4 while including an RPF Vector that contains
the IP address of R1, which serves as R3's PQ node for the protected the IP address of R1, which serves as R3's PQ node for the protected
R3-R2 link. R4 then forwards the packet to R1 via the R1-R4 link R3-R2 link. R4 then forwards the packet to R1 via the R1-R4 link
according to the unicast route associated with the RPF Vector. R1 according to the unicast route associated with the RPF Vector. R1
subsequently forwards the packet to R2, thus establishing the subsequently forwards the packet to R2, thus establishing the
secondary path R3->R4->R1->R2. secondary path R3->R4->R1->R2.
Additionally, for multicast source S3 and receiver R, the primary Additionally, for multicast source S3 and receiver R, the primary
path of the PIM Join packet is R3->R2->R5. Using TI-LFA, R3 sends path of the PIM Join packet is R3->R2->R5. Using TI-LFA, R3 sends
the PIM Join packet to R7 while including two RPF Vectors: the PIM Join packet to R7 while including two RPF Vectors:
skipping to change at line 271 skipping to change at line 271
* The second RPF Vector contains the interface IP addresses of R6 * The second RPF Vector contains the interface IP addresses of R6
and R5, which serve as R3's Q-node for the protected R3-R2 link. and R5, which serve as R3's Q-node for the protected R3-R2 link.
The first RPF Vector guides the PIM Join path through R3->R7->R6, The first RPF Vector guides the PIM Join path through R3->R7->R6,
while the second RPF Vector guides the PIM Join path through R6->R5, while the second RPF Vector guides the PIM Join path through R6->R5,
thereby establishing the secondary path R3->R7->R6->R5. thereby establishing the secondary path R3->R7->R6->R5.
This document leverages the above RPF Vector standards, obviating the This document leverages the above RPF Vector standards, obviating the
need for PIM protocol extensions. This approach allows the need for PIM protocol extensions. This approach allows the
establishment of a standby multicast tree based on the Segment List establishment of a standby multicast tree based on the segment list
calculated by TI-LFA, thereby providing comprehensive MoFRR calculated by TI-LFA, thereby providing comprehensive MoFRR
protection for multicast services across diverse network protection for multicast services across diverse network
environments. environments.
3.2. Procedure 3.2. Procedure
Consider a Segment List calculated by TI-LFA as (NodeSID(A), Consider a segment list calculated by TI-LFA as (NodeSID(A),
AdjSID(A-B)). Node A belongs to the P-space, and node B belongs to AdjSID(A-B)). Node A belongs to the P-space, and node B belongs to
the Q-space. The IP address corresponding to NodeSID(A) can be the Q-space. The IP address corresponding to NodeSID(A) can be
retrieved from the local LSDB of the IGP and assumed to be IP-a. retrieved from the local LSDB of the IGP and assumed to be IP-a.
Similarly, the IP addresses of the two endpoints of the link Similarly, the IP addresses of the two endpoints of the link
corresponding to AdjSID(A-B) can also be retrieved from the local corresponding to AdjSID(A-B) can also be retrieved from the local
LSDB and assumed to be IP-La and IP-Lb. LSDB and assumed to be IP-La and IP-Lb.
Within the PIM process, IP-a is treated as the standard RPF Vector Within the PIM process, IP-a is treated as the standard RPF Vector
Attribute and added to the PIM Join packet. IP-La is considered the Attribute and added to the PIM Join packet. IP-La is considered the
local address of the incoming interface, and IP-Lb is regarded as the local address of the incoming interface, and IP-Lb is regarded as the
skipping to change at line 355 skipping to change at line 355
IPv6 data plane (SRv6 [RFC8986]): IPv6 data plane (SRv6 [RFC8986]):
Node IP Address Node SID (End) Node IP Address Node SID (End)
R4 IP6-R4 SID-R4 R4 IP6-R4 SID-R4
Link IP Address Adjacency SID (End.X) Link IP Address Adjacency SID (End.X)
R3->R4 IP6-R3-R4 SID-R3-R4 R3->R4 IP6-R3-R4 SID-R3-R4
R4->R3 IP6-R4-R3 SID-R4-R3 R4->R3 IP6-R4-R3 SID-R4-R3
The primary path of the PIM Join packet is R6->R2->R1, and the The primary path of the PIM Join packet is R6->R2->R1, and the
secondary path is R6->R5->R4->R3->R2->R1. However, the traditional secondary path is R6->R5->R4->R3->R2->R1. However, the conventional
LFA does not function properly for the secondary path because the LFA does not function properly for the secondary path because the
shortest path to R2 from R5 (or from R4) still traverses the R6-R2 shortest path to R2 from R5 (or from R4) still traverses the R6-R2
link. In this scenario, R6 must calculate the secondary UMH using link. In this scenario, R6 must calculate the secondary UMH using
the proposed MoFRR method based on TI-LFA. the proposed MoFRR method based on TI-LFA.
According to the TI-LFA algorithm, the P-space and Q-space are According to the TI-LFA algorithm, the P-space and Q-space are
illustrated in Figure 3. The TI-LFA repair path consists of the Node illustrated in Figure 3. The TI-LFA repair path consists of the Node
SID of R4 and the Adjacency SID of R4->R3. On the Segment Routing SID of R4 and the Adjacency SID of R4->R3. On the Segment Routing
over MPLS (SR-MPLS) data plane, the repair segment list is (Label-R4, over MPLS (SR-MPLS) data plane, the repair segment list is (Label-R4,
Label-R4-R3). On the Segment Routing over IPv6 (SRv6) data plane, Label-R4-R3). On the Segment Routing over IPv6 (SRv6) data plane,
skipping to change at line 469 skipping to change at line 469
5. Management and Operational Considerations 5. Management and Operational Considerations
The management of the proposed approach is consistent with [RFC7916]. The management of the proposed approach is consistent with [RFC7916].
However, in the operation of this approach, the node on the backup However, in the operation of this approach, the node on the backup
Join paths must have an independent configuration strategy for Join paths must have an independent configuration strategy for
installing RPF Vector Attributes in the PIM Join packet and installing RPF Vector Attributes in the PIM Join packet and
controlling the sending of this PIM Join message. controlling the sending of this PIM Join message.
All nodes on the backup Join paths must be able to parse the PIM Join All nodes on the backup Join paths must be able to parse the PIM Join
message with the RPF Vector Attribute. If the nodes do not message with the RPF Vector Attribute. If the nodes do not
understand the RPF Vector Attribute in the PIM Join packet, then it understand the RPF Vector Attribute in the PIM Join packet, then they
must discard the RPF Vector Attribute because failing to remove the must discard the RPF Vector Attribute because failing to remove the
RPF Vectors could cause upstream nodes to send the Join back towards RPF Vectors could cause upstream nodes to send the Join packet back
these nodes causing loops. towards these nodes causing loops.
If an administrator is manually specifying the path that the Join If an administrator is manually specifying the path that the Join
messages need to be sent on, it is recommended that the administrator messages need to be sent on, it is recommended that the administrator
computes the path to include nodes that support the Explicit RPF computes the path to include nodes that support the Explicit RPF
Vector and check that the state is created correctly on each node Vector and check that the state is created correctly on each node
along the path. Tools like Mtrace [RFC8487] can be used for along the path. Tools like Mtrace [RFC8487] can be used for
debugging and to ensure that the Join state is set up correctly. debugging and to ensure that the Join state is set up correctly.
6. IANA Considerations 6. IANA Considerations
skipping to change at line 575 skipping to change at line 575
underlying routing infrastructure. As the solution described in the underlying routing infrastructure. As the solution described in the
document is based on SR technology, readers should be aware of the document is based on SR technology, readers should be aware of the
security considerations related to this technology (see [RFC8402]) security considerations related to this technology (see [RFC8402])
and its data plane instantiations (see [RFC8660], [RFC8754], and and its data plane instantiations (see [RFC8660], [RFC8754], and
[RFC8986]). [RFC8986]).
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC9855] Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute Using Segment Routing", RFC 9855,
DOI 10.17487/RFC9855, September 2025,
<https://www.rfc-editor.org/info/rfc9855>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>. <https://www.rfc-editor.org/info/rfc5286>.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format", Independent Multicast (PIM) Join Attribute Format",
RFC 5384, DOI 10.17487/RFC5384, November 2008, RFC 5384, DOI 10.17487/RFC5384, November 2008,
<https://www.rfc-editor.org/info/rfc5384>. <https://www.rfc-editor.org/info/rfc5384>.
skipping to change at line 644 skipping to change at line 638
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC9855] Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute Using Segment Routing", RFC 9855,
DOI 10.17487/RFC9855, September 2025,
<https://www.rfc-editor.org/info/rfc9855>.
8.2. Informative References 8.2. Informative References
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, DOI 10.17487/RFC5715, January Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <https://www.rfc-editor.org/info/rfc5715>. 2010, <https://www.rfc-editor.org/info/rfc5715>.
[RFC8102] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and [RFC8102] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and
S. Litkowski, "Remote-LFA Node Protection and S. Litkowski, "Remote-LFA Node Protection and
Manageability", RFC 8102, DOI 10.17487/RFC8102, March Manageability", RFC 8102, DOI 10.17487/RFC8102, March
2017, <https://www.rfc-editor.org/info/rfc8102>. 2017, <https://www.rfc-editor.org/info/rfc8102>.
 End of changes. 22 change blocks. 
29 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.48.