<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!-- pre-edited by ST 04/25/25 --> <!-- formatted by ST 05/01/25 --> <!-- reference review by TH 05/12/25 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <!-- [rfced] Would you like the references to be alphabetized or left in their current order? --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-pim-mofrr-tilfa-14" number="9860" consensus="true" category="info" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="false" tocInclude="true" version="3"> <front> <title abbrev="MoFRRbasedBased onTILFA">Multicast-onlyTI-LFA">Multicast-Only Fast Reroute (MoFRR) Based on Topology IndependentLoop-freeLoop-Free Alternate (TI-LFA) Fast Reroute</title> <seriesInfoname="Internet-Draft" value="draft-ietf-pim-mofrr-tilfa-14"/>name="RFC" value="9860"/> <author initials="Y." surname="Liu" fullname="Yisong Liu"> <organization>China Mobile</organization> <address> <postal><street>China</street><country>China</country> </postal> <email>liuyisong@chinamobile.com</email> </address> </author> <author initials="M." surname="McBride" fullname="Mike McBride"> <organization abbrev="Futurewei">Futurewei Inc.</organization> <address> <postal><street>USA</street><country>United States of America</country> </postal> <email>michael.mcbride@futurewei.com</email> </address> </author> <author initials="Z." surname="Zhang" fullname="Zheng(Sandy) Zhang"> <organization abbrev="ZTE">ZTE Corporation</organization> <address> <postal><street>China</street><country>China</country> </postal> <email>zzhang_ietf@hotmail.com</email> </address> </author> <author initials="J." surname="Xie" fullname="Jingrong Xie"> <organization abbrev="Huawei">Huawei Technologies</organization> <address> <postal><street>China</street><country>China</country> </postal> <email>xiejingrong@huawei.com</email> </address> </author> <author initials="C." surname="Lin" fullname="Changwang Lin"> <organization>New H3C Technologies</organization> <address> <postal><street>China</street><country>China</country> </postal> <email>linchangwang.04414@h3c.com</email> </address> </author> <date year="2025"month="April" day="7"/> <workgroup>PIM Working Group</workgroup>month="September"/> <area>RTG</area> <workgroup>pim</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t> This document specifies the use of Topology Independent Loop-Free Alternate (TI-LFA) mechanisms withMulticast OnlyMulticast-only FastReRouteReroute (MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA providesfast rerouteFast Reroute (FRR) 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 offast rerouteFRR mechanisms to multicast traffic, enabling enhanced resilience and minimized packet loss in multicast networks. The document outlines an optional approach to implement TI-LFA in conjunction with MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in the event of a failure.</t> </abstract> </front> <middle> <section anchor="sect-1" numbered="true" toc="default"> <name>Introduction</name> <t> Multicast-only Fast Reroute (MoFRR), as defined in <xref target="RFC7431" format="default"/>, offers a mechanism to reduce multicast packet loss in the event of node or link failures by introducing simple enhancements to multicast routing protocols, such as Protocol Independent Multicast (PIM) <xref target="RFC7761" format="default"/>. However, the <xref target="RFC7431" format="default"/> MoFRR mechanism, which selects the secondary multicastnext-hopnext hop based solely on theloop-free alternate fast rerouteLoop-Free Alternate (LFA) FRR defined in <xref target="RFC7431" format="default"/>, has limitations in certain multicast deployment scenarios (see <xref target="sect-2" format="default"/>).</t> <t> This document introduces a new mechanism for MoFRR using FRR for Topology Independent Loop-Free Alternate (TI-LFA) <xreftarget="I-D.ietf-rtgwg-segment-routing-ti-lfa" format="default"/> fast reroute.target="RFC9855" format="default"/>. Unlike conventional methods, TI-LFA is independent of network topology, enabling broader coverage across diverse network environments. This mechanism is applicable to PIMnetworks,includingnetworks, including cases where PIM operates natively over IP in Segment Routing (SR) networks.</t> <t> The TI-LFA mechanism is designed for standard link-state Interior Gateway Protocol (IGP) shortest path and SR scenarios. For each destination advertised by the IGP in a network, TI-LFA pre-installs a backup forwarding entry for the protected destination, which is ready to be activated upon the detection of a link failure used to reach that destination. This document leverages the backup path computed byTI- LFATI-LFA through the IGP as a secondary Upstream Multicast Hop (UMH) for PIM. By sending PIM secondary Join messages hop by hop on the TI-LFA backup path, afast rerouteFRR backup path can be created for PIM multicast.</t> <t> The 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.</t> <t> The approach does not alter the existing management and operation of LFA,RLFA,TI-LFA, andTI-LFARemote LFA (RLFA) <xref target="RFC7916" format="default"/> <xref target="RFC8102" format="default"/> <xreftarget="I-D.ietf-rtgwg-segment-routing-ti-lfa"target="RFC9855" format="default"/>. Additionally, during post-failure reconvergence, micro-loops <xref target="RFC5715" format="default"/> may form due to transient forwarding inconsistencies across routers. PIM micro-loop prevention is out of scope for this document.</t> <t> 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. All nodes along the backup Join paths must support theRPFReverse Path Forwarding (RPF) VectorattributeAttribute as defined in <xref target="RFC5496" format="default"/> and <xref target="RFC7891" format="default"/>. If there is a choice between vector and non-vector Join messages 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 Join messages. For guidance on conflicts in Join attributes, please refer toSection 3.3.3 of<xref target="RFC5384"format="default"/>.</t>section="3.3.3"/>.</t> <section anchor="sect-1.1" numbered="true" toc="default"> <name>Terminology</name> <t> This document utilizes the terminology as defined in <xref target="RFC7431" format="default"/> and incorporates the concepts established in <xref target="RFC7490" format="default"/>. The definitions of individual terms are not reiterated within this document.</t> </section> </section> <section anchor="sect-2" numbered="true" toc="default"> <name>Problem Statement</name> <section anchor="sect-2.1" numbered="true" toc="default"> <name>LFA for MoFRR</name> <t>Section 3 of<xref target="RFC7431"format="default"/>section="3"/> specifies that a secondary UMH in PIM for MoFRR is a Loop-Free Alternate (LFA). However, the conventional LFA mechanism requires that at least one neighbor'snext-hopnext hop to the destination node is a loop-freenext-hop.next hop. Due to existing limitations of the LFA mechanism in network deployments, such as topology dependency and incomplete destination coverage, the LFA mechanism can only be deployed in certain network topology environments. In specific network topologies, the secondary UMH cannot be computed in PIM for MoFRR, preventing PIM from establishing a standby multicasttreetree, and thusfrom implementingpreventing the implementation of MoFRR protection. Consequently, the <xref target="RFC7431" format="default"/> MoFRR functionality in PIM is applicable only in network topologies where LFA is feasible.</t> <t> The limitations of the <xref target="RFC7431" format="default"/> MoFRR applicability can be illustrated using the example network depicted inFigure 1.<xref target="ure-example-network-topology"/>. 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. All link metrics are bidirectional.</t> <t> 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, which corresponds to the LFA path of unicast routing. In this scenario, the <xref target="RFC7431" format="default"/> MoFRR operates effectively.</t> <t> 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 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 <xref target="RFC7431" format="default"/> MoFRR cannot calculate a secondary UMH. Similarly, for multicast source S3 and receiver R, the <xref target="RFC7431" format="default"/> MoFRR mechanism is ineffective.</t> <figure anchor="ure-example-network-topology"> <name>Example Network Topology</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 10 20 [S1]----(R1)-------------(R4) | | | | |10 |10 10 | | [S2]----(R2)-------------(R3)----[R] | 10 | 10 | | |10 |10 10 | | [S3]----(R5)-----(R6)----(R7) 100 10 ]]></artwork> </figure> </section> <section anchor="sect-2.2" numbered="true" toc="default"> <name>TI-LFA for MoFRR</name> <t> 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. When a remote PQ node exists in both P-space and Q-space, the Segment List requires only the PQ node's NodeSID.</t> <t> PIM can look up the correspondingnodenode's IP address in the unicast route base according to the NodeSID and the IP addresses of the endpoints of the corresponding link in the unicast route base according to the Adjacency SIDs. However, multicast protocol packets cannot be directly forwarded along the path of the Segment List.</t> <t> To establish a standby multicast tree, PIM Join messages need to be transmittedhop-by-hop.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 devicehop-by-hop,hop by hop, generating an incoming interface and an outgoing interface list, to form a completeend-to- endend-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.</t> </section> </section> <section anchor="sect-3" numbered="true" toc="default"> <name>A Solution</name> <section anchor="sect-3.1" numbered="true" toc="default"> <name>Overview</name> <t> A secondary UMH serves as a candidatenext-hopnext hop that can be used to reach the root of a multicast tree. In this document, the secondary UMH is derived from unicast routing, utilizing the Segment List computed by TI-LFA.</t> <t> The path information from the Segment List is incorporated into the 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, while the IP addresses of the interfaces at both endpoints of the link associated with the Adjacency SID can be used as the local upstream interface and upstream neighbor.</t> <t> <xref target="RFC5496" format="default"/> defines the PIM RPF Vectorattribute,Attribute, which can carry the node's IP address corresponding to the Node SID. Additionally, <xref target="RFC7891" format="default"/> defines theexplicitExplicit RPF Vector, which can carry the peer's IP address corresponding to the Adjacency SID.</t> <t> For instance, in the network illustrated inFigure 1,<xref target="ure-example-network-topology"/>, the secondary path for the PIM Join packet towards multicast source S2 cannot be computed by <xref target="RFC7431" format="default"/> MoFRR, as previously described. Using TI-LFA, 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 R3-R2 link. R4 then forwards the packet to R1 via theR1- R4R1-R4 link according to the unicast route associated with the RPF Vector. R1 subsequently forwards the packet to R2, thus establishing the secondary path R3->R4->R1->R2.</t> <t> 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 the PIM Join packet to R7 while including two RPF Vectors:</t> <ul spacing="normal"> <li> <t>The first RPF Vector contains the IP address of R6, which serves as R3's P-node for the protected R3-R2 link.</t> </li> <li> <t>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.</t> </li> </ul> <t> 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, thereby establishing the secondary path R3->R7->R6->R5.</t> <t> This document leverages the above 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.</t> </section> <section anchor="sect-3.2" numbered="true" toc="default"> <name>Procedure</name> <t> 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 locallink-state databaseLSDB of the IGP 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 locallink-state databaseLSDB and assumed to be IP-La and IP-Lb.</t> <t> 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 theexplicitExplicit RPF Vector Attribute.</t> <t> The PIM protocol initially selects the RPF incoming interface and upstream neighbor towards IP-a and proceedshop-by-hophop 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.</t> <t> 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. Theprotocol, then,protocol then continueshop-by-hophop by hop to establish the PIM standby multicast tree, extending to the router directly connected to the source.</t> <t> When a remote PQ node exists in both P-space and Q-space, the processing can be simplified to involve onlyNodenode A.</t> </section> </section> <section anchor="sect-4" numbered="true" toc="default"> <name>Illustration</name> <t> This section provides an illustration of MoFRR based on TI-LFA. The example topology is depicted inFigure 2.<xref target="ure-example-topology"/>. The metric for the R3-R4 link is 100, while the metrics for the other links are 10. All link metrics are bidirectional.</t> <figure anchor="ure-example-topology"> <name>Example Topology</name> <artwork name="" type="" align="left" alt=""><![CDATA[ <-----Primary Path--- (S,G) Join [S]---(R1)---(R2)******(R6)-------[R] | | <--- | | | | | | | | | (R5) | | | | | | | | | | | | | | (R3)------(R4) | | | --Secondary Path-- ]]></artwork> </figure> <t> The IP addresses and SIDs involved in the MoFRR calculation are configured as follows:</t><dl newline="true" spacing="normal" indent="0"> <dt>IPv4 Data Plane (MPLS-SR [RFC8660])</dt> <dd/> </dl><t>IPv4 data plane (SR-MPLS <xref target="RFC8660"/>):</t> <artwork name="" type="" align="left" alt=""><![CDATA[ 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-R3IPv6 Data Plane]]></artwork> <t>IPv6 data plane (SRv6[RFC8986])<xref target="RFC8986"/>):</t> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 ]]></artwork> <t> 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.</t> <t> According to the TI-LFA algorithm, the P-space and Q-space are illustrated inFigure 3.<xref target="ure-p-space-and-q-space"/>. The TI-LFA repair path consists of the Node SID of R4 and the Adjacency SID of R4->R3. On theMPLS-SRSegment Routing over MPLS (SR-MPLS) data plane, the repair segment list is (Label-R4, Label-R4-R3). On theSRv6Segment Routing over IPv6 (SRv6) data plane, the repair segment list is (SID-R4, SID-R4-R3).</t> <figure anchor="ure-p-space-and-q-space"> <name>P-Space and Q-Space</name> <artwork name="" type="" align="left" alt=""><![CDATA[ ........ . . [S]---(R1)---(R2)******(R6)---[R] . | . | . | . +++|++++ . | . + | + . | . + (R5) + . | . + | + . | . + | + . | . + | + . (R3)------(R4) + . . + + ........ ++++++++ Q-Space P-Space ]]></artwork> </figure> <t> In the PIM process, the IP addresses associated with the repair segment list are retrieved from the IGPlink-state database.</t>LSDB.</t> <t> 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.</t> <t> 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.</t><dl newline="true" spacing="normal" indent="0"> <dt>Subsequently,<t>Subsequently, R6 installs the secondary UMH using these RPFVectors.</dt> <dd/> </dl>Vectors.</t> <figure anchor="ure-forwarding-pim-join-packet-along-secondary-path-ipv4"> <name>Forwarding PIM Join PacketalongAlong Secondary Path (IPv4)</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +---------+ |Type = 0 | |IP4-R4 | +---------+ +---------+ |Type = 4 | |Type = 4 | |IP4-R3-R4| |IP4-R3-R4| +---------+ +---------+ No RPF Vector R6----->R5---->R4------------>R3----->R2---->R1 ]]></artwork> </figure> <t> On the IPv4 data plane, the forwarding of the PIM Join packet along the secondary path is shown inFigure 4.</t><xref target="ure-forwarding-pim-join-packet-along-secondary-path-ipv4"/>.</t> <t> 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.</t> <t> When R5 receives the packet, it performs a unicast route lookup of the first RPF Vector IP4-R4 and sends the packet to R4.</t> <t> 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.</t> <t> 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.</t> <t> After the PIM Join packet reaches R1, a secondary multicast tree, R1->R2->R3->R4->R5->R6, is establishedhop-by-hophop by hop for (S, G) using MoFRR based on TI-LFA.</t> <figure anchor="ure-forwarding-pim-join-packet-along-secondary-path-ipv6"> <name>Forwarding PIM Join PacketalongAlong Secondary Path (IPv6)</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +---------+ |Type = 0 | |IP6-R4 | +---------+ +---------+ |Type = 4 | |Type = 4 | |IP6-R3-R4| |IP6-R3-R4| +---------+ +---------+ No RPF Vector R6----->R5---->R4------------>R3----->R2---->R1 ]]></artwork> </figure> <t> On the IPv6 data plane, the forwarding of the PIM Join packet along the secondary path is illustrated inFigure 5.<xref target="ure-forwarding-pim-join-packet-along-secondary-path-ipv6"/>. The procedure is analogous to that of the IPv4 data plane.</t> <t> 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 case, only a single RPF Vector needs to be carried, and all other processing steps remain unchanged.</t> </section> <section anchor="sect-5" numbered="true" toc="default"> <name>Management and Operational Considerations</name> <t> The management of the proposed approach is consistent with <xref target="RFC7916" format="default"/>.But,However, in the operation of this approach, the node on the backup Join paths must have an independent configuration strategy for installing RPF Vector Attributes in the PIM Join packet and controlling the sending of this PIM Joinmessages.</t>message.</t> <!--[rfced] For clarity, should "the Join" be updated to "the Join packet"? Original: If the nodes do not understand the RPF Vector attribute in the PIM Join packet, then it must discard the RPF Vector attribute because failing to remove the RPF Vectors could cause upstream nodes to send the Join back toward these nodes causing loops. Perhaps: If the nodes do not understand the RPF Vector Attribute in the PIM Join packet, then they must discard the RPF Vector Attribute because failing to remove the RPF Vectors could cause upstream nodes to send the Join packet back toward these nodes causing loops. --> <t> All nodes on the backup Join paths must be able to parse the PIM Join message with the RPF Vectorattribute.Attribute. If the nodes do not understand the RPF VectorattributeAttribute in the PIM Join packet, then it must discard the RPF VectorattributeAttribute because failing to remove the RPF Vectors could cause upstream nodes to send the Join backtowardtowards these nodes causing loops.</t> <t> If an administrator is manually specifying the path that the Join messages need to be sent on, it is recommended that the administrator computes the path to include nodes that support the Explicit RPF Vector and check that the state is created correctly on each node along the path. Tools likemtraceMtrace <xref target="RFC8487" format="default"/> can be used for debugging and to ensure that the Join state issetupset up correctly.</t> </section> <section anchor="sect-6" numbered="true" toc="default"> <name>IANA Considerations</name> <t> This document has no IANA actions.</t> </section> <section anchor="sect-7" numbered="true" toc="default"> <name>Security Considerations</name> <t> This document does not introduce additional security concerns. It does not change the security properties of PIM. For generalPIM-SMPIM - Sparse Mode (PIM-SM) protocol security considerations, see <xref target="RFC7761" format="default"/>. The security considerations of LFA,R-LFA,RLFA, and MoFRR described in <xref target="RFC5286" format="default"/>, <xref target="RFC7490" format="default"/>, and <xref target="RFC7431" format="default"/> should apply to this document.</t> <t> When deploying TI-LFA, packets may be sent over nodes and links they were not transported through before, potentially raising the following security issues:</t> <ol spacing="normal"type="1"><li>type="1"><li anchor="issue1"> <t>Spoofing andFalse Route Advertisements</t>false route advertisements</t> <ul spacing="normal"> <li> <t>Dependencies ofLFA/R-LFA/TI-LFALFA/RLFA/TI-LFA onRouting Information</t>routing information</t> <ul spacing="normal"> <li> <t>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.</t> </li> <li><t>R-LFA<t>RLFA 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.</t> </li> </ul> </li> </ul> </li><li><li anchor="issue2"> <t>On-pathAttacks</t>attacks</t> <ul spacing="normal"> <li> <t>Use ofAlternate Paths</t>alternate paths</t> <ul spacing="normal"> <li> <t>By rerouting traffic through alternate paths, especially those that traverse multiple hops (as inR-LFARLFA and TI-LFA), the risk ofOn-pathon-path attacks increases if any of the intermediate routers on the alternate pathisare compromised.</t> </li> <li> <t>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.</t> </li> </ul> </li> </ul> </li><li><li anchor="issue3"> <t>Confidentiality andIntegrity</t>integrity</t> <ul spacing="normal"> <li> <t>TrafficEncapsulation</t>encapsulation</t> <ul spacing="normal"> <li><t>R-LFA<t>RLFA 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.</t> </li> </ul> </li> <li> <t>Protection ofExplicit Paths</t>explicit paths</t> <ul spacing="normal"> <li> <t>TI-LFA relies on explicit paths that are typically defined usingsegment routing.SR. If these paths are not properly protected, an attacker could manipulate the segment list to reroute traffic through malicious nodes.</t> </li> </ul> </li> </ul> </li><li><li anchor="issue4"> <t>IncreasedAttack Surface</t>attack surface</t> <ul spacing="normal"> <li> <t>ExtendedTopology</t>topology</t> <ul spacing="normal"> <li> <t>By introducing LFA,R-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.</t> </li> </ul> </li> </ul> </li> </ol> <t> To address security issues#1<xref target="issue1" format="none">1</xref> and#2<xref target="issue2" format="none">2</xref> mentioned above, control plane protocols need to provide security protection. To mitigate the risks associated with false route advertisements andOn-pathon-path attacks, it is recommended to use secure routing protocols (e.g., OSPFv3 with IPsec,ISISIS-IS HMAC-SHA256, or PIM with IPsec) that provide authentication and integrity protection for routing updates.</t> <t> To address security issues#3<xref target="issue3" format="none">3</xref> and#4<xref target="issue4" format="none">4</xref> mentioned above, these mechanisms need to run within a trusted network. The security of LFA,R-LFA,RLFA, and TI-LFA mechanisms heavily relies on the trustworthiness of the underlying routing infrastructure. As the solution described in the document is based onSegment RoutingSR technology, readers should be aware of the security considerations related to this technology(<xref(see <xref target="RFC8402" format="default"/>) and its data plane instantiations(<xref(see <xref target="RFC8660" format="default"/>, <xref target="RFC8754" format="default"/>, and <xref target="RFC8986" format="default"/>).</t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <!-- [RFC9855] draft-ietf-rtgwg-segment-routing-ti-lfa-21 companion doc RFC YYY1 AUTH48 as of 09/05/25 --> <referenceanchor="I-D.ietf-rtgwg-segment-routing-ti-lfa" target="https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-21" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-segment-routing-ti-lfa.xml">anchor="RFC9855" target="https://www.rfc-editor.org/info/rfc9855"> <front> <title>Topology Independent Fast RerouteusingUsing Segment Routing</title> <authorfullname="Ahmed Bashandy"initials="A."surname="Bashandy">surname="Bashandy" fullname="Ahmed Bashandy"> <organization>Individual</organization> </author> <authorfullname="Stephane Litkowski"initials="S."surname="Litkowski">surname="Litkowski" fullname="Stephane Litkowski"> <organization>Cisco Systems</organization> </author> <authorfullname="Clarence Filsfils"initials="C."surname="Filsfils">surname="Filsfils" fullname="Clarence Filsfils"> <organization>Cisco Systems</organization> </author> <authorfullname="Pierre Francois"initials="P."surname="Francois">surname="Francois" fullname="Pierre Francois"> <organization>INSA Lyon</organization> </author> <authorfullname="Bruno Decraene"initials="B."surname="Decraene">surname="Decraene" fullname="Bruno Decraene"> <organization>Orange</organization> </author> <authorfullname="Daniel Voyer"initials="D."surname="Voyer">surname="Voyer" fullname="Daniel Voyer"> <organization>Bell Canada</organization> </author> <dateday="12" month="February" year="2025"/> <abstract> <t>This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options.</t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-segment-routing-ti-lfa-21"/> </reference> <reference anchor="RFC5286" target="https://www.rfc-editor.org/info/rfc5286" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"> <front> <title>Basic Specification for IP Fast Reroute: Loop-Free Alternates</title> <author fullname="A. Atlas" initials="A." role="editor" surname="Atlas"/> <author fullname="A. Zinin" initials="A." role="editor" surname="Zinin"/> <datemonth="September"year="2008"/> <abstract> <t>This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5286"/> <seriesInfo name="DOI" value="10.17487/RFC5286"/> </reference> <reference anchor="RFC5384" target="https://www.rfc-editor.org/info/rfc5384" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5384.xml"> <front> <title>The Protocol Independent Multicast (PIM) Join Attribute Format</title> <author fullname="A. Boers" initials="A." surname="Boers"/> <author fullname="I. Wijnands" initials="I." surname="Wijnands"/> <author fullname="E. Rosen" initials="E." surname="Rosen"/> <date month="November" year="2008"/> <abstract> <t>A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format. [STANDARDS-TRACK]</t> </abstract>year="2025"/> </front> <seriesInfo name="RFC"value="5384"/>value="9855"/> <seriesInfo name="DOI"value="10.17487/RFC5384"/>value="10.17487/RFC9855"/> </reference><reference anchor="RFC5496" target="https://www.rfc-editor.org/info/rfc5496" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5496.xml"> <front> <title>The Reverse Path Forwarding (RPF) Vector TLV</title> <author fullname="IJ. Wijnands" initials="IJ." surname="Wijnands"/> <author fullname="A. Boers" initials="A." surname="Boers"/> <author fullname="E. Rosen" initials="E." surname="Rosen"/> <date month="March" year="2009"/> <abstract> <t>This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5384.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5496.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7431.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7490.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7891.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7916.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5715.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8102.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8487.xml"/> </references> </references> <section numbered="false" anchor="contributors" toc="default"> <name>Contributors</name> <contact fullname="Mengxiao Chen"> <organization>New H3C Technologies</organization> <address> <postal> <country>China</country> </postal> <email>chen.mengxiao@h3c.com</email> </address> </contact> </section> </back> </rfc> <!-- [rfced] To avoid using an RFC5384, which enables PIM to build multicast trees throughas anMPLS-enabled network, even if that network's IGP does not have a route toadjective, may we update thesourceinstances ofthe tree. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5496"/> <seriesInfo name="DOI" value="10.17487/RFC5496"/> </reference> <reference anchor="RFC7431" target="https://www.rfc-editor.org/info/rfc7431" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7431.xml"> <front> <title>Multicast-Only Fast Reroute</title> <author fullname="A. Karan" initials="A." surname="Karan"/> <author fullname="C. Filsfils" initials="C." surname="Filsfils"/> <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/> <author fullname="B. Decraene" initials="B." surname="Decraene"/> <date month="August" year="2015"/> <abstract> <t>As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults"[RFC7431] MoFRR" in theIP network carrying the packets for these services. This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to multicast routing protocols suchtext below asProtocol Independent Multicast (PIM) and Multipoint LDP (mLDP).</t> </abstract> </front> <seriesInfo name="RFC" value="7431"/> <seriesInfo name="DOI" value="10.17487/RFC7431"/> </reference> <reference anchor="RFC7490" target="https://www.rfc-editor.org/info/rfc7490" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7490.xml"> <front> <title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title> <author fullname="S. Bryant" initials="S." surname="Bryant"/> <author fullname="C. Filsfils" initials="C." surname="Filsfils"/> <author fullname="S. Previdi" initials="S." surname="Previdi"/> <author fullname="M. Shand" initials="M." surname="Shand"/> <author fullname="N. So" initials="N." surname="So"/> <date month="April" year="2015"/> <abstract> <t>This document describes an extension tofollows? Original: However, thebasic IP fast reroute[RFC7431] MoFRR mechanism,described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided bywhich selects thebasic mechanisms.</t> </abstract> </front> <seriesInfo name="RFC" value="7490"/> <seriesInfo name="DOI" value="10.17487/RFC7490"/> </reference> <reference anchor="RFC7761" target="https://www.rfc-editor.org/info/rfc7761" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"> <front> <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title> <author fullname="B. Fenner" initials="B." surname="Fenner"/> <author fullname="M. Handley" initials="M." surname="Handley"/> <author fullname="H. Holbrook" initials="H." surname="Holbrook"/> <author fullname="I. Kouvelas" initials="I." surname="Kouvelas"/> <author fullname="R. Parekh" initials="R." surname="Parekh"/> <author fullname="Z. Zhang" initials="Z." surname="Zhang"/> <author fullname="L. Zheng" initials="L." surname="Zheng"/> <date month="March" year="2016"/> <abstract> <t>This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is asecondary multicastrouting protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.</t> <t>This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and movesnext-hop based solely on thePIM specification to Internet Standard.</t> </abstract> </front> <seriesInfo name="STD" value="83"/> <seriesInfo name="RFC" value="7761"/> <seriesInfo name="DOI" value="10.17487/RFC7761"/> </reference> <reference anchor="RFC7891" target="https://www.rfc-editor.org/info/rfc7891" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7891.xml"> <front> <title>Explicit Reverse Path Forwarding (RPF) Vector</title> <author fullname="J. Asghar" initials="J." surname="Asghar"/> <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/> <author fullname="S. Krishnaswamy" initials="S." surname="Krishnaswamy"/> <author fullname="A. Karan" initials="A." surname="Karan"/> <author fullname="V. Arya" initials="V." surname="Arya"/> <date month="June" year="2016"/> <abstract> <t>The PIM Reverse Path Forwarding (RPF) Vector TLVloop-free alternate fast reroute defined inRFC 5496 can be included[RFC7431], has limitations ina PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the source or Rendezvous Point associated with thecertain multicasttree.</t> <t>This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, thus bypassingdeployment scenarios (see Section 2). ... Consequently, theunicast route lookup.</t> </abstract> </front> <seriesInfo name="RFC" value="7891"/> <seriesInfo name="DOI" value="10.17487/RFC7891"/> </reference> <reference anchor="RFC7916" target="https://www.rfc-editor.org/info/rfc7916" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7916.xml"> <front> <title>Operational Management of Loop-Free Alternates</title> <author fullname="S. Litkowski" initials="S." role="editor" surname="Litkowski"/> <author fullname="B. Decraene" initials="B." surname="Decraene"/> <author fullname="C. Filsfils" initials="C." surname="Filsfils"/> <author fullname="K. Raza" initials="K." surname="Raza"/> <author fullname="M. Horneffer" initials="M." surname="Horneffer"/> <author fullname="P. Sarkar" initials="P." surname="Sarkar"/> <date month="July" year="2016"/> <abstract> <t>Loop-Free Alternates (LFAs), as defined[RFC7431] MoFRR functionality inRFC 5286, constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.</t> <t>This proposalPIM isalsoapplicableto remote-LFA solutions.</t> </abstract> </front> <seriesInfo name="RFC" value="7916"/> <seriesInfo name="DOI" value="10.17487/RFC7916"/> </reference> <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"> <front> <title>Segment Routing Architecture</title> <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/> <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/> <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/> <author fullname="B. Decraene" initials="B." surname="Decraene"/> <author fullname="S. Litkowski" initials="S." surname="Litkowski"/> <author fullname="R. Shakir" initials="R." surname="Shakir"/> <date month="July" year="2018"/> <abstract> <t>Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow stateonlyat the ingress node(s) to the SR domain.</t> <t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segmentsin network topologies where LFA isencoded as a stack of labels.feasible. ... Thesegment to process is on the top of the stack. Upon completionlimitations ofa segment, the related label is popped fromthestack.</t> <t>SR[RFC7431] MoFRR applicability can beapplied toillustrated using theIPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addressesexample network depicted in Figure 1. ... In this scenario, therouting header. The active segment is indicated by[RFC7431] MoFRR operates effectively. ... In this case, theDestination Address (DA) of[RFC7431] MoFRR cannot calculate a secondary UMH. Similarly, for multicast source S3 and receiver R, thepacket. The next active segment[RFC7431] MoFRR mechanism isindicated by a pointerineffective. ... For instance, in thenew routing header.</t> </abstract> </front> <seriesInfo name="RFC" value="8402"/> <seriesInfo name="DOI" value="10.17487/RFC8402"/> </reference> <reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"> <front> <title>Segment Routing withnetwork illustrated in Figure 1, theMPLS Data Plane</title> <author fullname="A. Bashandy" initials="A." role="editor" surname="Bashandy"/> <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/> <author fullname="S. Previdi" initials="S." surname="Previdi"/> <author fullname="B. Decraene" initials="B." surname="Decraene"/> <author fullname="S. Litkowski" initials="S." surname="Litkowski"/> <author fullname="R. Shakir" initials="R." surname="Shakir"/> <date month="December" year="2019"/> <abstract> <t>Segment Routing (SR) leveragessecondary path for thesource-routing paradigm. A node steers aPIM Join packetthrough a controlled set of instructions, called segments,towards multicast source S2 cannot be computed byprepending[RFC7431] MoFRR, as previously described. Perhaps: However, thepacket with an SR header. InMoFRR mechanism [RFC7431], which selects theMPLS data plane,secondary... ... Consequently, theSR headerMoFRR functionality [RFC7431] in PIM isinstantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR overapplicable... ... The limitations of theMPLS data plane (SR-MPLS).</t> </abstract> </front> <seriesInfo name="RFC" value="8660"/> <seriesInfo name="DOI" value="10.17487/RFC8660"/> </reference> <reference anchor="RFC8754" target="https://www.rfc-editor.org/info/rfc8754" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"> <front> <title>IPv6 Segment Routing Header (SRH)</title> <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/> <author fullname="D. Dukes" initials="D." role="editor" surname="Dukes"/> <author fullname="S. Previdi" initials="S." surname="Previdi"/> <author fullname="J. Leddy" initials="J." surname="Leddy"/> <author fullname="S. Matsushima" initials="S." surname="Matsushima"/> <author fullname="D. Voyer" initials="D." surname="Voyer"/> <date month="March" year="2020"/> <abstract> <t>Segment RoutingMoFRR applicability [RFC7431] can beapplied to the IPv6 data plane usingillustrated... ... In this scenario, MoFRR [RFC7431] operates effectively. ... In this case, MoFRR [RFC7431] cannot calculate anew type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRHsecondary UMH. Similarly, for multicast source S3 andhow it is used by nodes that are Segment Routing (SR) capable.</t> </abstract> </front> <seriesInfo name="RFC" value="8754"/> <seriesInfo name="DOI" value="10.17487/RFC8754"/> </reference> <reference anchor="RFC8986" target="https://www.rfc-editor.org/info/rfc8986" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"> <front> <title>Segment Routing over IPv6 (SRv6) Network Programming</title> <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/> <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/> <author fullname="J. Leddy" initials="J." surname="Leddy"/> <author fullname="D. Voyer" initials="D." surname="Voyer"/> <author fullname="S. Matsushima" initials="S." surname="Matsushima"/> <author fullname="Z. Li" initials="Z." surname="Li"/> <date month="February" year="2021"/> <abstract> <t>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions inreceiver R, theIPv6 packet header.</t> <t>Each instructionMoFRR mechanism [RFC7431] isimplemented on one or several nodesineffective. ... For instance, in the networkand identified by an SRv6 Segment Identifierillustrated in Figure 1, thepacket.</t> <t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t> </abstract> </front> <seriesInfo name="RFC" value="8986"/> <seriesInfo name="DOI" value="10.17487/RFC8986"/> </reference> </references> <references> <name>Informative References</name> <reference anchor="RFC5715" target="https://www.rfc-editor.org/info/rfc5715" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5715.xml"> <front> <title>A Frameworksecondary path forLoop-Free Convergence</title> <author fullname="M. Shand" initials="M." surname="Shand"/> <author fullname="S. Bryant" initials="S." surname="Bryant"/> <date month="January" year="2010"/> <abstract> <t>A micro-loop is athe PIM Join packetforwarding looptowards multicast source S2 cannot be computed by MoFRR [RFC7431], as previously described. --> <!-- [rfced] We note thatmay occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.</t> <t>This framework provides a summary ofthecauses and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needsfollowing terminology appears to beaddressed in specific networks. It also provides a survey ofused inconsistently throughout thecurrently proposed mechanisms thatdocument. Please review these occurrences and let us know if/how they may beused to prevent or to suppress the formationmade consistent. Node SID vs. NodeSID Segment List vs. segment list --> <!-- [rfced] FYI - We have added expansions for abbreviations upon first use per Section 3.6 ofmicro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available andRFC 7322 ("RFC Style Guide"). Please review each expansion in thetopology is susceptibledocument carefully tomicro-loops, useensure correctness. Reverse Path Forwarding (RPF) Remote LFA (RLFA) PIM - Sparse Mode (PIM-SM) --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates ofone orthis nature typically result in moreof these mechanisms may be desirable. This document is not an Internet Standards Track specification; itprecise language, which ispublishedhelpful forinformational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="5715"/> <seriesInfo name="DOI" value="10.17487/RFC5715"/> </reference> <reference anchor="RFC8102" target="https://www.rfc-editor.org/info/rfc8102" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8102.xml"> <front> <title>Remote-LFA Node Protection and Manageability</title> <author fullname="P. Sarkar" initials="P." role="editor" surname="Sarkar"/> <author fullname="S. Hegde" initials="S." surname="Hegde"/> <author fullname="C. Bowers" initials="C." surname="Bowers"/> <author fullname="H. Gredler" initials="H." surname="Gredler"/> <author fullname="S. Litkowski" initials="S." surname="Litkowski"/> <date month="March" year="2017"/> <abstract> <t>The loop-free alternates (LFAs) computed followingreaders. a) For example, please consider whether "native" should be updated in thecurrent remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called "PQ-nodes") may not guarantee node protection for all destinations being protected by it.</t> <t>This document describes an extensiontext below: This mechanism is applicable tothe remote-loop-free-basedPIM networks, including cases where PIM operates natively over IPfast reroute mechanisms that specifies procedures for determiningin Segment Routing (SR) networks. b) In addition, please consider whetheror not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can"tradition" should beutilizedupdated for clarity. While thecollection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate pathsNIST website <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is aprecursor to applyingsubjective term, as it is not theoperator-defined policysame foreliminating paths not fittingeveryone: However, theconstraints.</t> </abstract> </front> <seriesInfo name="RFC" value="8102"/> <seriesInfo name="DOI" value="10.17487/RFC8102"/> </reference> <reference anchor="RFC8487" target="https://www.rfc-editor.org/info/rfc8487" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8487.xml"> <front> <title>Mtrace Version 2: Traceroute Facilitytraditional LFA does not function properly forIP Multicast</title> <author fullname="H. Asaeda" initials="H." surname="Asaeda"/> <author fullname="K. Meyer" initials="K." surname="Meyer"/> <author fullname="W. Lee" initials="W." role="editor" surname="Lee"/> <date month="October" year="2018"/> <abstract> <t>This document describestheIP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations onsecondary path because thepart of routers.</t> <t>This specification describesshortest path to R2 from R5 (or from R4) still traverses therequired functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply.</t> </abstract> </front> <seriesInfo name="RFC" value="8487"/> <seriesInfo name="DOI" value="10.17487/RFC8487"/> </reference> </references> </references> <section numbered="false" anchor="contributors" toc="default"> <name>Contributors</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Mengxiao Chen New H3C Technologies China Email: chen.mengxiao@h3c.com ]]></artwork> </section> </back> </rfc>R6-R2 link. -->