rfc9860.original   rfc9860.txt 
PIM Working Group Y. Liu Internet Engineering Task Force (IETF) Y. Liu
Internet-Draft China Mobile Request for Comments: 9860 China Mobile
Intended status: Informational M. McBride Category: Informational M. McBride
Expires: 9 October 2025 Futurewei ISSN: 2070-1721 Futurewei
Z. Zhang Z. Zhang
ZTE ZTE
J. Xie J. Xie
Huawei Huawei
C. Lin C. Lin
New H3C Technologies New H3C Technologies
7 April 2025 September 2025
Multicast-only Fast Reroute Based on Topology Independent Loop-free Multicast-Only Fast Reroute (MoFRR) Based on Topology Independent Loop-
Alternate (TI-LFA) Fast Reroute Free Alternate (TI-LFA) Fast Reroute
draft-ietf-pim-mofrr-tilfa-14
Abstract Abstract
This document specifies the use of Topology Independent Loop-Free This document specifies the use of Topology Independent Loop-Free
Alternate (TI-LFA) mechanisms with Multicast Only Fast ReRoute Alternate (TI-LFA) mechanisms with Multicast-only Fast Reroute
(MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA (MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA
provides fast reroute protection for unicast traffic in IP networks provides Fast Reroute (FRR) protection for unicast traffic in IP
by precomputing backup paths that avoid potential failures. By networks by precomputing backup paths that avoid potential failures.
integrating TI-LFA with MoFRR, this document extends the benefits of By integrating TI-LFA with MoFRR, this document extends the benefits
fast reroute mechanisms to multicast traffic, enabling enhanced of FRR mechanisms to multicast traffic, enabling enhanced resilience
resilience and minimized packet loss in multicast networks. The and minimized packet loss in multicast networks. The document
document outlines an optional approach to implement TI-LFA in outlines an optional approach to implement TI-LFA in conjunction with
conjunction with MoFRR for PIM, ensuring that multicast traffic is MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in
rapidly rerouted in the event of a failure. the event of a failure.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 9 October 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9860.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement
2.1. LFA for MoFRR . . . . . . . . . . . . . . . . . . . . . . 4 2.1. LFA for MoFRR
2.2. TI-LFA for MoFRR . . . . . . . . . . . . . . . . . . . . 5 2.2. TI-LFA for MoFRR
3. A Solution . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. A Solution
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Overview
3.2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Procedure
4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Illustration
5. Management and Operational Considerations . . . . . . . . . . 11 5. Management and Operational Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 [RFC7431] MoFRR mechanism, which selects the secondary
multicast next-hop based solely on the loop-free alternate fast multicast next hop based solely on the Loop-Free Alternate (LFA) FRR
reroute defined in [RFC7431], has limitations in certain multicast defined in [RFC7431], has limitations in certain multicast deployment
deployment scenarios (see Section 2). scenarios (see Section 2).
This document introduces a new mechanism for MoFRR using Topology This document introduces a new mechanism for MoFRR using FRR for
Independent Loop-Free Alternate (TI-LFA) Topology Independent Loop-Free Alternate (TI-LFA) [RFC9855]. Unlike
[I-D.ietf-rtgwg-segment-routing-ti-lfa] fast reroute. 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 natively 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, ready to be backup forwarding entry for the protected destination, which is ready
activated upon the detection of a link failure used to reach that to be activated upon the detection of a link failure used to reach
destination. This document leverages the backup path computed by TI- that destination. This document leverages the backup path computed
LFA through the IGP as a secondary Upstream Multicast Hop (UMH) for by TI-LFA through the IGP as a secondary Upstream Multicast Hop (UMH)
PIM. By sending PIM secondary Join messages hop by hop on the TI-LFA for PIM. By sending PIM secondary Join messages hop by hop on the
backup path, a fast reroute backup path can be created for PIM TI-LFA backup path, a FRR backup path can be created for PIM
multicast. multicast.
The techniques described in this document are limited to protecting The techniques described in this document are limited to protecting
links and nodes within a link-state IGP area. Protecting domain exit links and nodes within a link-state IGP area. Protecting domain exit
routers and/or links attached to other routing domains is beyond the routers and/or links attached to other routing domains is beyond the
scope of this document. All the Segment Identifiers (SIDs) required scope of this document. All the Segment Identifiers (SIDs) required
are contained within the Link State Database (LSDB) of the IGP. are contained within the Link State Database (LSDB) of the IGP.
The approach does not alter the existing management and operation of The approach does not alter the existing management and operation of
LFA, RLFA, and TI-LFA [RFC7916] [RFC8102] LFA, TI-LFA, and Remote LFA (RLFA) [RFC7916] [RFC8102] [RFC9855].
[I-D.ietf-rtgwg-segment-routing-ti-lfa]. Additionally, during post- Additionally, during post-failure reconvergence, micro-loops
failure reconvergence, micro-loops [RFC5715] may form due to [RFC5715] may form due to transient forwarding inconsistencies across
transient forwarding inconsistencies across routers. PIM micro-loop routers. PIM micro-loop prevention is out of scope for this
prevention is out of scope for this document. document.
Note that this document introduces an optional approach for backup Note that this document introduces an optional approach for backup
Join paths, designed to enhance the protection scope of existing Join paths, designed to enhance the protection scope of existing
multicast systems. It is fully compatible with current protocol multicast systems. It is fully compatible with current protocol
implementations and does not necessitate any changes to the protocols implementations and does not necessitate any changes to the protocols
or forwarding functions on intermediate nodes. All nodes along the or forwarding functions on intermediate nodes. All nodes along the
backup Join paths must support the RPF Vector attribute as defined in backup Join paths must support the Reverse Path Forwarding (RPF)
[RFC5496] and [RFC7891]. If there is a choice between vector and Vector Attribute as defined in [RFC5496] and [RFC7891]. If there is
non-vector Join messages on the intermediate nodes, the non-vector a choice between vector and non-vector Join messages on the
option should be prioritized, which implies that protection paths intermediate nodes, the non-vector option should be prioritized,
will remain inactive. This document does not modify the handling of which implies that protection paths will remain inactive. This
conflicts in PIM Join messages. For guidance on conflicts in Join document does not modify the handling of conflicts in PIM Join
attributes, please refer to Section 3.3.3 of [RFC5384]. messages. For guidance on conflicts in Join attributes, please refer
to Section 3.3.3 of [RFC5384].
1.1. Terminology 1.1. Terminology
This document utilizes the terminology as defined in [RFC7431] and This document utilizes the terminology as defined in [RFC7431] and
incorporates the concepts established in [RFC7490]. The definitions incorporates the concepts established in [RFC7490]. The definitions
of individual terms are not reiterated within this document. of individual terms are not reiterated within this document.
2. Problem Statement 2. Problem Statement
2.1. LFA for MoFRR 2.1. LFA for MoFRR
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 from implementing MoFRR protection. a standby multicast tree, and thus preventing the implementation of
Consequently, the [RFC7431] MoFRR functionality in PIM is applicable MoFRR protection. Consequently, the [RFC7431] MoFRR functionality in
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 [RFC7431] MoFRR applicability 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
skipping to change at page 5, line 29 skipping to change at line 204
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 NodeSID 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 NodeSID.
PIM can look up the corresponding node 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 NodeSID 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 outgoing interface list, to form a complete end-to-end multicast tree
tree for forwarding multicast traffic. Therefore, simply sending PIM for forwarding multicast traffic. Therefore, simply sending PIM Join
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 [RFC7431] MoFRR, 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:
* The first RPF Vector contains the IP address of R6, which serves * The first RPF Vector contains the IP address of R6, which serves
as R3's P-node for the protected R3-R2 link. as R3's P-node for the protected R3-R2 link.
skipping to change at page 7, line 17 skipping to change at line 281
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 link-state database of the IGP and assumed retrieved from the local LSDB of the IGP and assumed to be IP-a.
to be IP-a. Similarly, the IP addresses of the two endpoints of the Similarly, the IP addresses of the two endpoints of the link
link corresponding to AdjSID(A-B) can also be retrieved from the corresponding to AdjSID(A-B) can also be retrieved from the local
local link-state database 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
address of the upstream neighbor. Consequently, IP-Lb can be address of the upstream neighbor. Consequently, IP-Lb can be
included in the PIM Join packet as the explicit RPF Vector Attribute. included in the PIM Join packet as the Explicit RPF Vector Attribute.
The PIM protocol initially selects the RPF incoming interface and The PIM protocol initially selects the RPF incoming interface and
upstream neighbor towards IP-a and proceeds hop-by-hop to establish upstream neighbor towards IP-a and proceeds hop by hop to establish
the PIM standby multicast tree until reaching node A. At node A, IP- the PIM standby multicast tree until reaching node A. At node A, IP-
Lb is treated as the PIM upstream neighbor. Node A identifies the Lb is treated as the PIM upstream neighbor. Node A identifies the
incoming interface in the unicast routing table based on IP-Lb, and incoming interface in the unicast routing table based on IP-Lb, and
IP-Lb is used as the RPF upstream address for the PIM Join packet IP-Lb is used as the RPF upstream address for the PIM Join packet
directed towards node B. directed towards node B.
Upon receiving the PIM Join packet at node B, the PIM protocol, Upon receiving the PIM Join packet at node B, the PIM protocol,
finding no additional RPF Vector Attributes, selects the RPF incoming finding no additional RPF Vector Attributes, selects the RPF incoming
interface and upstream neighbor towards the multicast source interface and upstream neighbor towards the multicast source
directly. The protocol, then, continues hop-by-hop to establish the directly. The protocol then continues hop by hop to establish the
PIM standby multicast tree, extending to the router directly PIM standby multicast tree, extending to the router directly
connected to the source. connected to the source.
When a remote PQ node exists in both P-space and Q-space, the When a remote PQ node exists in both P-space and Q-space, the
processing can be simplified to involve only Node A. processing can be simplified to involve only node A.
4. Illustration 4. Illustration
This section provides an illustration of MoFRR based on TI-LFA. The This section provides an illustration of MoFRR based on TI-LFA. The
example topology is depicted in Figure 2. The metric for the R3-R4 example topology is depicted in Figure 2. The metric for the R3-R4
link is 100, while the metrics for the other links are 10. All link link is 100, while the metrics for the other links are 10. All link
metrics are bidirectional. metrics are bidirectional.
<-----Primary Path--- (S,G) Join <-----Primary Path--- (S,G) Join
skipping to change at page 8, line 24 skipping to change at line 336
| | | | | | | |
| (R3)------(R4) | | (R3)------(R4) |
| | | |
--Secondary Path-- --Secondary Path--
Figure 2: Example Topology Figure 2: Example Topology
The IP addresses and SIDs involved in the MoFRR calculation are The IP addresses and SIDs involved in the MoFRR calculation are
configured as follows: configured as follows:
IPv4 Data Plane (MPLS-SR [RFC8660]) IPv4 data plane (SR-MPLS [RFC8660]):
Node IP Address Node SID Node IP Address Node SID
R4 IP4-R4 Label-R4 R4 IP4-R4 Label-R4
Link IP Address Adjacency SID Link IP Address Adjacency SID
R3->R4 IP4-R3-R4 Label-R3-R4 R3->R4 IP4-R3-R4 Label-R3-R4
R4->R3 IP4-R4-R3 Label-R4-R3 R4->R3 IP4-R4-R3 Label-R4-R3
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 traditional
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 MPLS-SR data SID of R4 and the Adjacency SID of R4->R3. On the Segment Routing
plane, the repair segment list is (Label-R4, Label-R4-R3). On the over MPLS (SR-MPLS) data plane, the repair segment list is (Label-R4,
SRv6 data plane, the repair segment list is (SID-R4, SID-R4-R3). Label-R4-R3). On the Segment Routing over IPv6 (SRv6) data plane,
the repair segment list is (SID-R4, SID-R4-R3).
........ ........
. . . .
[S]---(R1)---(R2)******(R6)---[R] [S]---(R1)---(R2)******(R6)---[R]
. | . | . | . |
. | . +++|++++ . | . +++|++++
. | . + | + . | . + | +
. | . + (R5) + . | . + (R5) +
. | . + | + . | . + | +
. | . + | + . | . + | +
. | . + | + . | . + | +
. (R3)------(R4) + . (R3)------(R4) +
. . + + . . + +
........ ++++++++ ........ ++++++++
Q-Space P-Space Q-Space P-Space
Figure 3: P-Space and Q-Space Figure 3: P-Space and Q-Space
In the PIM process, the IP addresses associated with the repair In the PIM process, the IP addresses associated with the repair
segment list are retrieved from the IGP link-state database. segment list are retrieved from the IGP LSDB.
On the IPv4 data plane, the Node SID Label-R4 corresponds to IP4-R4, On the IPv4 data plane, the Node SID Label-R4 corresponds to IP4-R4,
which will be carried in the RPF Vector Attribute. The Adjacency SID which will be carried in the RPF Vector Attribute. The Adjacency SID
Label-R4-R3 corresponds to the local address IP4-R4-R3 and the remote Label-R4-R3 corresponds to the local address IP4-R4-R3 and the remote
peer address IP4-R3-R4, with IP4-R3-R4 carried in the Explicit RPF peer address IP4-R3-R4, with IP4-R3-R4 carried in the Explicit RPF
Vector Attribute. Vector Attribute.
On the IPv6 data plane, the End SID SID-R4 corresponds to IP6-R4, On the IPv6 data plane, the End SID SID-R4 corresponds to IP6-R4,
which will be carried in the RPF Vector Attribute. The End.X SID which will be carried in the RPF Vector Attribute. The End.X SID
SID-R4-R3 corresponds to the local address IP6-R4-R3 and the remote SID-R4-R3 corresponds to the local address IP6-R4-R3 and the remote
peer address IP6-R3-R4, with IP6-R3-R4 carried in the Explicit RPF peer address IP6-R3-R4, with IP6-R3-R4 carried in the Explicit RPF
Vector Attribute. Vector Attribute.
Subsequently, R6 installs the secondary UMH using these RPF Subsequently, R6 installs the secondary UMH using these RPF Vectors.
Vectors.
+---------+ +---------+
|Type = 0 | |Type = 0 |
|IP4-R4 | |IP4-R4 |
+---------+ +---------+ +---------+ +---------+
|Type = 4 | |Type = 4 | |Type = 4 | |Type = 4 |
|IP4-R3-R4| |IP4-R3-R4| |IP4-R3-R4| |IP4-R3-R4|
+---------+ +---------+ No RPF Vector +---------+ +---------+ No RPF Vector
R6----->R5---->R4------------>R3----->R2---->R1 R6----->R5---->R4------------>R3----->R2---->R1
Figure 4: Forwarding PIM Join Packet along Secondary Path (IPv4) Figure 4: Forwarding PIM Join Packet Along Secondary Path (IPv4)
On the IPv4 data plane, the forwarding of the PIM Join packet along On the IPv4 data plane, the forwarding of the PIM Join packet along
the secondary path is shown in Figure 4. the secondary path is shown in Figure 4.
R6 inserts two RPF Vector Attributes in the PIM Join packet: IP4-R4 R6 inserts two RPF Vector Attributes in the PIM Join packet: IP4-R4
of Type 0 (RPF Vector Attribute) and IP4-R3-R4 of Type 4 (Explicit of Type 0 (RPF Vector Attribute) and IP4-R3-R4 of Type 4 (Explicit
RPF Vector Attribute). R6 then forwards the packet along the RPF Vector Attribute). R6 then forwards the packet along the
secondary path. secondary path.
When R5 receives the packet, it performs a unicast route lookup of When R5 receives the packet, it performs a unicast route lookup of
skipping to change at page 10, line 38 skipping to change at line 435
R4, being the owner of IP4-R4, removes the first RPF Vector from the R4, being the owner of IP4-R4, removes the first RPF Vector from the
packet and forwards it according to the next RPF Vector. R4 sends packet and forwards it according to the next RPF Vector. R4 sends
the packet to R3 based on the next RPF Vector IP4-R3-R4, as its PIM the packet to R3 based on the next RPF Vector IP4-R3-R4, as its PIM
neighbor R3 corresponds to IP4-R3-R4. neighbor R3 corresponds to IP4-R3-R4.
When R3 receives the packet, as the owner of IP4-R3-R4, it removes When R3 receives the packet, as the owner of IP4-R3-R4, it removes
the RPF Vector. The packet, now devoid of RPF Vectors, is forwarded the RPF Vector. The packet, now devoid of RPF Vectors, is forwarded
to the source through R3->R2->R1 based on unicast routes. to the source through R3->R2->R1 based on unicast routes.
After the PIM Join packet reaches R1, a secondary multicast tree, After the PIM Join packet reaches R1, a secondary multicast tree,
R1->R2->R3->R4->R5->R6, is established hop-by-hop for (S, G) using R1->R2->R3->R4->R5->R6, is established hop by hop for (S, G) using
MoFRR based on TI-LFA. MoFRR based on TI-LFA.
+---------+ +---------+
|Type = 0 | |Type = 0 |
|IP6-R4 | |IP6-R4 |
+---------+ +---------+ +---------+ +---------+
|Type = 4 | |Type = 4 | |Type = 4 | |Type = 4 |
|IP6-R3-R4| |IP6-R3-R4| |IP6-R3-R4| |IP6-R3-R4|
+---------+ +---------+ No RPF Vector +---------+ +---------+ No RPF Vector
R6----->R5---->R4------------>R3----->R2---->R1 R6----->R5---->R4------------>R3----->R2---->R1
Figure 5: Forwarding PIM Join Packet along Secondary Path (IPv6) Figure 5: Forwarding PIM Join Packet Along Secondary Path (IPv6)
On the IPv6 data plane, the forwarding of the PIM Join packet along On the IPv6 data plane, the forwarding of the PIM Join packet along
the secondary path is illustrated in Figure 5. The procedure is the secondary path is illustrated in Figure 5. The procedure is
analogous to that of the IPv4 data plane. analogous to that of the IPv4 data plane.
When a remote PQ node exists in both P-space and Q-space, the When a remote PQ node exists in both P-space and Q-space, the
processing can be simplified to involve only the PQ node. In this processing can be simplified to involve only the PQ node. In this
case, only a single RPF Vector needs to be carried, and all other case, only a single RPF Vector needs to be carried, and all other
processing steps remain unchanged. processing steps remain unchanged.
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].
But, in the operation of this approach, the node on the backup Join However, in the operation of this approach, the node on the backup
paths must have independent configuration strategy for installing RPF Join paths must have an independent configuration strategy for
Vector Attributes in the PIM Join packet and controlling the sending installing RPF Vector Attributes in the PIM Join packet and
of this PIM Join messages. 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 RPF Vector attribute. If the nodes do not understand message with the RPF Vector Attribute. If the nodes do not
the RPF Vector attribute in the PIM Join packet, then it must discard understand the RPF Vector Attribute in the PIM Join packet, then it
the RPF Vector attribute because failing to remove the RPF Vectors must discard the RPF Vector Attribute because failing to remove the
could cause upstream nodes to send the Join back toward these nodes RPF Vectors could cause upstream nodes to send the Join back towards
causing loops. 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 setup correctly. debugging and to ensure that the Join state is set up correctly.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Security Considerations 7. Security Considerations
This document does not introduce additional security concerns. It This document does not introduce additional security concerns. It
does not change the security properties of PIM. For general PIM-SM does not change the security properties of PIM. For general PIM -
protocol security considerations, see [RFC7761]. The security Sparse Mode (PIM-SM) protocol security considerations, see [RFC7761].
considerations of LFA, R-LFA, and MoFRR described in [RFC5286], The security considerations of LFA, RLFA, and MoFRR described in
[RFC7490], and [RFC7431] should apply to this document. [RFC5286], [RFC7490], and [RFC7431] should apply to this document.
When deploying TI-LFA, packets may be sent over nodes and links they When deploying TI-LFA, packets may be sent over nodes and links they
were not transported through before, potentially raising the were not transported through before, potentially raising the
following security issues: following security issues:
1. Spoofing and False Route Advertisements 1. Spoofing and false route advertisements
* Dependencies of LFA/R-LFA/TI-LFA on Routing Information
* Dependencies of LFA/RLFA/TI-LFA on routing information
- LFAs depend on accurate routing information to determine - LFAs depend on accurate routing information to determine
alternate paths. If an attacker can inject false routing alternate paths. If an attacker can inject false routing
information (e.g., by spoofing link-state advertisements), information (e.g., by spoofing link-state advertisements),
it could cause the network to select suboptimal or it could cause the network to select suboptimal or
malicious paths for LFAs. malicious paths for LFAs.
- R-LFA and TI-LFA also depend on accurate routing - RLFA and TI-LFA also depend on accurate routing
information, particularly for determining the tunneling information, particularly for determining the tunneling
paths or explicit paths. False route advertisements could paths or explicit paths. False route advertisements could
mislead the network into using insecure or compromised mislead the network into using insecure or compromised
paths. paths.
2. On-path Attacks 2. On-path attacks
* Use of Alternate Paths * Use of alternate paths
- By rerouting traffic through alternate paths, especially - By rerouting traffic through alternate paths, especially
those that traverse multiple hops (as in R-LFA and TI-LFA), those that traverse multiple hops (as in RLFA and TI-LFA),
the risk of On-path attacks increases if any of the the risk of on-path attacks increases if any of the
intermediate routers on the alternate path is compromised. intermediate routers on the alternate path are compromised.
- TI-LFA, which uses explicit paths, might expose traffic to - TI-LFA, which uses explicit paths, might expose traffic to
routers that were not originally part of the primary path, routers that were not originally part of the primary path,
potentially allowing for interception or alteration of the potentially allowing for interception or alteration of the
traffic. traffic.
3. Confidentiality and Integrity 3. Confidentiality and integrity
* Traffic Encapsulation * Traffic encapsulation
- R-LFA and TI-LFA involve encapsulating traffic, which may - RLFA and TI-LFA involve encapsulating traffic, which may
expose it to vulnerabilities if the encapsulation expose it to vulnerabilities if the encapsulation
mechanisms are not secure. For instance, if IPsec or mechanisms are not secure. For instance, if IPsec or
another secure encapsulation method is not used, an another secure encapsulation method is not used, an
attacker might be able to intercept or alter the traffic in attacker might be able to intercept or alter the traffic in
transit. transit.
* Protection of Explicit Paths * Protection of explicit paths
- TI-LFA relies on explicit paths that are typically defined - TI-LFA relies on explicit paths that are typically defined
using segment routing. If these paths are not properly using SR. If these paths are not properly protected, an
protected, an attacker could manipulate the segment list to attacker could manipulate the segment list to reroute
reroute traffic through malicious nodes. traffic through malicious nodes.
4. Increased Attack Surface 4. Increased attack surface
* Extended Topology
- By introducing LFA, R-LFA, and TI-LFA, the network * Extended topology
increases its reliance on additional routers and links,
thereby expanding the potential attack surface. Compromise
of any router in these alternate paths could expose traffic
to unauthorized access or disruption.
To address security issues #1 and #2 mentioned above, control plane - By introducing LFA, RLFA, and TI-LFA, the network increases
its reliance on additional routers and links, thereby
expanding the potential attack surface. Compromise of any
router in these alternate paths could expose traffic to
unauthorized access or disruption.
To address security issues 1 and 2 mentioned above, control plane
protocols need to provide security protection. To mitigate the risks protocols need to provide security protection. To mitigate the risks
associated with false route advertisements and On-path attacks, it is associated with false route advertisements and on-path attacks, it is
recommended to use secure routing protocols (e.g., OSPFv3 with IPsec, recommended to use secure routing protocols (e.g., OSPFv3 with IPsec,
ISIS HMAC-SHA256, or PIM with IPsec) that provide authentication and IS-IS HMAC-SHA256, or PIM with IPsec) that provide authentication and
integrity protection for routing updates. integrity protection for routing updates.
To address security issues #3 and #4 mentioned above, these To address security issues 3 and 4 mentioned above, these mechanisms
mechanisms need to run within a trusted network. The security of need to run within a trusted network. The security of LFA, RLFA, and
LFA, R-LFA, and TI-LFA mechanisms heavily relies on the TI-LFA mechanisms heavily relies on the trustworthiness of the
trustworthiness of the underlying routing infrastructure. As the underlying routing infrastructure. As the solution described in the
solution described in the document is based on Segment Routing document is based on SR technology, readers should be aware of the
technology, readers should be aware of the security considerations security considerations related to this technology (see [RFC8402])
related to this technology ([RFC8402]) and its data plane and its data plane instantiations (see [RFC8660], [RFC8754], and
instantiations ([RFC8660], [RFC8754], and [RFC8986]). [RFC8986]).
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-rtgwg-segment-routing-ti-lfa] [RFC9855] Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress, Reroute Using Segment Routing", RFC 9855,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- DOI 10.17487/RFC9855, September 2025,
21, 12 February 2025, <https://www.rfc-editor.org/info/rfc9855>.
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
segment-routing-ti-lfa-21>.
[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 page 15, line 43 skipping to change at line 676
Authors' Addresses Authors' Addresses
Yisong Liu Yisong Liu
China Mobile China Mobile
China China
Email: liuyisong@chinamobile.com Email: liuyisong@chinamobile.com
Mike McBride Mike McBride
Futurewei Inc. Futurewei Inc.
USA United States of America
Email: michael.mcbride@futurewei.com Email: michael.mcbride@futurewei.com
Zheng(Sandy) Zhang Zheng(Sandy) Zhang
ZTE Corporation ZTE Corporation
China China
Email: zzhang_ietf@hotmail.com Email: zzhang_ietf@hotmail.com
Jingrong Xie Jingrong Xie
Huawei Technologies Huawei Technologies
China China
Email: xiejingrong@huawei.com Email: xiejingrong@huawei.com
Changwang Lin Changwang Lin
New H3C Technologies New H3C Technologies
China China
Email: linchangwang.04414@h3c.com Email: linchangwang.04414@h3c.com
 End of changes. 63 change blocks. 
168 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.48.