rfc9860.original.xml   rfc9860.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
raft-ietf-pim-mofrr-tilfa-14" category="info" ipr="trust200902" obsoletes="" upd <!-- pre-edited by ST 04/25/25 -->
ates="" xml:lang="en" symRefs="true" sortRefs="false" tocInclude="true" version= <!-- formatted by ST 05/01/25 -->
"3"> <!-- reference review by TH 05/12/25 -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<!-- [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="d
raft-ietf-pim-mofrr-tilfa-14" number="9860" consensus="true" category="info" ipr
="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="fa
lse" tocInclude="true" version="3">
<front> <front>
<title abbrev="MoFRR based on TILFA">Multicast-only Fast Reroute Based on To <title abbrev="MoFRR Based on TI-LFA">Multicast-Only Fast Reroute (MoFRR) Ba
pology Independent Loop-free Alternate (TI-LFA) Fast Reroute</title> sed on
<seriesInfo name="Internet-Draft" value="draft-ietf-pim-mofrr-tilfa-14"/> Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute</title>
<seriesInfo name="RFC" value="9860"/>
<author initials="Y." surname="Liu" fullname="Yisong Liu"> <author initials="Y." surname="Liu" fullname="Yisong Liu">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal> <postal>
<street>China</street> <country>China</country>
</postal> </postal>
<email>liuyisong@chinamobile.com</email> <email>liuyisong@chinamobile.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="McBride" fullname="Mike McBride"> <author initials="M." surname="McBride" fullname="Mike McBride">
<organization abbrev="Futurewei">Futurewei Inc.</organization> <organization abbrev="Futurewei">Futurewei Inc.</organization>
<address> <address>
<postal> <postal>
<street>USA</street> <country>United States of America</country>
</postal> </postal>
<email>michael.mcbride@futurewei.com</email> <email>michael.mcbride@futurewei.com</email>
</address> </address>
</author> </author>
<author initials="Z." surname="Zhang" fullname="Zheng(Sandy) Zhang"> <author initials="Z." surname="Zhang" fullname="Zheng(Sandy) Zhang">
<organization abbrev="ZTE">ZTE Corporation</organization> <organization abbrev="ZTE">ZTE Corporation</organization>
<address> <address>
<postal> <postal>
<street>China</street> <country>China</country>
</postal> </postal>
<email>zzhang_ietf@hotmail.com</email> <email>zzhang_ietf@hotmail.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Xie" fullname="Jingrong Xie"> <author initials="J." surname="Xie" fullname="Jingrong Xie">
<organization abbrev="Huawei">Huawei Technologies</organization> <organization abbrev="Huawei">Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>China</street> <country>China</country>
</postal> </postal>
<email>xiejingrong@huawei.com</email> <email>xiejingrong@huawei.com</email>
</address> </address>
</author> </author>
<author initials="C." surname="Lin" fullname="Changwang Lin"> <author initials="C." surname="Lin" fullname="Changwang Lin">
<organization>New H3C Technologies</organization> <organization>New H3C Technologies</organization>
<address> <address>
<postal> <postal>
<street>China</street> <country>China</country>
</postal> </postal>
<email>linchangwang.04414@h3c.com</email> <email>linchangwang.04414@h3c.com</email>
</address> </address>
</author> </author>
<date year="2025" month="April" day="7"/> <date year="2025" month="September"/>
<workgroup>PIM Working Group</workgroup> <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> <abstract>
<t> <t>
This document specifies the use of Topology Independent Loop-Free This document specifies the use of Topology Independent Loop-Free
Alternate (TI-LFA) mechanisms with Multicast Only Fast ReRoute Alternate (TI-LFA) mechanisms with Multicast-only Fast Reroute
(MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA (MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA
provides fast reroute protection for unicast traffic in IP networks provides Fast Reroute (FRR) protection for unicast traffic in IP networks
by precomputing backup paths that avoid potential failures. By by precomputing backup paths that avoid potential failures. By
integrating TI-LFA with MoFRR, this document extends the benefits of integrating TI-LFA with MoFRR, this document extends the benefits of FRR
fast reroute mechanisms to multicast traffic, enabling enhanced mechanisms to multicast traffic, enabling enhanced
resilience and minimized packet loss in multicast networks. The resilience and minimized packet loss in multicast networks. The
document outlines an optional approach to implement TI-LFA in document outlines an optional approach to implement TI-LFA in
conjunction with MoFRR for PIM, ensuring that multicast traffic is conjunction with MoFRR for PIM, ensuring that multicast traffic is
rapidly rerouted in the event of a failure.</t> rapidly rerouted in the event of a failure.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" numbered="true" toc="default"> <section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
Multicast-only Fast Reroute (MoFRR), as defined in <xref target="RFC7431" for Multicast-only Fast Reroute (MoFRR), as defined in <xref target="RFC7431"
mat="default"/>, offers format="default"/>, offers a mechanism to reduce multicast packet loss in
a mechanism to reduce multicast packet loss in the event of node or the event of node or link failures by introducing simple enhancements to
link failures by introducing simple enhancements to multicast multicast routing protocols, such as Protocol Independent Multicast (PIM)
routing protocols, such as Protocol Independent Multicast (PIM) <xref target="RFC7761" format="default"/>. However, the <xref
<xref target="RFC7761" format="default"/>. However, the <xref target="RFC7431 target="RFC7431" format="default"/> MoFRR mechanism, which selects the
" format="default"/> MoFRR mechanism, which selects the secondary multicast next hop based solely on the Loop-Free Alternate (LFA)
secondary multicast next-hop based solely on the loop-free alternate FRR defined in <xref target="RFC7431" format="default"/>, has limitations
fast reroute defined in <xref target="RFC7431" format="default"/>, has limita in certain multicast deployment scenarios (see <xref target="sect-2"
tions in certain format="default"/>).</t>
multicast deployment scenarios (see <xref target="sect-2" format="default"/>)
.</t>
<t> <t>
This document introduces a new mechanism for MoFRR using Topology This document introduces a new mechanism for MoFRR using FRR for Topology
Independent Loop-Free Alternate (TI-LFA) <xref target="I-D.ietf-rtgwg-segment Independent Loop-Free Alternate (TI-LFA) <xref target="RFC9855" format="defau
-routing-ti-lfa" format="default"/> fast reroute. lt"/>.
Unlike conventional methods, TI-LFA is independent of network Unlike conventional methods, TI-LFA is independent of network
topology, enabling broader coverage across diverse network topology, enabling broader coverage across diverse network
environments. This mechanism is applicable to PIM networks,including environments. This mechanism is applicable to PIM networks, including
cases where PIM operates natively over IP in Segment Routing (SR) cases where PIM operates natively over IP in Segment Routing (SR)
networks.</t> networks.</t>
<t> <t>
The TI-LFA mechanism is designed for standard link-state Interior The TI-LFA mechanism is designed for standard link-state Interior
Gateway Protocol (IGP) shortest path and SR scenarios. For each Gateway Protocol (IGP) shortest path and SR scenarios. For each
destination advertised by the IGP in a network, TI-LFA pre-installs destination advertised by the IGP in a network, TI-LFA pre-installs
a backup forwarding entry for the protected destination, ready to be 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 activated upon the detection of a link failure used to reach that
destination. This document leverages the backup path computed by TI- destination. This document leverages the backup path computed by TI-LFA
LFA through the IGP as a secondary Upstream Multicast Hop (UMH) for 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 PIM. By sending PIM secondary Join messages hop by hop on the TI-LFA
backup path, a fast reroute backup path can be created for PIM backup path, a FRR backup path can be created for PIM
multicast.</t> multicast.</t>
<t> <t>
The techniques described in this document are limited to protecting The techniques described in this document are limited to protecting
links and nodes within a link-state IGP area. Protecting domain exit links and nodes within a link-state IGP area. Protecting domain exit
routers and/or links attached to other routing domains is beyond the routers and/or links attached to other routing domains is beyond the
scope of this document. All the Segment Identifiers (SIDs) required scope of this document. All the Segment Identifiers (SIDs) required
are contained within the Link State Database (LSDB) of the IGP.</t> are contained within the Link State Database (LSDB) of the IGP.</t>
<t> <t>
The approach does not alter the existing management and operation of The approach does not alter the existing management and operation of
LFA, RLFA, and TI-LFA <xref target="RFC7916" format="default"/> <xref target= "RFC8102" format="default"/> <xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa " format="default"/>. Additionally, LFA, TI-LFA, and Remote LFA (RLFA) <xref target="RFC7916" format="default"/> <xref target="RFC8102" format="default"/> <xref target="RFC9855" format="defaul t"/>. Additionally,
during post-failure reconvergence, micro-loops <xref target="RFC5715" format= "default"/> may form during post-failure reconvergence, micro-loops <xref target="RFC5715" format= "default"/> may form
due to transient forwarding inconsistencies across routers. PIM due to transient forwarding inconsistencies across routers. PIM
micro-loop prevention is out of scope for this document.</t> micro-loop prevention is out of scope for this document.</t>
<t> <t>
Note that this document introduces an optional approach for backup Note that this document introduces an optional approach for backup
Join paths, designed to enhance the protection scope of existing Join paths, designed to enhance the protection scope of existing
multicast systems. It is fully compatible with current protocol multicast systems. It is fully compatible with current protocol
implementations and does not necessitate any changes to the implementations and does not necessitate any changes to the
protocols or forwarding functions on intermediate nodes. All nodes protocols or forwarding functions on intermediate nodes. All nodes
along the backup Join paths must support the RPF Vector attribute as along the backup Join paths must support the Reverse Path Forwarding (RPF) Ve ctor Attribute as
defined in <xref target="RFC5496" format="default"/> and <xref target="RFC789 1" format="default"/>. If there is a choice between defined in <xref target="RFC5496" format="default"/> and <xref target="RFC789 1" format="default"/>. If there is a choice between
vector and non-vector Join messages on the intermediate nodes, the vector and non-vector Join messages on the intermediate nodes, the
non-vector option should be prioritized, which implies that non-vector option should be prioritized, which implies that
protection paths will remain inactive. This document does not modify protection paths will remain inactive. This document does not modify
the handling of conflicts in PIM Join messages. For guidance on the handling of conflicts in PIM Join messages. For guidance on
conflicts in Join attributes, please refer to Section 3.3.3 of conflicts in Join attributes, please refer to
<xref target="RFC5384" format="default"/>.</t> <xref target="RFC5384" section="3.3.3"/>.</t>
<section anchor="sect-1.1" numbered="true" toc="default"> <section anchor="sect-1.1" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t> <t>
This document utilizes the terminology as defined in <xref target="RFC7431" f ormat="default"/> and This document utilizes the terminology as defined in <xref target="RFC7431" f ormat="default"/> and
incorporates the concepts established in <xref target="RFC7490" format="defau lt"/>. The definitions incorporates the concepts established in <xref target="RFC7490" format="defau lt"/>. The definitions
of individual terms are not reiterated within this document.</t> of individual terms are not reiterated within this document.</t>
</section> </section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default"> <section anchor="sect-2" numbered="true" toc="default">
<name>Problem Statement</name> <name>Problem Statement</name>
<section anchor="sect-2.1" numbered="true" toc="default"> <section anchor="sect-2.1" numbered="true" toc="default">
<name>LFA for MoFRR</name> <name>LFA for MoFRR</name>
<t> <t>
Section 3 of <xref target="RFC7431" format="default"/> specifies that a secon <xref target="RFC7431" section="3"/> specifies that a secondary UMH in PIM
dary UMH in PIM for for MoFRR is a Loop-Free Alternate (LFA). However, the conventional LFA
MoFRR is a Loop-Free Alternate (LFA). However, the conventional LFA mechanism requires that at least one neighbor's next hop to the destination
mechanism requires that at least one neighbor's next-hop to the node is a loop-free next hop. Due to existing limitations of the LFA
destination node is a loop-free next-hop. Due to existing mechanism in network deployments, such as topology dependency and
limitations of the LFA mechanism in network deployments, such as incomplete destination coverage, the LFA mechanism can only be deployed in
topology dependency and incomplete destination coverage, the LFA certain network topology environments. In specific network topologies, the
mechanism can only be deployed in certain network topology secondary UMH cannot be computed in PIM for MoFRR, preventing PIM from
environments. In specific network topologies, the secondary UMH establishing a standby multicast tree, and thus preventing the
cannot be computed in PIM for MoFRR, preventing PIM from implementation of MoFRR protection. Consequently, the <xref target="RFC7431"
establishing a standby multicast tree and thus from implementing format="default"/> MoFRR functionality
MoFRR protection. Consequently, the <xref target="RFC7431" format="default"/> in PIM is applicable only in network topologies where LFA is feasible.</t>
MoFRR functionality in
PIM is applicable only in network topologies where LFA is feasible.</t>
<t> <t>
The limitations of the <xref target="RFC7431" format="default"/> MoFRR applic ability can be The limitations of the <xref target="RFC7431" format="default"/> MoFRR applic ability can be
illustrated using the example network depicted in Figure 1. In this illustrated using the example network depicted in <xref target="ure-example-n etwork-topology"/>. In this
example, the metric of the R1-R4 link is 20, the metric of the R5-R6 example, the metric of the R1-R4 link is 20, the metric of the R5-R6
link is 100, and the metrics of the other links are 10. All link link is 100, and the metrics of the other links are 10. All link
metrics are bidirectional.</t> metrics are bidirectional.</t>
<t> <t>
For multicast source S1 and receiver R, the primary path of the PIM For multicast source S1 and receiver R, the primary path of the PIM
Join packet is R3-&gt;R2-&gt;R1, and the secondary path is R3-&gt;R4-&gt;R1, Join packet is R3-&gt;R2-&gt;R1, and the secondary path is R3-&gt;R4-&gt;R1,
which corresponds to the LFA path of unicast routing. In this which corresponds to the LFA path of unicast routing. In this
scenario, the <xref target="RFC7431" format="default"/> MoFRR operates effect ively.</t> scenario, the <xref target="RFC7431" format="default"/> MoFRR operates effect ively.</t>
<t> <t>
For multicast source S2 and receiver R, the primary path of the PIM For multicast source S2 and receiver R, the primary path of the PIM
skipping to change at line 197 skipping to change at line 222
</section> </section>
<section anchor="sect-2.2" numbered="true" toc="default"> <section anchor="sect-2.2" numbered="true" toc="default">
<name>TI-LFA for MoFRR</name> <name>TI-LFA for MoFRR</name>
<t> <t>
The alternate path provided by the TI-LFA mechanism is represented The alternate path provided by the TI-LFA mechanism is represented
as a Segment List, which includes the NodeSID of the P-space node 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 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 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> Segment List requires only the PQ node's NodeSID.</t>
<t> <t>
PIM can look up the corresponding node IP address in the unicast PIM can look up the corresponding node's IP address in the unicast
route base according to the NodeSID and the IP addresses of the route base according to the NodeSID and the IP addresses of the
endpoints of the corresponding link in the unicast route base endpoints of the corresponding link in the unicast route base
according to the Adjacency SIDs. However, multicast protocol packets according to the Adjacency SIDs. However, multicast protocol packets
cannot be directly forwarded along the path of the Segment List.</t> cannot be directly forwarded along the path of the Segment List.</t>
<t> <t>
To establish a standby multicast tree, PIM Join messages need to be To establish a standby multicast tree, PIM Join messages need to be
transmitted hop-by-hop. However, not all nodes and links on the transmitted hop by hop. However, not all nodes and links on the unicast
unicast alternate path are included in the Segment List. If PIM alternate path are included in the Segment List. If PIM protocol packets
protocol packets are transmitted solely in unicast mode, they are transmitted solely in unicast mode, they effectively traverse the
effectively traverse the unicast tunnel like unicast traffic and do unicast tunnel like unicast traffic and do not pass through the
not pass through the intermediate nodes of the tunnel. Consequently, intermediate nodes of the tunnel. Consequently, the intermediate nodes on
the intermediate nodes on the alternate path cannot forward the alternate path cannot forward multicast traffic because they lack PIM
multicast traffic because they lack PIM state entries. PIM must state entries. PIM must create entries on each device hop by hop,
create entries on each device hop-by-hop, generating an incoming generating an incoming interface and an outgoing interface list, to form a
interface and an outgoing interface list, to form a complete end-to- complete end-to-end multicast tree for forwarding multicast
end multicast tree for forwarding multicast traffic. Therefore, traffic. Therefore, simply sending PIM Join packets using the Segment List,
simply sending PIM Join packets using the Segment List, as done with as done with unicast traffic, is insufficient to establish a standby
unicast traffic, is insufficient to establish a standby multicast multicast tree.</t>
tree.</t>
</section> </section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default"> <section anchor="sect-3" numbered="true" toc="default">
<name>A Solution</name> <name>A Solution</name>
<section anchor="sect-3.1" numbered="true" toc="default"> <section anchor="sect-3.1" numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t> <t>
A secondary UMH serves as a candidate next-hop that can be used to A secondary UMH serves as a candidate next hop that can be used to
reach the root of a multicast tree. In this document, the secondary reach the root of a multicast tree. In this document, the secondary
UMH is derived from unicast routing, utilizing the Segment List UMH is derived from unicast routing, utilizing the Segment List
computed by TI-LFA.</t> computed by TI-LFA.</t>
<t> <t>
The path information from the Segment List is incorporated into the The path information from the Segment List is incorporated into the
PIM packets to guide hop-by-hop RPF selection. The IP address PIM packets to guide hop-by-hop RPF selection. The IP address
corresponding to the Node SID can be used as the segmented root corresponding to the Node SID can be used as the segmented root
node, while the IP addresses of the interfaces at both endpoints of 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 the link associated with the Adjacency SID can be used as the local
upstream interface and upstream neighbor.</t> upstream interface and upstream neighbor.</t>
<t> <t>
<xref target="RFC5496" format="default"/> defines the PIM RPF Vector attribut e, which can carry the <xref target="RFC5496" format="default"/> defines the PIM RPF Vector Attribut e, which can carry the
node's IP address corresponding to the Node SID. Additionally, node's IP address corresponding to the Node SID. Additionally,
<xref target="RFC7891" format="default"/> defines the explicit RPF Vector, wh ich can carry the <xref target="RFC7891" format="default"/> defines the Explicit RPF Vector, wh ich can carry the
peer's IP address corresponding to the Adjacency SID.</t> peer's IP address corresponding to the Adjacency SID.</t>
<t> <t>
For instance, in the network illustrated in Figure 1, the secondary For instance, in the network illustrated in <xref
path for the PIM Join packet towards multicast source S2 cannot be target="ure-example-network-topology"/>, the secondary path for the PIM
computed by <xref target="RFC7431" format="default"/> MoFRR, as previously de Join packet towards multicast source S2 cannot be computed by <xref
scribed. Using TI-LFA, target="RFC7431" format="default"/> MoFRR, as previously described. Using
R3 sends the packet to R4 while including an RPF Vector that 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 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 the R1- protected R3-R2 link. R4 then forwards the packet to R1 via the R1-R4 link
R4 link according to the unicast route associated with the RPF according to the unicast route associated with the RPF Vector. R1
Vector. R1 subsequently forwards the packet to R2, thus establishing subsequently forwards the packet to R2, thus establishing the secondary
the secondary path R3-&gt;R4-&gt;R1-&gt;R2.</t> path R3-&gt;R4-&gt;R1-&gt;R2.</t>
<t> <t>
Additionally, for multicast source S3 and receiver R, the primary Additionally, for multicast source S3 and receiver R, the primary
path of the PIM Join packet is R3-&gt;R2-&gt;R5. Using TI-LFA, R3 sends path of the PIM Join packet is R3-&gt;R2-&gt;R5. Using TI-LFA, R3 sends
the PIM Join packet to R7 while including two RPF Vectors:</t> the PIM Join packet to R7 while including two RPF Vectors:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The first RPF Vector contains the IP address of R6, which serves <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> as R3's P-node for the protected R3-R2 link.</t>
</li> </li>
<li> <li>
skipping to change at line 282 skipping to change at line 307
calculated by TI-LFA, thereby providing comprehensive MoFRR calculated by TI-LFA, thereby providing comprehensive MoFRR
protection for multicast services across diverse network protection for multicast services across diverse network
environments.</t> environments.</t>
</section> </section>
<section anchor="sect-3.2" numbered="true" toc="default"> <section anchor="sect-3.2" numbered="true" toc="default">
<name>Procedure</name> <name>Procedure</name>
<t> <t>
Consider a Segment List calculated by TI-LFA as (NodeSID(A), Consider a Segment List calculated by TI-LFA as (NodeSID(A),
AdjSID(A-B)). Node A belongs to the P-space, and node B belongs to AdjSID(A-B)). Node A belongs to the P-space, and node B belongs to
the Q-space. The IP address corresponding to NodeSID(A) can be the Q-space. The IP address corresponding to NodeSID(A) can be
retrieved from the local link-state database of the IGP and assumed retrieved from the local LSDB of the IGP and assumed
to be IP-a. Similarly, the IP addresses of the two endpoints of the 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 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.</t> local LSDB and assumed to be IP-La and IP-Lb.</t>
<t> <t>
Within the PIM process, IP-a is treated as the standard RPF Vector Within the PIM process, IP-a is treated as the standard RPF Vector
Attribute and added to the PIM Join packet. IP-La is considered the Attribute and added to the PIM Join packet. IP-La is considered the
local address of the incoming interface, and IP-Lb is regarded as local address of the incoming interface, and IP-Lb is regarded as
the address of the upstream neighbor. Consequently, IP-Lb can be the address of the upstream neighbor. Consequently, IP-Lb can be
included in the PIM Join packet as the explicit RPF Vector included in the PIM Join packet as the Explicit RPF Vector
Attribute.</t> Attribute.</t>
<t> <t>
The PIM protocol initially selects the RPF incoming interface and The PIM protocol initially selects the RPF incoming interface and
upstream neighbor towards IP-a and proceeds hop-by-hop to establish upstream neighbor towards IP-a and proceeds hop by hop to establish
the PIM standby multicast tree until reaching node A. At node A, IP- the PIM standby multicast tree until reaching node A. At node A, IP-
Lb is treated as the PIM upstream neighbor. Node A identifies the Lb is treated as the PIM upstream neighbor. Node A identifies the
incoming interface in the unicast routing table based on IP-Lb, and incoming interface in the unicast routing table based on IP-Lb, and
IP-Lb is used as the RPF upstream address for the PIM Join packet IP-Lb is used as the RPF upstream address for the PIM Join packet
directed towards node B.</t> directed towards node B.</t>
<t> <t>
Upon receiving the PIM Join packet at node B, the PIM protocol, Upon receiving the PIM Join packet at node B, the PIM protocol,
finding no additional RPF Vector Attributes, selects the RPF finding no additional RPF Vector Attributes, selects the RPF
incoming interface and upstream neighbor towards the multicast incoming interface and upstream neighbor towards the multicast
source directly. The protocol, then, continues hop-by-hop to source directly. The protocol then continues hop by hop to
establish the PIM standby multicast tree, extending to the router establish the PIM standby multicast tree, extending to the router
directly connected to the source.</t> directly connected to the source.</t>
<t> <t>
When a remote PQ node exists in both P-space and Q-space, the When a remote PQ node exists in both P-space and Q-space, the
processing can be simplified to involve only Node A.</t> processing can be simplified to involve only node A.</t>
</section> </section>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default"> <section anchor="sect-4" numbered="true" toc="default">
<name>Illustration</name> <name>Illustration</name>
<t> <t>
This section provides an illustration of MoFRR based on TI-LFA. The This section provides an illustration of MoFRR based on TI-LFA. The
example topology is depicted in Figure 2. The metric for the R3-R4 example topology is depicted in <xref target="ure-example-topology"/>. The me tric for the R3-R4
link is 100, while the metrics for the other links are 10. All link link is 100, while the metrics for the other links are 10. All link
metrics are bidirectional.</t> metrics are bidirectional.</t>
<figure anchor="ure-example-topology"> <figure anchor="ure-example-topology">
<name>Example Topology</name> <name>Example Topology</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
<-----Primary Path--- (S,G) Join <-----Primary Path--- (S,G) Join
[S]---(R1)---(R2)******(R6)-------[R] [S]---(R1)---(R2)******(R6)-------[R]
| | | |
<--- | | | <--- | | |
skipping to change at line 339 skipping to change at line 364
| | (R5) | | | (R5) |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| (R3)------(R4) | | (R3)------(R4) |
| | | |
--Secondary Path-- --Secondary Path--
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The IP addresses and SIDs involved in the MoFRR calculation are The IP addresses and SIDs involved in the MoFRR calculation are
configured as follows:</t> configured as follows:</t>
<dl newline="true" spacing="normal" indent="0">
<dt>IPv4 Data Plane (MPLS-SR [RFC8660])</dt> <t>IPv4 data plane (SR-MPLS <xref target="RFC8660"/>):</t>
<dd/>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Node IP Address Node SID Node IP Address Node SID
R4 IP4-R4 Label-R4 R4 IP4-R4 Label-R4
Link IP Address Adjacency SID Link IP Address Adjacency SID
R3->R4 IP4-R3-R4 Label-R3-R4 R3->R4 IP4-R3-R4 Label-R3-R4
R4->R3 IP4-R4-R3 Label-R4-R3 R4->R3 IP4-R4-R3 Label-R4-R3
]]></artwork>
IPv6 Data Plane (SRv6 [RFC8986]) <t>IPv6 data plane (SRv6 <xref target="RFC8986"/>):</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Node IP Address Node SID (End) Node IP Address Node SID (End)
R4 IP6-R4 SID-R4 R4 IP6-R4 SID-R4
Link IP Address Adjacency SID (End.X) Link IP Address Adjacency SID (End.X)
R3->R4 IP6-R3-R4 SID-R3-R4 R3->R4 IP6-R3-R4 SID-R3-R4
R4->R3 IP6-R4-R3 SID-R4-R3 R4->R3 IP6-R4-R3 SID-R4-R3
]]></artwork> ]]></artwork>
<t> <t>
The primary path of the PIM Join packet is R6-&gt;R2-&gt;R1, and the The primary path of the PIM Join packet is R6-&gt;R2-&gt;R1, and the
secondary path is R6-&gt;R5-&gt;R4-&gt;R3-&gt;R2-&gt;R1. However, the traditi onal secondary path is R6-&gt;R5-&gt;R4-&gt;R3-&gt;R2-&gt;R1. However, the traditi onal
LFA does not function properly for the secondary path because the LFA does not function properly for the secondary path because the
shortest path to R2 from R5 (or from R4) still traverses the R6-R2 shortest path to R2 from R5 (or from R4) still traverses the R6-R2
link. In this scenario, R6 must calculate the secondary UMH using link. In this scenario, R6 must calculate the secondary UMH using
the proposed MoFRR method based on TI-LFA.</t> the proposed MoFRR method based on TI-LFA.</t>
<t> <t>
According to the TI-LFA algorithm, the P-space and Q-space are According to the TI-LFA algorithm, the P-space and Q-space are illustrated
illustrated in Figure 3. The TI-LFA repair path consists of the Node in <xref target="ure-p-space-and-q-space"/>. The TI-LFA repair path
SID of R4 and the Adjacency SID of R4-&gt;R3. On the MPLS-SR data consists of the Node SID of R4 and the Adjacency SID of R4-&gt;R3. On the
plane, the repair segment list is (Label-R4, Label-R4-R3). On the Segment Routing over MPLS (SR-MPLS) data plane, the repair segment list is
SRv6 data plane, the repair segment list is (SID-R4, SID-R4-R3).</t> (Label-R4, Label-R4-R3). On the Segment 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"> <figure anchor="ure-p-space-and-q-space">
<name>P-Space and Q-Space</name> <name>P-Space and Q-Space</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
........ ........
. . . .
[S]---(R1)---(R2)******(R6)---[R] [S]---(R1)---(R2)******(R6)---[R]
. | . | . | . |
. | . +++|++++ . | . +++|++++
. | . + | + . | . + | +
. | . + (R5) + . | . + (R5) +
skipping to change at line 396 skipping to change at line 420
. | . + | + . | . + | +
. | . + | + . | . + | +
. (R3)------(R4) + . (R3)------(R4) +
. . + + . . + +
........ ++++++++ ........ ++++++++
Q-Space P-Space Q-Space P-Space
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In the PIM process, the IP addresses associated with the repair In the PIM process, the IP addresses associated with the repair
segment list are retrieved from the IGP link-state database.</t> segment list are retrieved from the IGP LSDB.</t>
<t> <t>
On the IPv4 data plane, the Node SID Label-R4 corresponds to IP4-R4, On the IPv4 data plane, the Node SID Label-R4 corresponds to IP4-R4,
which will be carried in the RPF Vector Attribute. The Adjacency SID which will be carried in the RPF Vector Attribute. The Adjacency SID
Label-R4-R3 corresponds to the local address IP4-R4-R3 and the 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 remote peer address IP4-R3-R4, with IP4-R3-R4 carried in the
Explicit RPF Vector Attribute.</t> Explicit RPF Vector Attribute.</t>
<t> <t>
On the IPv6 data plane, the End SID SID-R4 corresponds to IP6-R4, On the IPv6 data plane, the End SID SID-R4 corresponds to IP6-R4,
which will be carried in the RPF Vector Attribute. The End.X SID which will be carried in the RPF Vector Attribute. The End.X SID
SID-R4-R3 corresponds to the local address IP6-R4-R3 and the remote SID-R4-R3 corresponds to the local address IP6-R4-R3 and the remote
peer address IP6-R3-R4, with IP6-R3-R4 carried in the Explicit RPF peer address IP6-R3-R4, with IP6-R3-R4 carried in the Explicit RPF
Vector Attribute.</t> Vector Attribute.</t>
<dl newline="true" spacing="normal" indent="0">
<dt>Subsequently, R6 installs the secondary UMH using these RPF Vectors. <t>Subsequently, R6 installs the secondary UMH using these RPF Vectors.</t>
</dt>
<dd/>
</dl>
<figure anchor="ure-forwarding-pim-join-packet-along-secondary-path-ipv4"> <figure anchor="ure-forwarding-pim-join-packet-along-secondary-path-ipv4">
<name>Forwarding PIM Join Packet along Secondary Path (IPv4)</name> <name>Forwarding PIM Join Packet Along Secondary Path (IPv4)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------+ +---------+
|Type = 0 | |Type = 0 |
|IP4-R4 | |IP4-R4 |
+---------+ +---------+ +---------+ +---------+
|Type = 4 | |Type = 4 | |Type = 4 | |Type = 4 |
|IP4-R3-R4| |IP4-R3-R4| |IP4-R3-R4| |IP4-R3-R4|
+---------+ +---------+ No RPF Vector +---------+ +---------+ No RPF Vector
R6----->R5---->R4------------>R3----->R2---->R1 R6----->R5---->R4------------>R3----->R2---->R1
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
On the IPv4 data plane, the forwarding of the PIM Join packet along On the IPv4 data plane, the forwarding of the PIM Join packet along
the secondary path is shown in Figure 4.</t> the secondary path is shown in <xref target="ure-forwarding-pim-join-packet-a long-secondary-path-ipv4"/>.</t>
<t> <t>
R6 inserts two RPF Vector Attributes in the PIM Join packet: IP4-R4 R6 inserts two RPF Vector Attributes in the PIM Join packet: IP4-R4
of Type 0 (RPF Vector Attribute) and IP4-R3-R4 of Type 4 (Explicit of Type 0 (RPF Vector Attribute) and IP4-R3-R4 of Type 4 (Explicit
RPF Vector Attribute). R6 then forwards the packet along the RPF Vector Attribute). R6 then forwards the packet along the
secondary path.</t> secondary path.</t>
<t> <t>
When R5 receives the packet, it performs a unicast route lookup of 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> the first RPF Vector IP4-R4 and sends the packet to R4.</t>
<t> <t>
R4, being the owner of IP4-R4, removes the first RPF Vector from the R4, being the owner of IP4-R4, removes the first RPF Vector from the
packet and forwards it according to the next RPF Vector. R4 sends packet and forwards it according to the next RPF Vector. R4 sends
the packet to R3 based on the next RPF Vector IP4-R3-R4, as its PIM the packet to R3 based on the next RPF Vector IP4-R3-R4, as its PIM
neighbor R3 corresponds to IP4-R3-R4.</t> neighbor R3 corresponds to IP4-R3-R4.</t>
<t> <t>
When R3 receives the packet, as the owner of IP4-R3-R4, it removes When R3 receives the packet, as the owner of IP4-R3-R4, it removes
the RPF Vector. The packet, now devoid of RPF Vectors, is forwarded the RPF Vector. The packet, now devoid of RPF Vectors, is forwarded
to the source through R3-&gt;R2-&gt;R1 based on unicast routes.</t> to the source through R3-&gt;R2-&gt;R1 based on unicast routes.</t>
<t> <t>
After the PIM Join packet reaches R1, a secondary multicast tree, After the PIM Join packet reaches R1, a secondary multicast tree,
R1-&gt;R2-&gt;R3-&gt;R4-&gt;R5-&gt;R6, is established hop-by-hop for (S, G) u sing R1-&gt;R2-&gt;R3-&gt;R4-&gt;R5-&gt;R6, is established hop by hop for (S, G) u sing
MoFRR based on TI-LFA.</t> MoFRR based on TI-LFA.</t>
<figure anchor="ure-forwarding-pim-join-packet-along-secondary-path-ipv6"> <figure anchor="ure-forwarding-pim-join-packet-along-secondary-path-ipv6">
<name>Forwarding PIM Join Packet along Secondary Path (IPv6)</name> <name>Forwarding PIM Join Packet Along Secondary Path (IPv6)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------+ +---------+
|Type = 0 | |Type = 0 |
|IP6-R4 | |IP6-R4 |
+---------+ +---------+ +---------+ +---------+
|Type = 4 | |Type = 4 | |Type = 4 | |Type = 4 |
|IP6-R3-R4| |IP6-R3-R4| |IP6-R3-R4| |IP6-R3-R4|
+---------+ +---------+ No RPF Vector +---------+ +---------+ No RPF Vector
R6----->R5---->R4------------>R3----->R2---->R1 R6----->R5---->R4------------>R3----->R2---->R1
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
On the IPv6 data plane, the forwarding of the PIM Join packet along On the IPv6 data plane, the forwarding of the PIM Join packet along
the secondary path is illustrated in Figure 5. The procedure is the secondary path is illustrated in <xref target="ure-forwarding-pim-join-pa cket-along-secondary-path-ipv6"/>. The procedure is
analogous to that of the IPv4 data plane.</t> analogous to that of the IPv4 data plane.</t>
<t> <t>
When a remote PQ node exists in both P-space and Q-space, the When a remote PQ node exists in both P-space and Q-space, the
processing can be simplified to involve only the PQ node. In this processing can be simplified to involve only the PQ node. In this
case, only a single RPF Vector needs to be carried, and all other case, only a single RPF Vector needs to be carried, and all other
processing steps remain unchanged.</t> processing steps remain unchanged.</t>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default"> <section anchor="sect-5" numbered="true" toc="default">
<name>Management and Operational Considerations</name> <name>Management and Operational Considerations</name>
<t> <t>
The management of the proposed approach is consistent with <xref target="RFC7 916" format="default"/>. The management of the proposed approach is consistent with <xref target="RFC7 916" format="default"/>.
But, in the operation of this approach, the node on the backup Join paths However, in the operation of this approach, the node on the backup Join paths
must have independent configuration strategy for installing RPF Vector Attrib must have an independent configuration strategy for installing RPF Vector Att
utes ributes
in the PIM Join packet and controlling the sending of this PIM Join messages. in the PIM Join packet and controlling the sending of this PIM Join messag
</t> e.</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> <t>
All nodes on the backup Join paths must be able to parse the PIM Join message All nodes on the backup Join paths must be able to parse the PIM Join message
with RPF Vector attribute. If the nodes do not understand the RPF Vector attr with the RPF Vector Attribute. If the nodes do not understand the RPF Vector
ibute Attribute
in the PIM Join packet, then it must discard the RPF Vector attribute because in the PIM Join packet, then it must discard the RPF Vector Attribute because
failing failing
to remove the RPF Vectors could cause upstream nodes to send the Join back to to remove the RPF Vectors could cause upstream nodes to send the Join back to
ward wards
these nodes causing loops.</t> these nodes causing loops.</t>
<t> <t>
If an administrator is manually specifying the path that the Join messages ne If an administrator is manually specifying the path that the Join messages
ed to be sent on, need to be sent on, it is recommended that the administrator computes the
it is recommended that the administrator computes the path to include nodes t path to include nodes that support the Explicit RPF Vector and check that
hat support the the state is created correctly on each node along the path. Tools like
Explicit RPF Vector and check that the state is created correctly on each nod Mtrace <xref target="RFC8487" format="default"/> can be used for debugging
e along the path. and to ensure that the Join state is set up correctly.</t>
Tools like mtrace <xref target="RFC8487" format="default"/> can be used for d
ebugging and to ensure that the Join state is setup correctly.</t>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default"> <section anchor="sect-6" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
This document has no IANA actions.</t> This document has no IANA actions.</t>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default"> <section anchor="sect-7" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
This document does not introduce additional security concerns. It This document does not introduce additional security concerns. It
does not change the security properties of PIM. For general PIM-SM does not change the security properties of PIM. For general PIM - Sparse Mode (PIM-SM)
protocol security considerations, see <xref target="RFC7761" format="default" />. The security protocol security considerations, see <xref target="RFC7761" format="default" />. The security
considerations of LFA, R-LFA, and MoFRR described in <xref target="RFC5286" f ormat="default"/>, considerations of LFA, RLFA, and MoFRR described in <xref target="RFC5286" fo rmat="default"/>,
<xref target="RFC7490" format="default"/>, and <xref target="RFC7431" format= "default"/> should apply to this document.</t> <xref target="RFC7490" format="default"/>, and <xref target="RFC7431" format= "default"/> should apply to this document.</t>
<t> <t>
When deploying TI-LFA, packets may be sent over nodes and links they When deploying TI-LFA, packets may be sent over nodes and links they
were not transported through before, potentially raising the were not transported through before, potentially raising the
following security issues:</t> following security issues:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li anchor="issue1">
<t>Spoofing and False Route Advertisements</t> <t>Spoofing and false route advertisements</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Dependencies of LFA/R-LFA/TI-LFA on Routing Information</t> <t>Dependencies of LFA/RLFA/TI-LFA on routing information</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>LFAs depend on accurate routing information to determine <t>LFAs depend on accurate routing information to determine
alternate paths. If an attacker can inject false routing alternate paths. If an attacker can inject false routing
information (e.g., by spoofing link-state advertisements), it information (e.g., by spoofing link-state advertisements),
could cause the network to select suboptimal or malicious it could cause the network to select suboptimal or malicious
paths for LFAs.</t> paths for LFAs.</t>
</li> </li>
<li> <li>
<t>R-LFA and TI-LFA also depend on accurate routing informatio <t>RLFA and TI-LFA also depend on accurate routing
n, information, particularly for determining the tunneling
particularly for determining the tunneling paths or explicit paths or explicit paths. False route advertisements could
paths. False route advertisements could mislead the network mislead the network into using insecure or compromised
into using insecure or compromised paths.</t> paths.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li anchor="issue2">
<t>On-path Attacks</t> <t>On-path attacks</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Use of Alternate Paths</t> <t>Use of alternate paths</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>By rerouting traffic through alternate paths, especially <t>By rerouting traffic through alternate paths, especially
those that traverse multiple hops (as in R-LFA and TI-LFA), those that traverse multiple hops (as in RLFA and TI-LFA),
the risk of On-path attacks increases if any of the the risk of on-path attacks increases if any of the
intermediate routers on the alternate path is compromised.</t> intermediate routers on the alternate path are compromised.</t>
</li> </li>
<li> <li>
<t>TI-LFA, which uses explicit paths, might expose traffic to <t>TI-LFA, which uses explicit paths, might expose traffic to
routers that were not originally part of the primary path, routers that were not originally part of the primary path,
potentially allowing for interception or alteration of the potentially allowing for interception or alteration of the
traffic.</t> traffic.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li anchor="issue3">
<t>Confidentiality and Integrity</t> <t>Confidentiality and integrity</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Traffic Encapsulation</t> <t>Traffic encapsulation</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>R-LFA and TI-LFA involve encapsulating traffic, which may <t>RLFA and TI-LFA involve encapsulating traffic, which may
expose it to vulnerabilities if the encapsulation mechanisms expose it to vulnerabilities if the encapsulation mechanisms
are not secure. For instance, if IPsec or another secure are not secure. For instance, if IPsec or another secure
encapsulation method is not used, an attacker might be able encapsulation method is not used, an attacker might be able
to intercept or alter the traffic in transit.</t> to intercept or alter the traffic in transit.</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>Protection of Explicit Paths</t> <t>Protection of explicit paths</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>TI-LFA relies on explicit paths that are typically defined <t>TI-LFA relies on explicit paths that are typically
using segment routing. If these paths are not properly defined using SR. If these paths are not
protected, an attacker could manipulate the segment list to properly protected, an attacker could manipulate the segment
reroute traffic through malicious nodes.</t> list to reroute traffic through malicious nodes.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li anchor="issue4">
<t>Increased Attack Surface</t> <t>Increased attack surface</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Extended Topology</t> <t>Extended topology</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>By introducing LFA, R-LFA, and TI-LFA, the network increase s <t>By introducing LFA, RLFA, and TI-LFA, the network increases
its reliance on additional routers and links, thereby its reliance on additional routers and links, thereby
expanding the potential attack surface. Compromise of any expanding the potential attack surface. Compromise of any
router in these alternate paths could expose traffic to router in these alternate paths could expose traffic to
unauthorized access or disruption.</t> unauthorized access or disruption.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
</ol> </ol>
<t> <t>
To address security issues #1 and #2 mentioned above, control plane To address security issues <xref target="issue1" format="none">1</xref> and
<xref target="issue2" format="none">2</xref> mentioned above, control plane
protocols need to provide security protection. To mitigate the risks protocols need to provide security protection. To mitigate the risks
associated with false route advertisements and On-path attacks, it associated with false route advertisements and on-path attacks, it is
is recommended to use secure routing protocols (e.g., OSPFv3 with recommended to use secure routing protocols (e.g., OSPFv3 with IPsec, IS-IS
IPsec, ISIS HMAC-SHA256, or PIM with IPsec) that provide HMAC-SHA256, or PIM with IPsec) that provide authentication and integrity
authentication and integrity protection for routing updates.</t> protection for routing updates.</t>
<t> <t>
To address security issues #3 and #4 mentioned above, these To address security issues <xref target="issue3" format="none">3</xref> and <
mechanisms need to run within a trusted network. The security of xref
LFA, R-LFA, and TI-LFA mechanisms heavily relies on the target="issue4" format="none">4</xref> mentioned above, these mechanisms need
trustworthiness of the underlying routing infrastructure. As the to run
solution described in the document is based on Segment Routing within a trusted network. The security of LFA, RLFA, and TI-LFA mechanisms
technology, readers should be aware of the security considerations heavily relies on the trustworthiness of the underlying routing
related to this technology (<xref target="RFC8402" format="default"/>) and it infrastructure. As the solution described in the document is based on SR
s data plane technology, readers should be aware of the security considerations related
instantiations (<xref target="RFC8660" format="default"/>, <xref target="RFC8 to this technology (see <xref target="RFC8402" format="default"/>) and its da
754" format="default"/>, and <xref target="RFC8986" format="default"/>).</t> ta
plane instantiations (see <xref target="RFC8660" format="default"/>, <xref
target="RFC8754" format="default"/>, and <xref target="RFC8986"
format="default"/>).</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="I-D.ietf-rtgwg-segment-routing-ti-lfa" target="https:
//datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-21" xml: <!-- [RFC9855]
base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-segment-r draft-ietf-rtgwg-segment-routing-ti-lfa-21
outing-ti-lfa.xml"> companion doc RFC YYY1
<front> AUTH48 as of 09/05/25
<title>Topology Independent Fast Reroute using Segment Routing</titl -->
e>
<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy"> <reference anchor="RFC9855" target="https://www.rfc-editor.org/info/rfc9855">
<organization>Individual</organization> <front>
</author> <title>Topology Independent Fast Reroute Using Segment Routing</title>
<author fullname="Stephane Litkowski" initials="S." surname="Litkows <author initials="A." surname="Bashandy" fullname="Ahmed Bashandy">
ki"> <organization>Individual</organization>
<organization>Cisco Systems</organization> </author>
</author> <author initials="S." surname="Litkowski" fullname="Stephane Litkowski">
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils <organization>Cisco Systems</organization>
"> </author>
<organization>Cisco Systems</organization> <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
</author> <organization>Cisco Systems</organization>
<author fullname="Pierre Francois" initials="P." surname="Francois"> </author>
<organization>INSA Lyon</organization> <author initials="P." surname="Francois" fullname="Pierre Francois">
</author> <organization>INSA Lyon</organization>
<author fullname="Bruno Decraene" initials="B." surname="Decraene"> </author>
<organization>Orange</organization> <author initials="B." surname="Decraene" fullname="Bruno Decraene">
</author> <organization>Orange</organization>
<author fullname="Daniel Voyer" initials="D." surname="Voyer"> </author>
<organization>Bell Canada</organization> <author initials="D." surname="Voyer" fullname="Daniel Voyer">
</author> <organization>Bell Canada</organization>
<date day="12" month="February" year="2025"/> </author>
<abstract> <date month="September" year="2025"/>
<t>This document presents Topology Independent Loop-free Alternate </front>
Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segm <seriesInfo name="RFC" value="9855"/>
ents within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior <seriesInfo name="DOI" value="10.17487/RFC9855"/>
builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and r </reference>
emote LFAs with directed forwarding (DLFA). It extends these concepts to provide
guaranteed coverage in any two-connected networks using a link-state IGP. An im <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
portant aspect of TI-LFA is the FRR path selection approach establishing protect 286.xml"/>
ion over the expected post-convergence paths from the point of local repair, red <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
ucing the operational need to control the tie-breaks among various FRR options.< 384.xml"/>
/t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</abstract> 496.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-segment-rout 431.xml"/>
ing-ti-lfa-21"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</reference> 490.xml"/>
<reference anchor="RFC5286" target="https://www.rfc-editor.org/info/rfc5 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
286" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"> 761.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<title>Basic Specification for IP Fast Reroute: Loop-Free Alternates 891.xml"/>
</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="A. Atlas" initials="A." role="editor" surname="Atl 916.xml"/>
as"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="A. Zinin" initials="A." role="editor" surname="Zin 402.xml"/>
in"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="September" year="2008"/> 660.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>This document describes the use of loop-free alternates to prov 754.xml"/>
ide local protection for unicast traffic in pure IP and MPLS/LDP networks in the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
event of a single failure, whether link, node, or shared risk link group (SRLG) 986.xml"/>
. The goal of this technology is to reduce the packet loss that happens while ro
uters 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 s
afe to use until the distributed network convergence process completes. This sim
ple approach does not require any support from other routers. The extent to whic
h 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/rfc5
384" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5384.xml">
<front>
<title>The Protocol Independent Multicast (PIM) Join Attribute Forma
t</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 s
ent by a given node identifies one or more multicast distribution trees that tha
t 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 "wil
d card"). Under certain conditions it can be useful, when joining a tree, to spe
cify additional information related to the construction of the tree. However, th
ere has been no way to do so until now. This document describes a modification o
f 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>
</front>
<seriesInfo name="RFC" value="5384"/>
<seriesInfo name="DOI" value="10.17487/RFC5384"/>
</reference>
<reference anchor="RFC5496" target="https://www.rfc-editor.org/info/rfc5
496" 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 Multi
cast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build mul
ticast trees through an MPLS-enabled network, even if that network's IGP does no
t have a route to the source of the 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/rfc7
431" 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 in
the IP network carrying the packets for these services. This document describes
a mechanism for minimizing packet loss in a network when node or link failures o
ccur. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to
multicast routing protocols such as Protocol Independent Multicast (PIM) and Mu
ltipoint 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/rfc7
490" 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 to the basic IP fast rerou
te mechanism, described in RFC 5286, that provides additional backup connectivit
y for point-to-point link failures when none can be provided by the basic mechan
isms.</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/rfc7
761" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml">
<front>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protoc
ol 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 a multicast routing protocol that can use the underlyi
ng unicast routing information base or a separate multicast-capable routing info
rmation 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 Ro
uter features and authentication using IPsec that lack sufficient deployment exp
erience (see Appendix A), and moves the PIM 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/rfc7
891" 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="Krishnaswa
my"/>
<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 TLV defined in RFC
5496 can be included in a PIM Join Attribute such that the RPF neighbor is sele
cted based on the unicast reachability of the RPF Vector instead of the source o
r Rendezvous Point associated with the multicast tree.</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 by
passing the unicast 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/rfc7
916" 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 in RFC 5286, constitute
an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffi
c (and, by extension, MPLS LDP traffic). Following early deployment experiences,
this document provides operational feedback on LFAs, highlights some limitation
s, and proposes a set of refinements to address those limitations. It also propo
ses required management specifications.</t>
<t>This proposal is also applicable to 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/rfc8
402" 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="P
revidi"/>
<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 n
ode 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 provi
des a mechanism that allows a flow to be restricted to a specific topological pa
th, while maintaining per-flow state only at the ingress node(s) to the SR domai
n.</t>
<t>SR can be directly applied to the MPLS architecture with no cha
nge to the forwarding plane. A segment is encoded as an MPLS label. An ordered l
ist of segments is encoded as a stack of labels. The segment to process is on th
e top of the stack. Upon completion of a segment, the related label is popped fr
om the stack.</t>
<t>SR can be applied to the IPv6 architecture, with a new type of
routing header. A segment is encoded as an IPv6 address. An ordered list of segm
ents is encoded as an ordered list of IPv6 addresses in the routing header. The
active segment is indicated by the Destination Address (DA) of the packet. The n
ext active segment is indicated by a pointer in the new 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/rfc8
660" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml">
<front>
<title>Segment Routing with the MPLS 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) leverages the source-routing paradigm. A n
ode steers a packet through a controlled set of instructions, called segments, b
y prepending the packet with an SR header. In the MPLS data plane, the SR header
is instantiated through a label stack. This document specifies the forwarding b
ehavior to allow instantiating SR over the MPLS 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/rfc8
754" 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="Duk
es"/>
<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 Routing can be applied to the IPv6 data plane using a n
ew type of Routing Extension Header called the Segment Routing Header (SRH). Thi
s document describes the SRH and how it is used by nodes that are Segment Routin
g (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/rfc8
986" 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 framew
ork enables a network operator or an application to specify a packet processing
program by encoding a sequence of instructions in the IPv6 packet header.</t>
<t>Each instruction is implemented on one or several nodes in the
network and identified by an SRv6 Segment Identifier in the packet.</t>
<t>This document defines the SRv6 Network Programming concept and
specifies the base set of SRv6 behaviors that enables the creation of interopera
ble overlays with underlay optimization.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8986"/>
<seriesInfo name="DOI" value="10.17487/RFC8986"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC5715" target="https://www.rfc-editor.org/info/rfc5 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
715" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5715.xml"> 715.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<title>A Framework for Loop-Free Convergence</title> 102.xml"/>
<author fullname="M. Shand" initials="M." surname="Shand"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="S. Bryant" initials="S." surname="Bryant"/> 487.xml"/>
<date month="January" year="2010"/>
<abstract>
<t>A micro-loop is a packet forwarding loop that may occur transie
ntly among two or more routers in a hop-by-hop packet forwarding paradigm.</t>
<t>This framework provides a summary of the causes and consequence
s of micro-loops and enables the reader to form a judgement on whether micro-loo
ping is an issue that needs to be addressed in specific networks. It also provid
es a survey of the currently proposed mechanisms that may be used to prevent or
to suppress the formation of micro-loops when an IP or MPLS network undergoes to
pology change due to failure, repair, or management action. When sufficiently fa
st convergence is not available and the topology is susceptible to micro-loops,
use of one or more of these mechanisms may be desirable. This document is not an
Internet Standards Track specification; it is published for informational purpo
ses.</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/rfc8
102" 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="Sa
rkar"/>
<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 following the current
remote-LFA specification guarantees only link protection. The resulting remote-L
FA next hops (also called "PQ-nodes") may not guarantee node protection for all
destinations being protected by it.</t>
<t>This document describes an extension to the remote-loop-free-ba
sed IP fast reroute mechanisms that specifies procedures for determining whether
or not a given PQ-node provides node protection for a specific destination. The
document also shows how the same procedure can be utilized for the collection o
f complete characteristics for alternate paths. Knowledge about the characterist
ics of all alternate paths is a precursor to applying the operator-defined polic
y for eliminating paths not fitting the constraints.</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/rfc8
487" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8487.xml">
<front>
<title>Mtrace Version 2: Traceroute Facility for IP 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 describes the IP multicast traceroute facility, n
amed Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires spe
cial implementations on the part of routers.</t>
<t>This specification describes the required functionality in mult
icast routers, as well as how an Mtrace2 client invokes a Query and receives a R
eply.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8487"/>
<seriesInfo name="DOI" value="10.17487/RFC8487"/>
</reference>
</references> </references>
</references> </references>
<section numbered="false" anchor="contributors" toc="default"> <section numbered="false" anchor="contributors" toc="default">
<name>Contributors</name> <name>Contributors</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Mengxiao Chen <contact fullname="Mengxiao Chen">
New H3C Technologies <organization>New H3C Technologies</organization>
China <address>
Email: chen.mengxiao@h3c.com <postal>
]]></artwork> <country>China</country>
</postal>
<email>chen.mengxiao@h3c.com</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
<!-- [rfced] To avoid using an RFC as an adjective, may we update
the instances of "[RFC7431] MoFRR" in the text below as follows?
Original:
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 (see Section 2).
...
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 scenario, the [RFC7431] MoFRR operates effectively.
...
In this case, the [RFC7431] MoFRR cannot calculate a secondary UMH.
Similarly, for multicast source S3 and receiver R, the [RFC7431] MoFRR
mechanism is ineffective.
...
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 [RFC7431] MoFRR, as previously described.
Perhaps:
However, the MoFRR mechanism [RFC7431], which selects the secondary...
...
Consequently, the MoFRR functionality [RFC7431] in PIM is applicable...
...
The limitations of the MoFRR applicability [RFC7431] can be illustrated...
...
In this scenario, MoFRR [RFC7431] operates effectively.
...
In this case, MoFRR [RFC7431] cannot calculate a secondary UMH.
Similarly, for multicast source S3 and receiver R, the MoFRR
mechanism [RFC7431] is ineffective.
...
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 MoFRR [RFC7431], as previously described.
-->
<!-- [rfced] We note that the following terminology appears to be used
inconsistently throughout the document. Please review these occurrences
and let us know if/how they may be made 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 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure 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 of this nature typically
result in more precise language, which is helpful for readers.
a) For example, please consider whether "native" should be updated in the text
below:
This mechanism is applicable to PIM networks, including cases where PIM
operates natively over IP in Segment Routing (SR) networks.
b) In addition, please consider whether "tradition" should be updated for clarit
y.
While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-l
ibrary/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone:
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.
-->
 End of changes. 73 change blocks. 
612 lines changed or deleted 294 lines changed or added

This html diff was produced by rfcdiff 1.48.