PIM Working Group                                                 Y. Liu
Internet-Draft                                              China Mobile
Intended status: Informational                                M. McBride
Expires: 24 July 2025                                          Futurewei
                                                                Z. Zhang
                                                                     ZTE
                                                                  J. Xie
                                                                  Huawei
                                                                  C. Lin
                                                    New H3C Technologies
                                                         20 January 2025


  Multicast-only Fast Reroute Based on Topology Independent Loop-free
                         Alternate Fast Reroute
                     draft-ietf-pim-mofrr-tilfa-09

Abstract

   This document specifies the use of Topology Independent Loop-Free
   Alternate (TI-LFA) mechanisms with Multicast Only Fast ReRoute
   (MoFRR) for Protocol Independent Multicast (PIM).  The TI-LFA
   mechanism is designed for standard link-state Interior Gateway
   Protocol (IGP) shortest path and Segment Routing (SR) scenarios.  TI-
   LFA provides fast reroute protection for unicast traffic in IP
   networks by precomputing backup paths that avoid potential failures.
   By integrating TI-LFA with MoFRR, this document extends the benefits
   of fast reroute mechanisms to multicast traffic, enabling enhanced
   resilience and minimized packet loss in multicast networks.  The
   document outlines the necessary protocol extensions and operational
   considerations to implement TI-LFA in conjunction with MoFRR for PIM,
   ensuring that multicast traffic is rapidly rerouted in the event of a
   failure.  This document uses the backup path computed by TI-LFA
   through IGP as a secondary Upstream Multicast Hop (UMH) for PIM.  By
   using the TI-LFA backup path to send PIM secondary join messages hop-
   by-hop, it achieves the generation of a fast reroute backup path for
   PIM multicast.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.




Liu, et al.               Expires 24 July 2025                  [Page 1]

Internet-Draft            MoFRR based on TILFA              January 2025


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 July 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  LFA for MoFRR . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  RLFA for MoFRR  . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  TI-LFA for MoFRR  . . . . . . . . . . . . . . . . . . . .   6
   3.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Illustration  . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Join Conflict Considerations  . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The increasing deployment of video services has heightened the
   importance for network operators to implement solutions that minimize
   service disruptions caused by faults in the IP networks carrying
   these services.  Multicast-only Fast Reroute (MoFRR), as defined in
   [RFC7431], offers a mechanism to reduce multicast packet loss in the
   event of node or link failures by introducing simple enhancements to



Liu, et al.               Expires 24 July 2025                  [Page 2]

Internet-Draft            MoFRR based on TILFA              January 2025


   multicast routing protocols, such as Protocol Independent Multicast
   (PIM).  However, the [RFC7431] MoFRR mechanism, which selects the
   secondary multicast next hop based solely on the loop-free alternate
   fast reroute defined in [RFC7431], has limitations in certain
   multicast deployment scenarios.

   This document introduces a new mechanism for Multicast-only Fast
   Reroute using Topology Independent Loop-Free Alternate (TI-LFA)
   [I-D.ietf-rtgwg-segment-routing-ti-lfa] fast reroute.  Unlike
   traditional methods, TI-LFA is independent of network topology,
   enabling broader coverage across diverse network environments.  The
   applicability of this mechanism extends to PIM networks, including
   scenarios where PIM operates over native IP, as well as public
   network multicast trees established by PIM.  Additionally, this
   document addresses scenarios involving Multicast Distribution Tree
   (MDT) SAFI for Multicast VPN (MVPN) in [RFC6037] and [RFC6514],
   covering PIM-SSM Tree, PIM-SM Tree, and BIDIR-PIM Tree deployments.

   The TI-LFA mechanism is designed for standard link-state Interior
   Gateway Protocol (IGP) shortest path and Segment Routing (SR)
   scenarios.  For each destination specified by the IGP in the network,
   TI-LFA pre-installs a backup forwarding entry for the protected
   destination, ready to be activated upon the detection of a link
   failure used to reach that destination.  This document leverages the
   backup path computed by TI-LFA through the IGP as a secondary
   Upstream Multicast Hop (UMH) for PIM.  By using the TI-LFA backup
   path to send PIM secondary join messages hop by hop, it enables the
   creation of a fast reroute backup path for PIM multicast.

   The protection techniques described in this document are limited to
   protecting links and nodes within a link-state IGP area.  Protecting
   domain exit routers and/or links attached to other routing domains is
   beyond the scope of this document.  All the Segment Identifiers
   (SIDs) required are contained within the Link State Database (LSDB)
   of the IGP.

   Note that this document introduces an optional approach for backup
   join paths, designed to enhance the protection scope of existing
   multicast systems.  It is fully compatible with current protocol
   implementations and does not necessitate any changes to the protocols
   or forwarding functions on intermediate nodes.  If there is a choice
   between vector and non-vector joins on the intermediate nodes, the
   non-vector option should be prioritized, which implies that
   protection paths will remain inactive.  This document does not modify
   the handling of conflicts in PIM joins.  For guidance on conflicts in
   join attributes, please refer to Section 3.3.3 of [RFC5384].





Liu, et al.               Expires 24 July 2025                  [Page 3]

Internet-Draft            MoFRR based on TILFA              January 2025


1.1.  Terminology

   This document utilizes the terminology as defined in [RFC7431] and
   incorporates the concepts established in [RFC7490].  The definitions
   of individual terms are not reiterated within this document.

2.  Problem Statement

2.1.  LFA for MoFRR

   Section 3 of [RFC7431] specifies that the secondary UMH in PIM for
   MoFRR is a Loop-Free Alternate (LFA).  However, the traditional LFA
   mechanism requires that at least one neighbor's next hop to the
   destination node is an loop-free next hop.  Due to existing
   limitations in network deployments, this mechanism only covers
   certain network topology environments.  In specific network
   topologies, the corresponding secondary UMH cannot be computed,
   preventing PIM from establishing a standby multicast tree and thus
   from implementing MoFRR protection.  Consequently, the [RFC7431]
   MoFRR functionality in PIM is applicable only in network topologies
   where LFA is feasible.

   The limitations of the [RFC7431] MoFRR applicability can be
   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
   link is 100, and the metrics of the other links are 10.

   For multicast source S1, the primary path of the PIM 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 scenario, the [RFC7431]
   MoFRR operates effectively.

   For multicast source S2, the primary path of the PIM 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 shortest path from
   R4 to R1 is R4->R3->R2.  In this case, the [RFC7431] MoFRR cannot
   calculate a secondary UMH.  Similarly, for multicast source S3, the
   [RFC7431] MoFRR mechanism is ineffective.













Liu, et al.               Expires 24 July 2025                  [Page 4]

Internet-Draft            MoFRR based on TILFA              January 2025


            [S1]---(R1)----------(R4)
                    |             |
                    |             |           +------+------+
                    |             |           | Link |Metric|
                    |             |           +------+------+
            [S2]---(R2)----------(R3)---[R]   | R1-R4|  20  |
                    |             |           +------+------+
                    |             |           | R5-R6|  100 |
                    |             |           +------+------+
                    |             |           | Other|  10  |
            [S3]---(R5)---(R6)---(R7)         +------+------+

                     Figure 1: Example Network Topology

2.2.  RLFA for MoFRR

   The Remote Loop-Free Alternate (RLFA), as defined in [RFC7490],
   extends the traditional LFA mechanism, allowing it to accommodate a
   broader range of network deployment scenarios by utilizing a tunnel
   as an alternate path.  The RLFA mechanism requires that there exists
   at least one node, denoted as node N, in the network where the fault
   node is neither on the path from the source node to node N nor on the
   path from node N to the destination node.

   [RFC5496] introduces the RPF Vector attribute, which can be included
   in the PIM Join packet to ensure that the path is selected based on
   the unicast reachability of the RPF Vector.  By combining the RLFA
   mechanism with the RPF Vector, the secondary multicast tree for MoFRR
   can be established, thereby supporting a wider range of network
   topologies compared to the [RFC7431] MoFRR implementation with LFA.

   For instance, in the network illustrated in Figure 1, the secondary
   path for the PIM Join packet towards multicast source S2 cannot be
   computed by the [RFC7431] MoFRR, as previously described.  Utilizing
   the RLFA mechanism, R3 sends the packet to R4, including an RPF
   Vector containing the IP address of R1, which serves as the PQ node
   of R3 with respect to the protected R2-R3 link.  Subsequently, R4
   forwards the packet to R1 via the R1-R4 link, in accordance with the
   unicast route associated with the RPF Vector.  R1 then continues to
   forward the packet to R2, thereby establishing the secondary path,
   R3->R4->R1->R2, using MoFRR with RLFA.










Liu, et al.               Expires 24 July 2025                  [Page 5]

Internet-Draft            MoFRR based on TILFA              January 2025


2.3.  TI-LFA for MoFRR

   While RLFA provides enhanced capabilities over LFA, it remains
   dependent on the network topology.  In the network depicted in
   Figure 1, the primary path of the PIM Join packet towards multicast
   source S3 is R3->R2->R5.  However, an RLFA path does not exist
   because the PQ node of R3 with respect to the protected link R2-R3 is
   absent.  If R3 sends the packet to R7 with an RPF Vector containing
   the IP address of R5, R7 will forward it back to R3, as the IGP
   shortest path from R7 to R5 is R7->R3->R2->R5.  Similarly, if R3
   sends the packet to R7 with an RPF Vector containing the IP address
   of R6, R7 will forward it to R6, but R6 will then forward it back to
   R7, as the IGP shortest path from R6 to R5 is R6->R7->R3->R2->R5.  In
   this scenario, MoFRR with RLFA is unable to compute a secondary UMH.

   RLFA offers improvements over LFA but still has inherent limitations.
   [I-D.ietf-rtgwg-segment-routing-ti-lfa] defines a unicast FRR
   solution based on the TI-LFA mechanism.  The TI-LFA mechanism allows
   the expression of a backup path using an explicit path and imposes no
   constraints on the network topology, thus providing a more robust FRR
   mechanism.  Unicast traffic can be forwarded according to an explicit
   path list as an alternate path to protect unicast traffic, achieving
   full coverage across various network environments.

   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
   the Adjacency SIDs of the links between the P-space and Q-space
   nodes.  PIM can look up the corresponding node IP address in the
   unicast route according to the NodeSID and the IP addresses of the
   endpoints of the corresponding link in the unicast route according to
   the Adjacency SIDs.  However, multicast protocol packets cannot be
   directly forwarded along the path of the Segment List.

   To establish a standby multicast tree, PIM Join messages need to be
   transmitted hop-by-hop.  However, not all nodes and links on the
   unicast alternate path are included in the Segment List.  If PIM
   protocol packets are transmitted solely in unicast mode, they
   effectively traverse the unicast tunnel like unicast traffic and do
   not pass through the intermediate nodes of the tunnel.  Consequently,
   the intermediate nodes on the alternate path cannot forward multicast
   traffic because they lack PIM state entries.  PIM must create entries
   on each device hop-by-hop, generating an incoming interface and an
   outgoing interface list, to form a complete end-to- end multicast
   tree for forwarding multicast traffic.  Therefore, simply sending PIM
   Join packets using the Segment List, as done with unicast traffic, is
   insufficient to establish a standby multicast tree.





Liu, et al.               Expires 24 July 2025                  [Page 6]

Internet-Draft            MoFRR based on TILFA              January 2025


3.  Solution

   A secondary Upstream Multicast Hop (UMH) serves as a candidate next-
   hop that can be used to reach the root of the multicast tree.  In
   this document, the secondary UMH is derived from unicast routing,
   utilizing the Segment List computed by TI-LFA.

   In essence, the path information from the Segment List is
   incorporated into the PIM packets to guide hop-by-hop Reverse Path
   Forwarding (RPF) selection.  The IP address 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 link associated with the
   Adjacency SID can be directly used as the local upstream interface
   and upstream neighbor.

   For the PIM protocol, [RFC5496] defines the PIM RPF Vector attribute,
   which can carry the node IP address corresponding to the Node SID.
   Additionally, [RFC7891] defines the explicit RPF Vector, which can
   carry the peer IP address corresponding to the Adjacency SID.

   This document leverages the existing RPF Vector standards, obviating
   the need for PIM protocol extensions.  This approach allows the
   establishment of a standby multicast tree based on the Segment List
   calculated by TI-LFA, thereby providing comprehensive MoFRR
   protection for multicast services across diverse network
   environments.

   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
   the Q space.  The IP address corresponding to NodeSID(A) can be
   retrieved from the local link-state database of the IGP protocol and
   assumed to be IP-a.  Similarly, the IP addresses of the two endpoints
   of the link corresponding to AdjSID(A-B) can also be retrieved from
   the local link-state database and assumed to be IP-La and IP-Lb.

   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
   local address of the incoming interface, and IP-Lb is regarded as the
   address of the upstream neighbor.  Consequently, IP-Lb can be
   included in the PIM Join packet as the explicit RPF Vector Attribute.

   The PIM protocol initially selects the RPF incoming interface and
   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-
   Lb is treated as the PIM upstream neighbor.  Node A identifies the
   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
   directed towards node B.



Liu, et al.               Expires 24 July 2025                  [Page 7]

Internet-Draft            MoFRR based on TILFA              January 2025


   Upon receiving the PIM Join packet at node B, the PIM protocol,
   finding no additional RPF Vector Attributes, selects the RPF incoming
   interface and upstream neighbor towards the multicast source
   directly.  The protocol then continues hop-by-hop to establish the
   PIM standby multicast tree, extending to the router directly
   connected to the source.

4.  Illustration

   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
   link is 100, while the metrics for the other links are 10.  All link
   metrics are bidirectional.

                     <-----Primary Path--- (S,G) Join

             [S]---(R1)---(R2)******(R6)-------[R]
                            |        |
                     <---   |        |   |
                        |   |        |   |
                        |   |       (R5) |
                        |   |        |   |
                        |   |        |   |
                        |   |        |   |
                        | (R3)------(R4) |
                        |                |
                        --Secondary Path--

                         Figure 2: Example Topology

   The IP addresses and SIDs involved in the MoFRR calculation are
   configured as follows:

   IPv4 Data Plane (MPLS-SR)

















Liu, et al.               Expires 24 July 2025                  [Page 8]

Internet-Draft            MoFRR based on TILFA              January 2025


     Node    IP Address   Node SID
     R4      IP4-R4       Label-R4

     Link    IP Address   Adjacency SID
     R3->R4  IP4-R3-R4    Label-R3-R4
     R4->R3  IP4-R4-R3    Label-R4-R3

   IPv6 Data Plane (SRv6)

     Node    IP Address   Node SID (End)
     R4      IP6-R4       SID-R4

     Link    IP Address   Adjacency SID (End.X)
     R3->R4  IP6-R3-R4    SID-R3-R4
     R4->R3  IP6-R4-R3    SID-R4-R3

   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
   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
   link.  In this scenario, R6 must calculate the secondary UMH using
   the proposed MoFRR method based on TI-LFA.

   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
   SID of R4 and the Adjacency SID of R4->R3.  On the MPLS-SR data
   plane, the repair segment list is (Label-R4, Label-R4-R3).  On the
   SRv6 data plane, the repair segment list is (SID-R4, SID-R4-R3).

                           ........
                           .      .
                 [S]---(R1)---(R2)******(R6)---[R]
                           .   |  .     |
                           .   |  .  +++|++++
                           .   |  .  +  |   +
                           .   |  .  + (R5) +
                           .   |  .  +  |   +
                           .   |  .  +  |   +
                           .   |  .  +  |   +
                           . (R3)------(R4) +
                           .      .  +      +
                           ........  ++++++++
                           Q-Space    P-Space

                       Figure 3: P-Space and Q-Space

   In the PIM process, the IP addresses associated with the repair
   segment list are retrieved from the IGP link-state database.



Liu, et al.               Expires 24 July 2025                  [Page 9]

Internet-Draft            MoFRR based on TILFA              January 2025


   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
   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
   Vector Attribute.

   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
   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
   Vector Attribute.

   Subsequently, R6 installs the secondary UMH using these RPF
   Vectors.

             +---------+
             |Type = 0 |
             |IP4-R4   |
             +---------+    +---------+
             |Type = 4 |    |Type = 4 |
             |IP4-R3-R4|    |IP4-R3-R4|
             +---------+    +---------+   No RPF Vector

          R6----->R5---->R4------------>R3----->R2---->R1

      Figure 4: Forwarding PIM Join Packet along Secondary Path (IPv4)

   On the IPv4 data plane, the forwarding of the PIM Join packet along
   the secondary path is shown in Figure 4.

   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
   RPF Vector Attribute).  R6 then forwards the packet along the
   secondary path.

   When R5 receives the packet, it performs a unicast route lookup of
   the first RPF Vector IP4-R4 and sends the packet to R4.

   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
   the packet to R3 based on the next RPF Vector IP4-R3-R4, as its PIM
   neighbor R3 corresponds to IP4-R3-R4.

   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
   to the source through R3->R2->R1 based on unicast routes.





Liu, et al.               Expires 24 July 2025                 [Page 10]

Internet-Draft            MoFRR based on TILFA              January 2025


   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
   MoFRR based on TI-LFA.

             +---------+
             |Type = 0 |
             |IP6-R4   |
             +---------+    +---------+
             |Type = 4 |    |Type = 4 |
             |IP6-R3-R4|    |IP6-R3-R4|
             +---------+    +---------+   No RPF Vector

          R6----->R5---->R4------------>R3----->R2---->R1

      Figure 5: Forwarding PIM Join Packet along Secondary Path (IPv6)

   On the IPv6 data plane, the forwarding of the PIM Join packet along
   the secondary path is illustrated in Figure 5.  The procedure is
   analogous to that of the IPv4 data plane.

5.  Join Conflict Considerations

   This section illustrates the resolution of PIM join conflicts.  When
   intermediate nodes must choose between PIM joins with an RPF Vector
   attribute and those without, priority should be given to the joins
   without the RPF Vector attribute.  Figure 6 shows the example
   topology.  In this setup, the metric for the R3-R4 link is 100, while
   the metrics for all other links are 10.  Additionally, all link
   metrics are bidirectional.

                     <---(1)-Primary Path--- (S,G) Join
             [S]---(R1)---(R2)******(R6)-------[Receiver1]
                            |        |   ^
                     <---   |        |   |             |
                        |   |        |   |             |
                        |   |       (R5) |             |
                        |   |        | (3)-(S,G) Join  |
                        |   |        |   |             |
                        |   |        |   |             |
                        | (R3)------(R4)--[Receiver2]  |
                        |                              |
                        +-(2)-Secondary Path--(S,G)----+

             (1): Receiver1 Primary Path PIM Join (2): Receiver1
             Secondary Path PIM Join with RPF Vector (3): Receiver2
             Primary Path PIM Join

      Figure 6:        Join Conflict Scenario



Liu, et al.               Expires 24 July 2025                 [Page 11]

Internet-Draft            MoFRR based on TILFA              January 2025


   Figure 6 illustrates that both R6 and R4 have receivers, with R6
   utilizing MoFRR based on TI-LFA.  At R6 the primary PIM Join packet
   path is R6->R2->R1, while the secondary path is
   R6->R5->R4->R3->R2->R1.  At R4 the PIM Join packet path is
   R4->R5->R6->R2->R1.

   On R5, the PIM forwarding entries are:

   [R5]:

      (S,G) Entry 1 from Receiver1:

         Incoming interface: R4-R5

         Outgoing interface: R5-R6 (Join with RPF Vector)

      (S,G) Entry 2 from Receiver2:

         Incoming interface: R6-R5

         Outgoing interface: R5-R4 (Join without RPF Vector)

   To prevent conflicts, the PIM Join without the RPF Vector should be
   prioritized.  Thus, R5 retains only the entry2 with R6-R5 as the
   incoming interface and R5-R4 as the outgoing interface.  After
   selection, the final forwarding entry on R5 is as follows:

   [R5]:

      (S,G) active forwarding Entry:

        Incoming interface: R6-R5

        Outgoing interface: R5-R4

   This document specifies an optional approach for backup join paths,
   intended to enhance the protection scope of existing multicast
   systems.  It is fully compatible with existing protocol
   implementations and does not require changes to protocols or
   forwarding functions on intermediate nodes.  In the event of PIM join
   conflicts, joins without the RPF Vector attribute are prioritized to
   ensure that the original PIM forwarding functionality remains
   unaffected.

6.  IANA Considerations

   This document has no IANA actions.




Liu, et al.               Expires 24 July 2025                 [Page 12]

Internet-Draft            MoFRR based on TILFA              January 2025


7.  Security Considerations

   This document does not introduce additional security concerns.  It
   does not change the security properties of PIM.  For general PIM-SM
   protocol security considerations, see [RFC7761].  The security
   considerations of LFA, R-LFA, and MoFRR described in [RFC5286],
   [RFC7490], and [RFC7431] should apply to this document.

   When deploying TILFA, packets may be sent over nodes and links they
   were not transported through before, potentially raising the
   following security issues:

   1.  Spoofing and False Route Advertisements

       *  Dependencies of LFA/R-LFA/TI-LFA on Routing Information

          -  LFAs depend on accurate routing information to determine
             alternate paths.  If an attacker can inject false routing
             information (e.g., by spoofing link-state advertisements),
             it could cause the network to select suboptimal or
             malicious paths for LFAs.

          -  R-LFA and TI-LFA also depend on accurate routing
             information, particularly for determining the tunneling
             paths or explicit paths.  False route advertisements could
             mislead the network into using insecure or compromised
             paths.

   2.  Man-in-the-Middle (MitM) Attacks

       *  Use of Alternate Paths

          -  By rerouting traffic through alternate paths, especially
             those that traverse multiple hops (as in R-LFA and TI-LFA),
             the risk of MitM attacks increases if any of the
             intermediate routers on the alternate path are compromised.

          -  TI-LFA, which uses explicit paths, might expose traffic to
             routers that were not originally part of the primary path,
             potentially allowing for interception or alteration of the
             traffic.

   3.  Confidentiality and Integrity

       *  Traffic Encapsulation






Liu, et al.               Expires 24 July 2025                 [Page 13]

Internet-Draft            MoFRR based on TILFA              January 2025


          -  R-LFA and TI-LFA involve encapsulating traffic, which may
             expose it to vulnerabilities if the encapsulation
             mechanisms are not secure.  For instance, if IPsec or
             another secure encapsulation method is not used, an
             attacker might be able to intercept or alter the traffic in
             transit.

       *  Protection of Explicit Paths

          -  TI-LFA relies on explicit paths that are typically defined
             using segment routing.  If these paths are not properly
             protected, an attacker could manipulate the segment list to
             reroute traffic through malicious nodes.

   4.  Increased Attack Surface

       *  Extended Topology

          -  By introducing LFA, R-LFA, 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
   associated with false route advertisements and MitM attacks, it is
   recommended to use secure routing protocols (e.g., OSPFv3 with IPsec,
   ISIS HMAC-SHA256, or PIM with IPsec) that provide authentication and
   integrity protection for routing updates.

   To address security issues #3 and #4 mentioned above, these
   mechanisms need to run within a trusted network.  The security of
   LFA, R-LFA, and TI-LFA mechanisms heavily relies on the
   trustworthiness of the underlying routing infrastructure.  As the
   solution described in the document is based on Segment Routing
   technology, readers should be aware of the security considerations
   related to this technology ([RFC8402]) and its data plane
   instantiations ([RFC8660], [RFC8754], and [RFC8986]).

8.  References

8.1.  Normative References

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
              Decraene, B., and D. Voyer, "Topology Independent Fast
              Reroute using Segment Routing", Work in Progress,



Liu, et al.               Expires 24 July 2025                 [Page 14]

Internet-Draft            MoFRR based on TILFA              January 2025


              Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
              19, 22 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
              segment-routing-ti-lfa-19>.

   [RFC5286]  Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
              IP Fast Reroute: Loop-Free Alternates", RFC 5286,
              DOI 10.17487/RFC5286, September 2008,
              <https://www.rfc-editor.org/info/rfc5286>.

   [RFC5384]  Boers, A., Wijnands, I., and E. Rosen, "The Protocol
              Independent Multicast (PIM) Join Attribute Format",
              RFC 5384, DOI 10.17487/RFC5384, November 2008,
              <https://www.rfc-editor.org/info/rfc5384>.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496,
              DOI 10.17487/RFC5496, March 2009,
              <https://www.rfc-editor.org/info/rfc5496>.

   [RFC7431]  Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
              Decraene, "Multicast-Only Fast Reroute", RFC 7431,
              DOI 10.17487/RFC7431, August 2015,
              <https://www.rfc-editor.org/info/rfc7431>.

   [RFC7490]  Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
              So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
              RFC 7490, DOI 10.17487/RFC7490, April 2015,
              <https://www.rfc-editor.org/info/rfc7490>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.

   [RFC7891]  Asghar, J., Wijnands, IJ., Ed., Krishnaswamy, S., Karan,
              A., and V. Arya, "Explicit Reverse Path Forwarding (RPF)
              Vector", RFC 7891, DOI 10.17487/RFC7891, June 2016,
              <https://www.rfc-editor.org/info/rfc7891>.

8.2.  Informative References

   [RFC6037]  Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
              Systems' Solution for Multicast in BGP/MPLS IP VPNs",
              RFC 6037, DOI 10.17487/RFC6037, October 2010,
              <https://www.rfc-editor.org/info/rfc6037>.




Liu, et al.               Expires 24 July 2025                 [Page 15]

Internet-Draft            MoFRR based on TILFA              January 2025


   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8660]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing with the MPLS Data Plane", RFC 8660,
              DOI 10.17487/RFC8660, December 2019,
              <https://www.rfc-editor.org/info/rfc8660>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

Contributors

   Mengxiao Chen
   New H3C Technologies
   China
   Email: chen.mengxiao@h3c.com

Authors' Addresses

   Yisong Liu
   China Mobile
   China
   Email: liuyisong@chinamobile.com


   Mike McBride
   Futurewei Inc.
   USA
   Email: michael.mcbride@futurewei.com





Liu, et al.               Expires 24 July 2025                 [Page 16]

Internet-Draft            MoFRR based on TILFA              January 2025


   Zheng(Sandy) Zhang
   ZTE Corporation
   China
   Email: zzhang_ietf@hotmail.com


   Jingrong Xie
   Huawei Technologies
   China
   Email: xiejingrong@huawei.com


   Changwang Lin
   New H3C Technologies
   China
   Email: linchangwang.04414@h3c.com



































Liu, et al.               Expires 24 July 2025                 [Page 17]