Diff: rfc9860.original.xml

	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	<!DOCTYPE rfc [
	ates="" xml:lang="en" symRefs="true" sortRefs="false" tocInclude="true" version=	<!ENTITY nbsp " ">
	"3">	<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>

		<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="tr
		ue" 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>zhang.zheng@zte.com.cn</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="October"/>
	<workgroup>PIM Working Group</workgroup>	<area>RTG</area>
		<workgroup>pim</workgroup>

		<keyword>PIM</keyword>
		<keyword>MoFRR</keyword>
		<keyword>LFA</keyword>
		<keyword>TI-LFA</keyword>
		<keyword>SR-MPLS</keyword>
		<keyword>SRv6</keyword>
		<keyword>RPF Vector</keyword>
		<keyword>Join attribute</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 MoFRR mechanism
	<xref target="RFC7761" format="default"/>. However, the <xref target="RFC7431	<xref target="RFC7431"/>, which selects the secondary multicast next hop
	" format="default"/> MoFRR mechanism, which selects the	based solely on the Loop-Free Alternate (LFA) FRR defined in <xref
	secondary multicast next-hop based solely on the loop-free alternate	target="RFC7431" format="default"/>, has limitations in certain multicast
	fast reroute defined in <xref target="RFC7431" format="default"/>, has limita	deployment scenarios (see <xref target="sect-2" format="default"/>).</t>
	tions in certain
	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 w
	cases where PIM operates natively over IP in Segment Routing (SR)	here PIM
	networks.</t>	operates directly over IP in Segment Routing (SR) 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 MoFRR functionality
	establishing a standby multicast tree and thus from implementing	<xref target="RFC7431" format="default"/> in PIM is applicable only in
	MoFRR protection. Consequently, the <xref target="RFC7431" format="default"/>	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	The limitations of the MoFRR applicability <xref target="RFC7431" format="def
	ability can be	ault"/> 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->R2->R1, and the secondary path is R3->R4->R1,	Join packet is R3->R2->R1, and the secondary path is R3->R4->R1,
	which corresponds to the LFA path of unicast routing. In this	which corresponds to the LFA path of unicast routing. In this

	scenario, the <xref target="RFC7431" format="default"/> MoFRR operates effect ively.</t>	scenario, MoFRR <xref target="RFC7431" format="default"/> operates effectivel y.</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 Join
	Join packet is R3->R2. However, an LFA does not exist. If R3 sends	packet is R3->R2. However, an LFA does not exist. If R3 sends the packet
	the packet to R4, R4 will forward it back to R3 because the IGP	to R4, R4 will forward it back to R3 because the IGP shortest path from R4
	shortest path from R4 to R1 is R4->R3->R2. In this case, the	to R1 is R4->R3->R2. In this case, MoFRR <xref target="RFC7431"
	<xref target="RFC7431" format="default"/> MoFRR cannot calculate a secondary	format="default"/> cannot calculate a secondary UMH. Similarly, for
	UMH. Similarly, for	multicast source S3 and receiver R, the MoFRR mechanism <xref
	multicast source S3 and receiver R, the <xref target="RFC7431" format="defaul	target="RFC7431" format="default"/> is ineffective.</t>
	t"/> MoFRR mechanism is
	ineffective.</t>
	<figure anchor="ure-example-network-topology">	<figure anchor="ure-example-network-topology">
	<name>Example Network Topology</name>	<name>Example Network Topology</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	10 20	10 20
	[S1]----(R1)-------------(R4)	[S1]----(R1)-------------(R4)
	\| \|	\| \|
	\| \|	\| \|
	\|10 \|10	\|10 \|10
	10 \| \|	10 \| \|
	[S2]----(R2)-------------(R3)----[R]	[S2]----(R2)-------------(R3)----[R]

	skipping to change at line 192 ¶	skipping to change at line 213 ¶
	10 \| \|	10 \| \|
	[S3]----(R5)-----(R6)----(R7)	[S3]----(R5)-----(R6)----(R7)
	100 10	100 10
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	</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 Node SID 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 Node SID.</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 Node SID and the IP addresses of the
	endpoints of the corresponding link in the unicast route base	endpoints of the corresponding link in the unicast route base
	according to the Adjacency SIDs. However, multicast protocol packets	according to the Adjacency SIDs. However, multicast protocol packets

	cannot be directly forwarded along the path of the Segment List.</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 MoFRR <xref
	scribed. Using TI-LFA,	target="RFC7431" format="default"/>, 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->R4->R1->R2.</t>	path R3->R4->R1->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->R2->R5. Using TI-LFA, R3 sends	path of the PIM Join packet is R3->R2->R5. Using TI-LFA, R3 sends
	the PIM Join packet to R7 while including two RPF Vectors:</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 271 ¶	skipping to change at line 292 ¶
	and R5, which serve as R3's Q-node for the protected R3-R2 link.</t>	and R5, which serve as R3's Q-node for the protected R3-R2 link.</t>
	</li>	</li>
	</ul>	</ul>
	<t>	<t>
	The first RPF Vector guides the PIM Join path through R3->R7->R6,	The first RPF Vector guides the PIM Join path through R3->R7->R6,
	while the second RPF Vector guides the PIM Join path through R6->R5,	while the second RPF Vector guides the PIM Join path through R6->R5,
	thereby establishing the secondary path R3->R7->R6->R5.</t>	thereby establishing the secondary path R3->R7->R6->R5.</t>
	<t>	<t>
	This document leverages the above RPF Vector standards, obviating	This document leverages the above RPF Vector standards, obviating
	the need for PIM protocol extensions. This approach allows the	the need for PIM protocol extensions. This approach allows the

	establishment of a standby multicast tree based on the Segment List	establishment of a standby multicast tree based on the segment list
	calculated by TI-LFA, thereby providing comprehensive MoFRR	calculated by TI-LFA, thereby providing comprehensive MoFRR
	protection for multicast services across diverse network	protection for multicast services across diverse network
	environments.</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 360 ¶
	\| \| (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>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
		conventional 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>	<t>

	The primary path of the PIM Join packet is R6->R2->R1, and the	According to the TI-LFA algorithm, the P-space and Q-space are illustrated
	secondary path is R6->R5->R4->R3->R2->R1. However, the traditi	in <xref target="ure-p-space-and-q-space"/>. The TI-LFA repair path
	onal	consists of the Node SID of R4 and the Adjacency SID of R4->R3. On the
	LFA does not function properly for the secondary path because the	Segment Routing over MPLS (SR-MPLS) data plane, the repair segment list is
	shortest path to R2 from R5 (or from R4) still traverses the R6-R2	(Label-R4, Label-R4-R3). On the Segment Routing over IPv6 (SRv6) data
	link. In this scenario, R6 must calculate the secondary UMH using	plane, the repair segment list is (SID-R4, SID-R4-R3).</t>
	the proposed MoFRR method based on TI-LFA.</t>
	<t>
	According to the TI-LFA algorithm, the P-space and Q-space are
	illustrated in Figure 3. The TI-LFA repair path consists of the Node
	SID of R4 and the Adjacency SID of R4->R3. On the MPLS-SR data
	plane, the repair segment list is (Label-R4, Label-R4-R3). On the
	SRv6 data plane, the repair segment list is (SID-R4, SID-R4-R3).</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 416 ¶
	. \| . + \| +	. \| . + \| +
	. \| . + \| +	. \| . + \| +
	. (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->R2->R1 based on unicast routes.</t>	to the source through R3->R2->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->R2->R3->R4->R5->R6, is established hop-by-hop for (S, G) u sing	R1->R2->R3->R4->R5->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	The management of the proposed approach is consistent with <xref
	916" format="default"/>.	target="RFC7916" format="default"/>. However, in the operation of this
	But, in the operation of this approach, the node on the backup Join paths	approach, the node on the backup Join paths must have an independent
	must have independent configuration strategy for installing RPF Vector Attrib	configuration strategy for installing RPF Vector Attributes in the PIM Join
	utes	packet and controlling the sending of this PIM Join message.</t>
	in the PIM Join packet and controlling the sending of this PIM Join messages.
	</t>	<t>All nodes on the backup Join paths must be able to parse the PIM Join
	<t>	message with the RPF Vector Attribute. If the nodes do not understand the
	All nodes on the backup Join paths must be able to parse the PIM Join message	RPF Vector Attribute in the PIM Join packet, then they must discard the
	with RPF Vector attribute. If the nodes do not understand the RPF Vector attr	RPF Vector Attribute because failing to remove the RPF Vectors could cause
	ibute	upstream nodes to send the Join packet back towards these nodes causing
	in the PIM Join packet, then it must discard the RPF Vector attribute because	loops.</t>
	failing
	to remove the RPF Vectors could cause upstream nodes to send the Join back to
	ward
	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:	<reference anchor="RFC9855" target="https://www.rfc-editor.org/info/rfc9855">
	//datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-21" xml:	<front>
	base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-segment-r	<title>Topology Independent Fast Reroute Using Segment Routing</title>
	outing-ti-lfa.xml">	<author initials="A." surname="Bashandy" fullname="Ahmed Bashandy">
	<front>	<organization>Individual</organization>
	<title>Topology Independent Fast Reroute using Segment Routing</titl	</author>
	e>	<author initials="S." surname="Litkowski" fullname="Stephane Litkowski">
	<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy">	<organization>Cisco Systems</organization>
	<organization>Individual</organization>	</author>
	</author>	<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
	<author fullname="Stephane Litkowski" initials="S." surname="Litkows	<organization>Cisco Systems</organization>
	ki">	</author>
	<organization>Cisco Systems</organization>	<author initials="P." surname="Francois" fullname="Pierre Francois">
	</author>	<organization>INSA Lyon</organization>
	<author fullname="Clarence Filsfils" initials="C." surname="Filsfils	</author>
	">	<author initials="B." surname="Decraene" fullname="Bruno Decraene">
	<organization>Cisco Systems</organization>	<organization>Orange</organization>
	</author>	</author>
	<author fullname="Pierre Francois" initials="P." surname="Francois">	<author initials="D." surname="Voyer" fullname="Daniel Voyer">
	<organization>INSA Lyon</organization>	<organization>Bell Canada</organization>
	</author>	</author>
	<author fullname="Bruno Decraene" initials="B." surname="Decraene">	<date month="September" year="2025"/>
	<organization>Orange</organization>	</front>
	</author>	<seriesInfo name="RFC" value="9855"/>
	<author fullname="Daniel Voyer" initials="D." surname="Voyer">	<seriesInfo name="DOI" value="10.17487/RFC9855"/>
	<organization>Bell Canada</organization>	</reference>
	</author>
	<date day="12" month="February" year="2025"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	<abstract>	286.xml"/>
	<t>This document presents Topology Independent Loop-free Alternate	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segm	384.xml"/>
	ents within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and r	496.xml"/>
	emote LFAs with directed forwarding (DLFA). It extends these concepts to provide	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	guaranteed coverage in any two-connected networks using a link-state IGP. An im	431.xml"/>
	portant aspect of TI-LFA is the FRR path selection approach establishing protect	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	ion over the expected post-convergence paths from the point of local repair, red	490.xml"/>
	ucing the operational need to control the tie-breaks among various FRR options.<	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	/t>	761.xml"/>
	</abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	</front>	891.xml"/>
	<seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-segment-rout	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	ing-ti-lfa-21"/>	916.xml"/>
	</reference>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<reference anchor="RFC5286" target="https://www.rfc-editor.org/info/rfc5	402.xml"/>
	286" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<front>	660.xml"/>
	<title>Basic Specification for IP Fast Reroute: Loop-Free Alternates	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	</title>	754.xml"/>
	<author fullname="A. Atlas" initials="A." role="editor" surname="Atl	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	as"/>	986.xml"/>
	<author fullname="A. Zinin" initials="A." role="editor" surname="Zin
	in"/>
	<date month="September" year="2008"/>
	<abstract>
	<t>This document describes the use of loop-free alternates to prov
	ide 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 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>

End of changes. 83 change blocks.
	649 lines changed or deleted	297 lines changed or added
This html diff was produced by rfcdiff 1.48.