Diff: rfc9855xml2.original.xml

	rfc9855xml2.original.xml	rfc9855.xml
	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="utf-8"?>

	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	<!DOCTYPE rfc [
	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	<!ENTITY nbsp " ">
	C.2119.xml">	<!ENTITY zwsp "">
	<!ENTITY RFC5384 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	<!ENTITY nbhy "‑">
	C.5286.xml">	<!ENTITY wj "⁠">
	<!ENTITY RFC5714 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5714.xml">
	<!ENTITY RFC5715 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5715.xml">
	<!ENTITY RFC6571 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.6571.xml">
	<!ENTITY RFC6976 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.6976.xml">
	<!ENTITY RFC7490 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7490.xml">
	<!ENTITY RFC7916 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7916.xml">
	<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8174.xml">
	<!ENTITY RFC8333 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8333.xml">
	<!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8402.xml">
	<!ENTITY RFC8660 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8660.xml">
	<!ENTITY RFC8665 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8665.xml">
	<!ENTITY RFC8667 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8667.xml">
	<!ENTITY RFC8754 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8754.xml">
	<!ENTITY RFC8986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8986.xml">
	<!ENTITY RFC9256 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.9256.xml">
	<!ENTITY I-D.bashandy-rtgwg-segment-routing-uloop SYSTEM "https://xml2rfc.ietf.o
	rg/public/rfc/bibxml3/reference.I-D.bashandy-rtgwg-segment-routing-uloop.xml">
	<!ENTITY FLEXALGO SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.9350.xml">
	]>	]>

	<rfc category="std" consensus="true"
	docName="draft-ietf-rtgwg-segment-routing-ti-lfa-21" ipr="trust200902"
	submissionType="IETF">
	<!-- Generated by id2xml 1.4.4 on 2018-12-03T18:16:52Z -->

	<?rfc compact="yes"?>

	<?rfc text-list-symbols="o*+-"?>

	<?rfc subcompact="no"?>

	<?rfc sortrefs="yes"?>

	<?rfc symrefs="yes"?>


	<?rfc strict="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
		docName="draft-ietf-rtgwg-segment-routing-ti-lfa-21" number="9855" ipr="trust200
	<?rfc toc="yes"?>	902" submissionType="IETF" obsoletes="" updates="" xml:lang="en" sortRefs="true"
		symRefs="true" tocInclude="true" version="3">

	<front>	<front>

	<title abbrev="SR TI-LFA">Topology Independent Fast Reroute using Segment	<title abbrev="SR TI-LFA">Topology Independent Fast Reroute Using Segment
	Routing</title>	Routing</title>

		<seriesInfo name="RFC" value="9855"/>
	<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy">	<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy">
	<organization>Individual</organization>	<organization>Individual</organization>


	<address>	<address>

	<postal>
	<street/>

	<city/>

	<country/>
	</postal>

	<email>abashandy.ietf@gmail.com</email>	<email>abashandy.ietf@gmail.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Stephane Litkowski" initials="S." surname="Litkowski">	<author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>


	<address>	<address>
	<postal>	<postal>

	<street/>

	<city/>

	<country>France</country>	<country>France</country>
	</postal>	</postal>


	<email>slitkows@cisco.com</email>	<email>slitkows@cisco.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">	<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>


	<address>	<address>
	<postal>	<postal>

	<street/>

	<city>Brussels</city>	<city>Brussels</city>


	<country>Belgium</country>	<country>Belgium</country>
	</postal>	</postal>


	<email>cfilsfil@cisco.com</email>	<email>cfilsfil@cisco.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Pierre Francois" initials="P." surname="Francois">	<author fullname="Pierre Francois" initials="P." surname="Francois">
	<organization>INSA Lyon</organization>	<organization>INSA Lyon</organization>


	<address>	<address>

	<postal>
	<street/>

	<city/>

	<country/>
	</postal>

	<email>pierre.francois@insa-lyon.fr</email>	<email>pierre.francois@insa-lyon.fr</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Bruno Decraene" initials="B." surname="Decraene">	<author fullname="Bruno Decraene" initials="B." surname="Decraene">
	<organization>Orange</organization>	<organization>Orange</organization>


	<address>	<address>
	<postal>	<postal>

	<street/>

	<city>Issy-les-Moulineaux</city>	<city>Issy-les-Moulineaux</city>


	<country>France</country>	<country>France</country>
	</postal>	</postal>


	<email>bruno.decraene@orange.com</email>	<email>bruno.decraene@orange.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Daniel Voyer" initials="D." surname="Voyer">	<author fullname="Daniel Voyer" initials="D." surname="Voyer">
	<organization>Bell Canada</organization>	<organization>Bell Canada</organization>


	<address>	<address>
	<postal>	<postal>

	<street/>

	<city/>

	<country>Canada</country>	<country>Canada</country>
	</postal>	</postal>


	<email>daniel.voyer@bell.ca</email>	<email>daniel.voyer@bell.ca</email>
	</address>	</address>
	</author>	</author>

		<date year="2025" month="September"/>


	<abstract>	<area>RTG</area>
	<t>This document presents Topology Independent Loop-free Alternate Fast	<workgroup>rtgwg</workgroup>
	Reroute (TI-LFA), aimed at providing protection of node and adjacency
	segments within the Segment Routing (SR) framework. This Fast Reroute
	(FRR) behavior builds on proven IP Fast Reroute concepts being LFAs,
	remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It
	extends these concepts to provide guaranteed coverage in any
	two-connected networks using a link-state IGP. An important aspect of
	TI-LFA is the FRR path selection approach establishing protection over
	the expected post-convergence paths from the point of local repair,
	reducing the operational need to control the tie-breaks among various FRR
	options.</t>

	</abstract>
	</front>

	<middle>
	<section anchor="acronyms" title="Acronyms">
	<t><list style="symbols">
	<t>DLFA: Remote LFA with Directed forwarding.</t>

	<t>FRR: Fast Re-route.</t>

	<t>IGP: Interior Gateway Protocol.</t>

	<t>LFA: Loop-Free Alternate.</t>

	<t>LSDB: Link State DataBase.</t>

	<t>PLR: Point of Local Repair.</t>

	<t>RL: Repair list.</t>

	<t>RLFA: Remote LFA.</t>

	<t>SID: Segment Identifier.</t>


	<t>SPF: Shortest Path First.</t>	<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->


	<t>SR: Segment Routing.</t>	<keyword>example</keyword>


	<t>SRLG: Shared Risk Link Group.</t>	<!-- [rfced] FYI - We have made some adjustments to the abstract in order
		to clarify the expansions of some abbreviations. Please review and let
		us know if any further updates are necessary.


	<t>TI-LFA: Topology Independent LFA.</t>	Original:
		This document presents Topology Independent Loop-free Alternate Fast
		Reroute (TI-LFA), aimed at providing protection of node and adjacency
		segments within the Segment Routing (SR) framework. This Fast
		Reroute (FRR) behavior builds on proven IP Fast Reroute concepts
		being LFAs, remote LFAs (RLFA), and remote LFAs with directed
		forwarding (DLFA).


	</list></t>	Current:
	</section>	This document presents Topology Independent Loop-Free Alternate (TI-
		LFA) Fast Reroute (FRR), which is aimed at providing protection of
		node and adjacency segments within the Segment Routing (SR)
		framework. This FRR behavior builds on proven IP FRR concepts being
		LFAs, Remote LFAs (RLFAs), and remote LFAs with directed
		forwarding (DLFAs).
		-->


	<section anchor="introduction" title="Introduction">	<abstract>
		<t>This document presents Topology Independent Loop-Free Alternate
		(TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of
		node and adjacency segments within the Segment Routing (SR)
		framework. This FRR behavior builds on proven IP FRR concepts being
		LFAs, Remote LFAs (RLFAs), and remote LFAs with directed forwarding
		(DLFAs). It extends these concepts to provide guaranteed coverage in any
		two-connected networks using a link-state IGP. An important aspect of
		TI-LFA is the FRR path selection approach establishing protection over
		the expected post-convergence paths from the Point of Local Repair
		(PLR), reducing the operational need to control the tie-breaks among
		various FRR options.</t>
		</abstract>
		</front>
		<middle>
		<section anchor="introduction" numbered="true" toc="default">
		<name>Introduction</name>
	<t>This document outlines a local repair mechanism that leverages Segment	<t>This document outlines a local repair mechanism that leverages Segment
	Routing (SR) to restore end-to-end connectivity in the event of a failure	Routing (SR) to restore end-to-end connectivity in the event of a failure
	involving a directly connected network component. This mechanism is	involving a directly connected network component. This mechanism is
	designed for standard link-state Interior Gateway Protocol (IGP) shortest	designed for standard link-state Interior Gateway Protocol (IGP) shortest
	path scenarios. Non-SR mechanisms for local repair are beyond the scope	path scenarios. Non-SR mechanisms for local repair are beyond the scope
	of this document. Non-local failures are addressed in a separate document	of this document. Non-local failures are addressed in a separate document

	<xref target="I-D.bashandy-rtgwg-segment-routing-uloop"/>.</t>	<xref target="I-D.bashandy-rtgwg-segment-routing-uloop" format="default"/>
		.</t>
	<t>The term topology independent (TI) describes the capability providing	<t>The term Topology Independent (TI) describes the capability providing
	a loop free backup path that is effective accross all network	a loop-free backup path that is effective across all network
	topologies. This provides a major improvement compared to LFA <xref	topologies. This provides a major improvement compared to LFA <xref

	target="RFC5286"/> and remote LFA <xref target="RFC7490"/> which cannot	target="RFC5286" format="default"/> and RLFA <xref
	provide a complete protection coverage in some topologies as described in	target="RFC7490" format="default"/>, which cannot provide a complete
	<xref target="RFC6571"/>.</t>	protection coverage in some topologies as described in <xref
		target="RFC6571" format="default"/>.</t>
	<t>When the network reconverges after failure, micro-loops <xref	<t>When the network reconverges after failure, micro-loops <xref

	target="RFC5715"/> can form due to transient inconsistencies in	target="RFC5715" format="default"/> can form due to transient
	the forwarding tables of different routers. If it is determined	inconsistencies in the forwarding tables of different routers. If it is
	that micro-loops are a significant issue in the deployment, then	determined that micro-loops are a significant issue in the deployment,
	a suitable loop-free convergence method, such as one of those	then a suitable loop-free convergence method should be implemented, such a
	described in <xref target="RFC5715"/>, <xref target="RFC6976"/>,	s one of those
	<xref target="RFC8333"/>, or <xref	described in <xref target="RFC5715" format="default"/>, <xref
	target="I-D.bashandy-rtgwg-segment-routing-uloop"/> should be	target="RFC6976" format="default"/>, <xref target="RFC8333"
	implemented.</t>	format="default"/>, or <xref
		target="I-D.bashandy-rtgwg-segment-routing-uloop" format="default"/>.</t>
	<t>TI-LFA operates locally at the Point of Local Repair (PLR) upon	<t>TI-LFA operates locally at the Point of Local Repair (PLR) upon
	detecting a failure in one of its direct links. Consequently, this local	detecting a failure in one of its direct links. Consequently, this local
	operation does not influence:	operation does not influence:

	<list style="symbols">	</t>
	<t>Micro-loops that may or may not form during the distributed	<ul spacing="normal">
	Interior Gateway Protocol (IGP) convergence as delineated in <xref	<li>
	target="RFC5715"/>:	<t>Micro-loops that may or may not form during the distributed IGP con
	<list style="symbols">	vergence as delineated in <xref target="RFC5715" format="default"/>:
	<t>These micro-loops occur on routes directed towards the	</t>
	destination that do not traverse TI-LFA-configured paths. According	<ul spacing="normal">
	to <xref target="RFC5714"/>, the formation of such micro-loops can	<li>
		<t>These micro-loops occur on routes directed towards the
		destination that do not traverse paths configured for TI-LFA. Accordin
		g
		to <xref target="RFC5714" format="default"/>, the formation of such mi
		cro-loops can
	prevent traffic from reaching the PLR, thereby bypassing the TI-LFA	prevent traffic from reaching the PLR, thereby bypassing the TI-LFA
	paths established for rerouting.</t>	paths established for rerouting.</t>

	</list></t>	</li>
		</ul>
		</li>
		<li>
	<t>Micro-loops that may or may not develop when the previously failed	<t>Micro-loops that may or may not develop when the previously failed
	link is restored to functionality.</t>	link is restored to functionality.</t>

	</list></t>	</li>
		</ul>
	<t>TI-LFA paths are activated from the instant the PLR detects a failure	<t>TI-LFA paths are activated from the instant the PLR detects a failure

	in a local link and remain in effect until the Interior Gateway Protocol	in a local link and remain in effect until the IGP convergence at the PLR
	(IGP) convergence at the PLR is fully achieved. Consequently, they are	is fully achieved. Consequently, they are
	not susceptible to micro-loops that may arise due to variations in the	not susceptible to micro-loops that may arise due to variations in the
	IGP convergence times across different nodes through which these paths	IGP convergence times across different nodes through which these paths
	traverse. This ensures a stable and predictable routing environment,	traverse. This ensures a stable and predictable routing environment,
	minimizing disruptions typically associated with asynchronous network	minimizing disruptions typically associated with asynchronous network
	behavior. However, an early (relative to the other nodes) IGP convergence	behavior. However, an early (relative to the other nodes) IGP convergence

	at the PLR and the consecutive ”early” release of TI-LFA paths may cause	at the PLR and the consecutive "early" release of TI-LFA paths may cause
	micro-loops, especially if these paths have been computed using the	micro-loops, especially if these paths have been computed using the

	methods described in Section <xref target="pq_backup"/>, <xref	methods described in Sections <xref target="pq_backup" format="counter"/>,
	target="adj_pq_backup"/>, or <xref target="remote_pq_backup"/> of the	<xref target="adj_pq_backup" format="counter"/>, or <xref target="remote_pq_bac
		kup" format="counter"/> of this
	document. One of the possible ways to prevent such micro-loops is local	document. One of the possible ways to prevent such micro-loops is local

	convergence delay (<xref target="RFC8333"/>).</t>	convergence delay <xref target="RFC8333" format="default"/>.</t>
		<t>TI-LFA procedures are complementary to the application of any micro-loo
	<t>TI-LFA procedures are complementary to application of any micro-loop	p
	avoidance procedures in the case of link or node failure: <list	avoidance procedures in the case of link or node failure:</t>
	style="symbols">	<ul spacing="normal">
		<li>
	<t>Link or node failure requires some urgent action to restore the	<t>Link or node failure requires some urgent action to restore the

	traffic that passed thru the failed resource. TI-LFA paths are	traffic that passed through the failed resource. TI-LFA paths are
	pre-computed and pre-installed and therefore suitable for urgent	pre-computed and pre-installed; therefore, they are suitable for urgen
	recovery</t>	t
		recovery.</t>
		</li>
		<li>
	<t>The paths used in the micro-loop avoidance procedures typically	<t>The paths used in the micro-loop avoidance procedures typically
	cannot be pre-computed.</t>	cannot be pre-computed.</t>

	</list></t>	</li>
		</ul>
	<t>For each destination (as specified by the IGP) in the network, TI-LFA	<t>For each destination (as specified by the IGP) in the network, TI-LFA
	pre-installs a backup forwarding entry for each protected destination	pre-installs a backup forwarding entry for each protected destination
	ready to be activated upon detection of the failure of a link used to	ready to be activated upon detection of the failure of a link used to
	reach the destination. TI-LFA provides protection in the event of any	reach the destination. TI-LFA provides protection in the event of any

	one of the following: single link failure, single node failure, or single	one of the following: single link failure, single node failure, or
	SRLG failure. In link failure mode, the destination is protected assuming	single Shared Risk Link Group (SRLG) failure. In link failure mode, the
	the failure of the link. In node protection mode, the destination is	destination is protected assuming the failure of the link. In node
	protected assuming that the neighbor connected to the primary link <xref t	protection mode, the destination is protected assuming that the neighbor
	arget="terminology"/> has	connected to the primary link (see <xref target="terminology"
	failed. In SRLG protecting mode, the destination is protected assuming	format="default"/>) has failed. In SRLG protecting mode, the
	that a configured set of links sharing fate with the primary link has	destination is protected assuming that a configured set of links sharing
	failed (e.g. a linecard or a set of links sharing a common transmission	fate with the primary link has failed (e.g., a linecard or a set of links
	pipe).</t>	sharing a common transmission pipe).</t>

	<t>Protection techniques outlined in this document are limited to	<t>Protection techniques outlined in this document are limited to
	protecting links, nodes, and SRLGs that are within a link-state IGP	protecting links, nodes, and SRLGs that are within a link-state IGP
	area. Protecting domain exit routers and/or links attached to another	area. Protecting domain exit routers and/or links attached to another

	routing domains are beyond the scope of this document</t>	routing domain is beyond the scope of this document.</t>


	<t>By utilizing Segment Routing (SR), TI-LFA eliminates the need to	<!-- [rfced] We were unable to find the term "Directed Loop-Free Alternates
		(DLFA)" mentioned in RFC 5714. Is there an alternative reference that could
		be used here?

		Original:
		By utilizing Segment Routing (SR), TI-LFA eliminates the need to
		establish Targeted Label Distribution Protocol sessions with remote
		nodes for leveraging the benefits of Remote Loop-Free Alternates
		(RLFA) [RFC7490][RFC7916] or Directed Loop-Free Alternates (DLFA)
		[RFC5714].

		-->
		<t>By utilizing SR, TI-LFA eliminates the need to
	establish Targeted Label Distribution Protocol sessions with	establish Targeted Label Distribution Protocol sessions with
	remote nodes for leveraging the benefits of Remote Loop-Free Alternates	remote nodes for leveraging the benefits of Remote Loop-Free Alternates

	(RLFA) <xref target="RFC7490"/><xref target="RFC7916"/> or Directed	(RLFAs) <xref target="RFC7490" format="default"/> <xref target="RFC7916" f
	Loop-Free Alternates (DLFA) <xref target="RFC5714"/>. All the Segment	ormat="default"/> or Directed
		Loop-Free Alternates (DLFAs) <xref target="RFC5714" format="default"/>. Al
		l the Segment
	Identifiers (SIDs) required are present within the Link State Database	Identifiers (SIDs) required are present within the Link State Database

	(LSDB) of the Interior Gateway Protocol (IGP). Consequently, there is no	(LSDB) of the IGP. Consequently, there is no
	longer a necessity to prefer LFAs over RLFAs or DLFAs, nor is there a	longer a necessity to prefer LFAs over RLFAs or DLFAs, nor is there a
	need to minimize the number of RLFA or DLFA repair nodes.</t>	need to minimize the number of RLFA or DLFA repair nodes.</t>


	<t>Utilizing SR makes the requirement unnecessary to establish additional	<!--[rfced] To improve readability, may we update "makes the requirement
		unnecessary" to "eliminates the need" in the sentence below?

		Original:
		Utilizing SR makes the requirement unnecessary to establish
		additional state within the network for enforcing explicit Fast
		Reroute (FRR) paths.

		Perhaps:
		Utilizing SR also eliminates the need to establish an
		additional state within the network for enforcing explicit Fast
		Reroute (FRR) paths.
		-->

		<t>Utilizing SR makes the requirement unnecessary to establish an addition
		al
	state within the network for enforcing explicit Fast Reroute (FRR) paths.	state within the network for enforcing explicit Fast Reroute (FRR) paths.

	This spares the nodes from maintaining supplementary state and frees the	This spares the nodes from maintaining a supplementary state and frees the
	operator from the necessity to implement additional protocols or protocol	operator from the necessity to implement additional protocols or protocol
	sessions solely to augment protection coverage.</t>	sessions solely to augment protection coverage.</t>

		<t>TI-LFA also brings the benefit of the ability to provide a backup
	<t>TI-LFA also brings	path that follows the expected post-convergence path considering a
	the benefit of the ability to provide a backup path that follows the	particular failure, which reduces the need of locally configured
	expected post-convergence path considering a particular failure which	policies that influence the backup path selection <xref
	reduces the need of locally configured policies that influence the backup	target="RFC7916" format="default"/>. The easiest way to express the
	path selection (<xref target="RFC7916"/>). The easiest way to express the	expected post-convergence path in a loop-free manner is to encode it as
	expected post-convergence path in a loop-free manner is to encode it as a	a list of adjacency segments. However, this may create a long segment
	list of adjacency segments. However, this may create a long segment list	list that some hardware may not be able to program. One of the
	that some hardware may not be able to program. One of the challenges of	challenges of TI-LFA is to encode the expected post-convergence path by
	TI-LFA is to encode the expected post-convergence path by combining	combining adjacency segments and node segments. Each implementation may
	adjacency segments and node segments. Each implementation may
	independently develop its own algorithm for optimizing the ordered	independently develop its own algorithm for optimizing the ordered
	segment list. This document provides an outline of the fundamental	segment list. This document provides an outline of the fundamental
	concepts applicable to constructing the SR backup path, along with the	concepts applicable to constructing the SR backup path, along with the

	related dataplane procedures. <xref target="advantages-post-conv-path"/>	related dataplane procedures. <xref target="advantages-post-conv-path"
	describes some of the post-convergence path related aspects of TI-LFA in	format="default"/> contains a more detailed description of some of the
	more detail.</t>	aspects of TI-LFA related to post-convergence path.</t>

	<t><xref target="terminology"/> defines the main notations used in the
	document. They are in line with <xref target="RFC5714"/>.</t>

	<t><xref target="base"/> defines the main principles of TI-LFA backup
	path computation.</t>

	<t><xref target="pq_space_intersect"/> suggests to compute the P-Space
	and Q-Space properties defined in <xref target="terminology"/>, for the
	specific case of nodes lying over the post-convergence paths towards the
	protected destinations.</t>

	<t>Using the properties defined in <xref target="pq_space_intersect"/>,
	<xref target="tilfa_repair_path"/> describes how to compute protection
	lists that encode a loop-free post-convergence path towards the
	destination.</t>

	<t><xref target="repairlist"/> defines the segment operations to be
	applied by the PLR to ensure consistency with the forwarding state of
	the repair node.</t>

	<t><xref target="dataplane"/> discusses aspects that are specific to the
	dataplane.</t>


	<t><xref target="tilfa-sr-algo"/> discusses relationship between TI-LFA	<!-- [rfced] To improve readability, we have reformatted the text that
	and the SR-algorithm.</t>	appears at the end of the Introduction into a bulleted list. Please review.


	<t>Certain considerations are needed when adjacency segments are used in a	In addition, may we adjust these three items for consistency with the other
	repare list. <xref target="adj-sid-repair-list"/> provides an overview	list items (so that each list item begins with the section number it refers
	of these considerations.</t>	to)?


	<t><xref target="security"/> discusses security considerations.</t>	Note: The section numbers in this document have changed so they may
		appear differently in the "Perhaps" text.


	<t><xref target="advantages-post-conv-path"/> highlights advantages of	Original:
	using the expected post-convergence path during FRR.</t>	Using the properties defined in Section 5, Section 6 describes how to
		compute protection lists that encode a loop-free post-convergence
		path towards the destination.
		...
		Certain considerations are needed when adjacency segments are used in
		a repare list. Section 10 provides an overview of these
		considerations.
		...
		By implementing the algorithms detailed in this document within
		actual service provider and large enterprise network environments,
		real-life measurements are presented regarding the number of SIDs
		utilized by repair paths. These measurements are summarized in
		Appendix B.


	<t>By implementing the algorithms detailed in this document within actual	Perhaps:
	service provider and large enterprise network environments, real-life	* Section 5 describes how to compute protection lists that encode a
	measurements are presented regarding the number of SIDs utilized by	loop-free post-convergence path towards the destination using the
	repair paths. These measurements are summarized in <xref target="analysis"	properties defined in Section 4.
	/>.</t>	...
		* Section 9 provides an overview of the certain considerations that
		are needed when adjacency segments are used in a repair list.
		...
		* Appendix B summarizes the measurements from implementing the
		algorithms detailed in this document within actual service
		provider and large enterprise network environments. Real-life
		measurements are presented regarding the number of SIDs utilized
		by repair paths.
		-->


		<t>This document is structured as follows:</t>
		<ul>
		<li><xref target="terminology" format="default"/> defines the main
		notations used in the document. They are in line with <xref
		target="RFC5714" format="default"/>.</li>
		<li><xref target="base" format="default"/> defines the main principles of
		TI-LFA backup path computation.</li>
		<li><xref target="pq_space_intersect" format="default"/> suggests to
		compute the P-Space and Q-Space properties defined in <xref
		target="terminology" format="default"/> for the specific case of nodes
		lying over the post-convergence paths towards the protected
		destinations.</li>
		<li>Using the properties defined in <xref target="pq_space_intersect"
		format="default"/>, <xref target="tilfa_repair_path" format="default"/>
		describes how to compute protection lists that encode a loop-free
		post-convergence path towards the destination.</li>
		<li><xref target="repairlist" format="default"/> defines the segment opera
		tions to be
		applied by the PLR to ensure consistency with the forwarding state of
		the repair node.</li>
		<li><xref target="dataplane" format="default"/> discusses aspects that are
		specific to the
		dataplane.</li>
		<li><xref target="tilfa-sr-algo" format="default"/> discusses the relation
		ship between TI-LFA
		and the SR algorithm.</li>
		<li>Certain considerations are needed when adjacency segments are used
		in a repair list. <xref target="adj-sid-repair-list" format="default"/>
		provides an overview of these considerations.</li>
		<li><xref target="security" format="default"/> discusses security consider
		ations.</li>
		<li><xref target="advantages-post-conv-path" format="default"/> highlights
		advantages of
		using the expected post-convergence path during FRR.</li>
		<li>By implementing the algorithms detailed in this document within
		actual service provider and large enterprise network environments,
		real-life measurements are presented regarding the number of SIDs
		utilized by repair paths. These measurements are summarized in <xref
		target="analysis" format="default"/>.</li>
		</ul>
	</section>	</section>


	<section anchor="terminology" title="Terminology">	<section anchor="terminology" numbered="true" toc="default">
	<t>The main notations used in this document are defined as follows.</t>	<name>Terminology</name>

	<t>The terms "old" and "new" topologies refer to the Link State Database
	(LSDB) state before and after the considered failure, respectively.</t>

	<t>SPT_old(R) is the Shortest Path Tree rooted at node R in the initial
	state of the network.</t>


	<t>SPT_new(R, X) is the Shortest Path Tree rooted at node R in the state	<section anchor="acronyms" numbered="true" toc="default">
	of the network after the resource X has failed.</t>	<name>Abbreviations and Notations</name>
		<dl spacing="normal" newline="false">
		<dt>DLFA:</dt><dd>Directed Loop-Free Alternate</dd>
		<dt>FRR:</dt><dd>Fast Reroute</dd>
		<dt>IGP:</dt><dd>Interior Gateway Protocol</dd>
		<dt>LFA:</dt><dd>Loop-Free Alternate</dd>
		<dt>LSDB:</dt><dd>Link State Database</dd>
		<dt>PLR:</dt><dd>Point of Local Repair</dd>
		<dt>RL:</dt><dd>Repair List</dd>
		<dt>RLFA:</dt><dd>Remote Loop-Free Alternate</dd>
		<dt>SID:</dt><dd>Segment Identifier</dd>
		<dt>SPF:</dt><dd>Shortest Path First</dd>
		<dt>SPT:</dt><dd>Shortest Path Tree</dd>
		<dt>SR:</dt><dd>Segment Routing</dd>
		<dt>SRLG:</dt><dd>Shared Risk Link Group</dd>
		<dt>TI-LFA:</dt><dd>Topology Independent Loop-Free Alternate</dd>
		</dl>


	<t>PLR stands for "Point of Local Repair". It is the router that applies	<!-- [rfced] FYI - The main notations in the Terminology section were
	fast traffic restoration after detecting failure in a directly attached	formatted inconsistently, so we have reformatted those items into a
	link, set of links, and/or node.</t>	bulleted list.


	<t>Similar to <xref target="RFC7490"/>, the concept of P-Space and	Please review the changes to the following items in particular:
	Q-Space is used for TI-LFA.</t>


	<t>The P-space P(R,X) of a router R with regard to a resource X (e.g. a	Original:
	link S-F, a node F, or a SRLG) is the set of routers reachable from R	Primary Interface: Primary Outgoing Interface: One of the outgoing
	using the pre-convergence shortest paths without any of those paths	interfaces towards a destination according to the IGP link-state
	(including equal-cost path splits) transiting through X. A P node is a	protocol
	node that belongs to the P-space.</t>


	<t>Consider the set of neighbors of a router R and a resource X. Exclude	Primary Link: A link connected to the primary interface
	from that set, the neighbors that are reachable from R using X. The
	Extended P-Space P'(R,X) of a node R with regard to a resource X is the
	union of the P-spaces of the neighbors in that reduced set of neighbors
	with regard to the resource X.</t>


	<t>The Q-space Q(R,X) of a router R with regard to a resource X is the	adj-sid(S-F): Adjacency Segment from node S to node F
	set of routers from which R can be reached without any path (including
	equal-cost path splits) transiting through X. A Q node is a node that
	belongs to the Q-space </t>


	<t>EP(P, Q) is an explicit SR path from a node P to a node Q.</t>	Current:
		* The primary interface and the primary outgoing interface are one of
		the outgoing interfaces towards a destination according to the IGP
		link-state protocol.


	<t>Primary Interface: Primary Outgoing Interface: One of the outgoing	* The primary link is a link connected to the primary interface.
	interfaces towards a destination according to the IGP link-state
	protocol</t>


	<t>Primary Link: A link connected to the primary interface</t>	* The adj-sid(S-F) is the adjacency segment from node S to node F.


	<t>adj-sid(S-F): Adjacency Segment from node S to node F</t>	-->


	<section anchor="conventions" title="Conventions used in this document">	<t>The main notations used in this document are defined as follows:</t>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	<ul>
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	<li>The terms "old" and "new" topologies refer to the LSDB state before
	"OPTIONAL" in this document are to be interpreted as described in BCP	and after the considered failure, respectively.</li>
	14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only	<li>SPT_old(R) is the SPT rooted at node R in the initial state of the
	when, they appear in all capitals, as shown here.</t>	network.</li>
		<li>SPT_new(R, X) is the SPT rooted at node R in the state of the
		network after the resource X has failed.</li>
		<li>The Point of Local Repair (PLR) is the router that applies
		fast traffic restoration after detecting failure in a directly attached
		link, set of links, and/or node.</li>
		<li>Similar to <xref target="RFC7490" format="default"/>, the concept of
		P-Space and
		Q-Space is used for TI-LFA.</li>
		<li>The P-space P(R,X) of a router R with regard to a resource X (e.g., a
		link S-F, a node F, or an SRLG) is the set of routers reachable from R
		using the pre-convergence shortest paths without any of those paths
		(including equal-cost path splits) transiting through X. A P node is a
		node that belongs to the P-space.</li>
		<li>Consider the set of neighbors of a router R and a resource X. Exclude
		from that set the neighbors that are reachable from R using X. The
		extended P-Space P'(R,X) of a node R with regard to a resource X is the
		union of the P-spaces of the neighbors in that reduced set of neighbors
		with regard to the resource X.</li>
		<li>The Q-space Q(R,X) of a router R with regard to a resource X is the
		set of routers from which R can be reached without any path (including
		equal-cost path splits) transiting through X. A Q node is a node that
		belongs to the Q-space.</li>
		<li>EP(P, Q) is an explicit SR path from a node P to a node Q.</li>
		<li>The primary interface and primary outgoing interface are one of the o
		utgoing
		interfaces towards a destination according to the IGP link-state
		protocol.</li>
		<li>The primary link is a link connected to the primary interface.</li>
		<li>The adj-sid(S-F) is the adjacency segment from node S to node F.</li>
		</ul>
		</section>
		<section anchor="conventions" numbered="true" toc="default">
		<name>Conventions Used in This Document</name>
		<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
		",
		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be
		interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
		target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
		</t>
	</section>	</section>


	</section>	</section>

		<section anchor="base" numbered="true" toc="default">
	<section anchor="base" title="Base principle">	<name>Base Principle</name>
	<t>The basic algorithm to compute the repair path is to pre-compute	<t>The basic algorithm to compute the repair path is to pre-compute

	SPT_new(R,X) and for each destination, encode the repair path as a	SPT_new(R,X) and, for each destination, encode the repair path as a
	loop-free segment list. One way to provide a loop-free segment list is to	loop-free segment list. One way to provide a loop-free segment list is to
	use adjacency SIDs only. However, this approach may create very long SID	use adjacency SIDs only. However, this approach may create very long SID

	lists that hardware may not be able to handle due to MSD (Maximum SID	lists that hardware may not be able to handle due to Maximum SID
	Depth) limitations.</t>	Depth (MSD) limitations.</t>

	<t>An implementation is free to use any local optimization to provide	<t>An implementation is free to use any local optimization to provide
	smaller segment lists by combining Node SIDs and Adjacency SIDs. In	smaller segment lists by combining Node SIDs and Adjacency SIDs. In

	addition, the usage of Node-SIDs allow to maximize ECMPs over the backup	addition, the usage of Node-SIDs allow for maximizing ECMPs over the backu
	path. These optimizations are out of scope of this document, however the	p
		path. These optimizations are out of scope of this document; however, the
	subsequent sections provide some guidance on how to leverage P-Spaces and	subsequent sections provide some guidance on how to leverage P-Spaces and
	Q-Spaces to optimize the size of the segment list.</t>	Q-Spaces to optimize the size of the segment list.</t>
	</section>	</section>

		<section anchor="pq_space_intersect" numbered="true" toc="default">
	<section anchor="pq_space_intersect"	<name>Intersecting P-Space and Q-Space with Post-Convergence Paths</name>
	title="Intersecting P-Space and Q-Space with post-convergence paths
	">
	<t>One of the challenges of defining an SR path following the expected	<t>One of the challenges of defining an SR path following the expected
	post-convergence path is to reduce the size of the segment list. In	post-convergence path is to reduce the size of the segment list. In

	order to reduce this segment list, an implementation MAY determine the	order to reduce this segment list, an implementation <bcp14>MAY</bcp14>
	P-Space/Extended P-Space and Q-Space properties (defined in <xref	determine the P-Space / extended P-Space and Q-Space properties (defined
	target="RFC7490"/>) of the nodes along the expected post-convergence	in <xref target="RFC7490" format="default"/>) of the nodes along the
	path from the PLR to the protected destination and compute an SR	expected post-convergence path from the PLR to the protected destination
	explicit path from P to Q when they are not adjacent. Such properties	and compute an SR explicit path from P to Q when they are not
	will be used in <xref target="tilfa_repair_path"/> to compute the TI-LFA	adjacent. Such properties will be used in <xref
		target="tilfa_repair_path" format="default"/> to compute the TI-LFA
	repair list.</t>	repair list.</t>

		<section anchor="extp_space" numbered="true" toc="default">
	<section anchor="extp_space"	<name>Extended P-Space Property Computation for a Resource X over Post-C
	title="Extended P-Space property computation for a resource X, ov	onvergence Paths</name>
	er post-convergence paths">
	<t>The objective is to determine which nodes on the post-convergence	<t>The objective is to determine which nodes on the post-convergence
	path from the PLR R to the destination D are in the extended P-space of	path from the PLR R to the destination D are in the extended P-space of
	R with regard to resource X (where X can be a link or a set of links	R with regard to resource X (where X can be a link or a set of links

	adjacent to the PLR, or a neighbor node of the PLR).</t>	adjacent to the PLR or a neighbor node of the PLR).</t>
		<t>This can be found by:</t>
	<t>This can be found by: <list style="symbols">	<ul spacing="normal">
	<t>Excluding neighbors which are not on the post-convergence path	<li>
	when computing P'(R,X)</t>	<t>excluding neighbors that are not on the post-convergence path
		when computing P'(R,X), then</t>
	<t>Then, intersecting the set of nodes belonging to the	</li>
		<li>
		<t>intersecting the set of nodes belonging to the
	post-convergence path from R to D, assuming the failure of X, with	post-convergence path from R to D, assuming the failure of X, with
	P'(R, X).</t>	P'(R, X).</t>

	</list></t>	</li>
		</ul>
	</section>	</section>

		<section anchor="q_space" numbered="true" toc="default">
	<section anchor="q_space"	<name>Q-Space Property Computation for a Resource X over Post-Convergenc
	title="Q-Space property computation for a resource X, over post	e Paths</name>
	-convergence paths">
	<t>The goal is to determine which nodes on the post-convergence path	<t>The goal is to determine which nodes on the post-convergence path
	from the Point of Local Repair (PLR) R to the destination D are in the	from the Point of Local Repair (PLR) R to the destination D are in the
	Q-Space of destination D with regard to resource X (where X can be a	Q-Space of destination D with regard to resource X (where X can be a
	link or a set of links adjacent to the PLR, or a neighbor node of the	link or a set of links adjacent to the PLR, or a neighbor node of the
	PLR).</t>	PLR).</t>


	<t>This can be found by intersecting the set of nodes belonging to the	<t>This can be found by intersecting the set of nodes belonging to the
	post-convergence path from R to D, assuming the failure of X, with	post-convergence path from R to D, assuming the failure of X, with
	Q(D, X).</t>	Q(D, X).</t>
	</section>	</section>

		<section anchor="q_space_scaling" numbered="true" toc="default">
	<section anchor="q_space_scaling"	<name>Scaling Considerations When Computing Q-Space</name>
	title="Scaling considerations when computing Q-Space">	<t><xref target="RFC7490" format="default"/> raises scaling concerns abo
	<t><xref target="RFC7490"/> raises scaling concerns about computing a	ut computing a
	Q-Space per destination. Similar concerns may affect TI-LFA	Q-Space per destination. Similar concerns may affect TI-LFA
	computation if an implementation tries to compute a reverse Shortest	computation if an implementation tries to compute a reverse Shortest

	Path Tree (<xref target="RFC7490"/>) for every destination in the	Path Tree (SPT) <xref target="RFC7490" format="default"/> for every dest ination in the
	network to determine the Q-Space. It will be up to each implementation	network to determine the Q-Space. It will be up to each implementation
	to determine the good tradeoff between scaling and accuracy of the	to determine the good tradeoff between scaling and accuracy of the
	optimization.</t>	optimization.</t>
	</section>	</section>
	</section>	</section>


	<section anchor="tilfa_repair_path" title="TI-LFA Repair path">	<!-- [rfced] To improve readability, may we break up this sentence into
		two sentences? If yes, would "the path" be the correct subject for the second
		sentence?

		Original:
		The repair list encodes the explicit, and possibly post-convergence, path to
		the destination, which avoids the protected resource X and, at the same
		time, is guaranteed to be loop-free irrespective of the state of FIBs along
		the nodes belonging to the explicit path as long as the states of the FIBs
		are programmed according to a link-state IGP.

		Perhaps:
		The repair list encodes the explicit (and possibly post-convergence) path to
		the destination, which avoids the protected resource X. At the same time,
		the path is guaranteed to be loop-free, irrespective of the state of FIBs
		along the nodes belonging to the explicit path, as long as the states of the
		FIBs are programmed according to a link-state IGP.

		-->

		<section anchor="tilfa_repair_path" numbered="true" toc="default">
		<name>TI-LFA Repair Path</name>
	<t>The TI-LFA repair path consists of an outgoing interface and a	<t>The TI-LFA repair path consists of an outgoing interface and a

	list of segments (repair list (RL)) to insert on the SR header in	list of segments (a Repair List (RL)) to insert on the SR header in
	accordance with the dataplane used. The repair list encodes the explicit,	accordance with the dataplane used. The repair list encodes the explicit,
	and possibly post-convergence, path to the destination, which avoids the	and possibly post-convergence, path to the destination, which avoids the
	protected resource X and, at the same time, is guaranteed to be loop-free	protected resource X and, at the same time, is guaranteed to be loop-free
	irrespective of the state of FIBs along the nodes belonging to the	irrespective of the state of FIBs along the nodes belonging to the
	explicit path as long as the states of the FIBs are programmed according	explicit path as long as the states of the FIBs are programmed according

	to a link-state IGP. Thus, there is no need for any co-ordination or	to a link-state IGP. Thus, there is no need for any coordination or
	message exchange between the PLR and any other router in the network.</t>	message exchange between the PLR and any other router in the network.</t>


	<t>The TI-LFA repair path is found by intersecting P(S,X) and Q(D,X) with	<t>The TI-LFA repair path is found by intersecting P(S,X) and Q(D,X) with

	the post-convergence path to D and computing the explicit SR- based path	the post-convergence path to D and computing the explicit SR-based path
	EP(P, Q) from a node P in P(S,X) to a node Q in Q(D,X) when these nodes	EP(P, Q) from a node P in P(S,X) to a node Q in Q(D,X) when these nodes

	are not adjacent along the post convergence path. The TI-LFA repair list	are not adjacent along the post-convergence path. The TI-LFA repair list
	is expressed generally as (Node-SID(P), EP(P, Q)).</t>	is expressed generally as (Node-SID(P), EP(P, Q)).</t>


	<figure anchor="sample-topo1" title="Sample topology with TI-LFA">	<figure anchor="sample-topo1">
	<artwork>	<name>Sample Topology with TI-LFA</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	S ------- N1 ----------- D	S ------- N1 ----------- D
	*\ \| \ \|	*\ \| \ \|
	* \ \| \ \|	* \ \| \ \|
	* \ \| \ \|	* \ \| \ \|
	* N2-----R1**R2 * R3	* N2-----R1**R2 * R3
	* *	* *
	N3 *********	N3 *********

	***** : link with high metric (1k)	***** : link with high metric (1k)
	----- : link with metric 1	----- : link with metric 1

		]]></artwork>
	</artwork>
	</figure>	</figure>


	<t>As an example, in <xref target="sample-topo1"/>, the focus is on the	<t>As an example, in <xref target="sample-topo1" format="default"/>, the f ocus is on the
	TI-LFA backup from S to D, considering the failure of node N1.</t>	TI-LFA backup from S to D, considering the failure of node N1.</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>
	<t>First, P(S, N1) is computed and results in [N3, N2, R1].</t>	<t>First, P(S, N1) is computed and results in [N3, N2, R1].</t>

		</li>
		<li>
	<t>Then, Q(D, N1) is computed and results in [R3].</t>	<t>Then, Q(D, N1) is computed and results in [R3].</t>

		</li>
		<li>
	<t>The expected post-convergence path from S to D considering the	<t>The expected post-convergence path from S to D considering the
	failure of N1 is <N2 -> R1 -> R2 -> R3 -> D> (we	failure of N1 is <N2 -> R1 -> R2 -> R3 -> D> (we

	are naming it PCPath in this example).</t>	are naming it "PCPath" in this example).</t>
		</li>
	<t>P(S, N1) intersection with PCPath is [N2, R1], R1 being the	<li>
	deeper downstream node in PCPath, it can be assumed to be used as P	<t>P(S, N1) intersection with PCPath is [N2, R1]. With R1 being the
	node (this is an example and an implementation could use a different	deeper downstream node in PCPath, it can be assumed to be used as a P
		node (this is an example, and an implementation could use a different
	strategy to choose the P node).</t>	strategy to choose the P node).</t>

		</li>
	<t>Q(D, N1) intersection with PCPath is [R3], so R3 is picked as Q	<li>
	node. An SR explicit path is then computed from R1 (P node) to R3 (Q	<t>Q(D, N1) intersection with PCPath is [R3], so R3 is picked as a Q
		node. An SR-explicit path is then computed from R1 (P node) to R3 (Q
	node) following PCPath (R1 -> R2 -> R3): <Adj-Sid(R1-R2),	node) following PCPath (R1 -> R2 -> R3): <Adj-Sid(R1-R2),
	Adj-Sid(R2-R3)>.</t>	Adj-Sid(R2-R3)>.</t>

	</list> As a result, the TI-LFA repair list of S for destination D	</li>
	considering the failure of node N1 is: <Node-SID(R1), Adj-Sid(R1-R2),	</ul>
	Adj-Sid(R20R3)>.</t>
		<!-- [rfced] FYI - We have updated the "0" in "Adj-Sid(R20R3)" to "-".
		Please review and let us know if further updates are needed.

		Original:
		As a result, the TI-LFA repair list of S for destination D
		considering the failure of node N1 is: <Node-SID(R1), Adj-Sid(R1-R2),
		Adj-Sid(R20R3)>

		Current:
		As a result, the TI-LFA repair list of S for destination D
		considering the failure of node N1 is: <Node-SID(R1), Adj-Sid(R1-R2),
		Adj-Sid(R2-R3)>.
		-->


		<t> As a result, the TI-LFA repair list of S for destination D
		considering the failure of node N1 is: <Node-SID(R1), Adj-Sid(R1-R2),
		Adj-Sid(R2-R3)>.</t>
	<t>Most often, the TI-LFA repair list has a simpler form, as described	<t>Most often, the TI-LFA repair list has a simpler form, as described

	in the following sections. <xref target="analysis"/> provides statistics	in the following sections. <xref target="analysis" format="default"/> prov ides statistics
	for the number of SIDs in the explicit path to protect against various	for the number of SIDs in the explicit path to protect against various
	failures.</t>	failures.</t>

		<section anchor="direct_backup" numbered="true" toc="default">
	<section anchor="direct_backup" title="FRR path using a direct neighbor">	<name>FRR Path Using a Direct Neighbor</name>
	<t>When a direct neighbor is in P(S,X) and Q(D,x) and the link to that	<t>When a direct neighbor is in P(S,X) and Q(D,x), and the link to that
	direct neighbor is on the post-convergence path, the outgoing interface	direct neighbor is on the post-convergence path, the outgoing interface
	is set to that neighbor and the repair segment list is empty.</t>	is set to that neighbor and the repair segment list is empty.</t>


	<t>This is comparable to a post-convergence LFA FRR repair.</t>	<t>This is comparable to a post-convergence LFA FRR repair.</t>
	</section>	</section>

		<section anchor="pq_backup" numbered="true" toc="default">
	<section anchor="pq_backup" title="FRR path using a PQ node">	<name>FRR Path Using a PQ Node</name>
	<t>When a remote node R is in P(S,X) and Q(D,x) and on the	<t>When a remote node R is in P(S,X) and Q(D,x) and on the
	post-convergence path, the repair list is made of a single node segment	post-convergence path, the repair list is made of a single node segment

	to R and the outgoing interface is set to the outgoing interface used	to R, and the outgoing interface is set to the outgoing interface used
	to reach R.</t>	to reach R.</t>


	<t>This is comparable to a post-convergence RLFA repair tunnel.</t>	<t>This is comparable to a post-convergence RLFA repair tunnel.</t>
	</section>	</section>

		<section anchor="adj_pq_backup" numbered="true" toc="default">
	<section anchor="adj_pq_backup"	<name>FRR Path Using a P Node and Q Node That Are Adjacent</name>
	title="FRR path using a P node and Q node that are adjacent">	<t>When a node P is in P(S,X) and a node Q is in Q(D,x), and both are on
	<t>When a node P is in P(S,X) and a node Q is in Q(D,x) and both are on	the post-convergence path and are adjacent to each other, the
	the post-convergence path and both are adjacent to each other, the	repair list is made of two segments: a node segment to P (to be
	repair list is made of two segments: A node segment to P (to be
	processed first), followed by an adjacency segment from P to Q.</t>	processed first), followed by an adjacency segment from P to Q.</t>


	<t>This is comparable to a post-convergence DLFA (LFA with directed	<t>This is comparable to a post-convergence DLFA (LFA with directed
	forwarding) repair tunnel.</t>	forwarding) repair tunnel.</t>
	</section>	</section>

		<section anchor="remote_pq_backup" numbered="true" toc="default">
	<section anchor="remote_pq_backup"	<name>Connecting Distant P and Q Nodes Along Post-Convergence Paths</nam
	title="Connecting distant P and Q nodes along post-convergence pa	e>
	ths">
	<t>In some cases, there is no adjacent P and Q node along the post-	<t>In some cases, there is no adjacent P and Q node along the post-

	convergence path. As mentioned in <xref target="base"/>, a list of	convergence path. As mentioned in <xref target="base" format="default"/> , a list of
	adjacency SIDs can be used to encode the path between P and Q.	adjacency SIDs can be used to encode the path between P and Q.
	However, the PLR can perform additional computations to compute a list	However, the PLR can perform additional computations to compute a list
	of segments that represent a loop-free path from P to Q. How these	of segments that represent a loop-free path from P to Q. How these
	computations are done is out of scope of this document and is left to	computations are done is out of scope of this document and is left to
	implementation.</t>	implementation.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="repairlist" numbered="true" toc="default">
	<section anchor="repairlist" title="Building TI-LFA repair lists for SR Segm	<name>Building TI-LFA Repair Lists for SR Segments</name>
	ents">
	<t>The following sections describe how to build the repair lists using	<t>The following sections describe how to build the repair lists using

	the terminology defined in <xref target="RFC8402"/>. The procedures	the terminology defined in <xref target="RFC8402" format="default"/>. The
	described in this section are equally applicable to both SR-MPLS and	procedures
	SRv6 dataplane, while the dataplane-specific considerations are	described in this section are equally applicable to both the Segment Routi
	described in <xref target="dataplane"/>.</t>	ng over MPLS (SR-MPLS) and
		the Segment Routing over IPv6 (SRv6) dataplane, while the dataplane-specif
	<t>In this section, the process by which a protecting router S handles	ic considerations are
		described in <xref target="dataplane" format="default"/>.</t>
		<t>This section explains the process by which a protecting router S handle
		s
	the active segment of a packet upon the failure of its primary outgoing	the active segment of a packet upon the failure of its primary outgoing

	interface for the packet, S-F, is explained. The failure of the primary	interface for the packet S-F. The failure of the primary
	outgoing interface may occur due to various triggers, such as link	outgoing interface may occur due to various triggers, such as link
	failure, neighbor node failure, and others.</t>	failure, neighbor node failure, and others.</t>

		<section anchor="link-protect-node-sid" numbered="true" toc="default">
	<section anchor="link-protect-node-sid"	<name>The Active Segment Is a Node Segment</name>
	title="The active segment is a node segment">	<t>The active segment <bcp14>MUST</bcp14> be kept on the SR header uncha
	<t>The active segment MUST be kept on the SR header unchanged and the	nged and the
	repair list MUST be added. The active segment becomes the first	repair list <bcp14>MUST</bcp14> be added. The active segment becomes the
		first
	segment after the repair list. The way the repair list is added depends	segment after the repair list. The way the repair list is added depends

	on the dataplane used (see <xref target="dataplane"/>).</t>	on the dataplane used (see <xref target="dataplane" format="default"/>). </t>
	</section>	</section>

		<section anchor="link-protect-adj-sid" numbered="true" toc="default">
	<section anchor="link-protect-adj-sid"	<name>The Active Segment Is an Adjacency Segment</name>
	title="The active segment is an adjacency segment">	<t>This section defines the FRR behavior applied by S for any packet
	<t>The FRR behavior applied by S for any packet received with an	received with an active adjacency segment S-F for which protection was
	active adjacency segment S-F, for which protection was enabled, is	enabled. Since protection has been enabled for the segment S-F and
	defined here. Since protection has been enabled for the segment S-F and	signaled in the IGP (for instance, using protocol extensions from
	signaled in the IGP (for instance, using protocol extensions from <xref	<xref target="RFC8667" format="default"/> and <xref target="RFC8665"
	target="RFC8667"/> and <xref target="RFC8665"/>), a calculator of any	format="default"/>), a calculator of any SR policy utilizing this
	SR policy utilizing this segment is aware that it may be transiently	segment is aware that it may be transiently rerouted out of S-F in the
	rerouted out of S-F in the event of an S-F failure.</t>	event of an S-F failure.</t>

	<t>The simplest approach for link protection of an adjacency segment	<t>The simplest approach for link protection of an adjacency segment
	S-F is to create a repair list that will carry the traffic to F. To do	S-F is to create a repair list that will carry the traffic to F. To do

	so, one or more “PUSH” operations are performed. If the repair list,	so, one or more "PUSH" operations are performed. If the repair list,
	while avoiding S-F, terminates on F, S only pushes segments of the	while avoiding S-F, terminates on F, S only pushes segments of the
	repair list. Otherwise, S pushes a node segment of F, followed by the	repair list. Otherwise, S pushes a node segment of F, followed by the
	segments of the repair list. For details on the "NEXT" and "PUSH"	segments of the repair list. For details on the "NEXT" and "PUSH"

	operations, refer to <xref target="RFC8402"/>.</t>	operations, refer to <xref target="RFC8402" format="default"/>.</t>

	<t>This method, which merges back the traffic at the remote end of the	<t>This method, which merges back the traffic at the remote end of the

	adjacency segment, has the advantage of keeping as much as possible the	adjacency segment, has the advantage of keeping as much traffic as
	traffic on the pre-failure path. When SR policies are involved and	possible on the pre-failure path. When SR policies are involved and
	strict compliance with the policy is required, an end-to-end protection	strict compliance with the policy is required, an end-to-end
	(beyond the scope of this document) should be preferred over the local	protection (beyond the scope of this document) should be preferred
	repair mechanism described above.</t>	over the local repair mechanism described above.</t>
		<t> Note, however, that when the SR source node is using Traffic
	<t> Note, however, that when the SR source node is using traffic	Engineering (TE), it will generally not be possible for the PLR to know
	engineering (TE), it will generally not be possible for the PLR to know
	what post-convergence path will be selected by the source node once it	what post-convergence path will be selected by the source node once it
	detects the failure, since computation of the TE path is a local matter	detects the failure, since computation of the TE path is a local matter
	that depends on constraints that may not be known at the	that depends on constraints that may not be known at the
	PLR. Therefore, no method applied at the PLR can guarantee protection	PLR. Therefore, no method applied at the PLR can guarantee protection
	will follow the post-convergence path.</t>	will follow the post-convergence path.</t>


	<t>The case where the active segment is followed by another adjacency	<t>The case where the active segment is followed by another adjacency
	segment is distinguished from the case where it is followed by a node	segment is distinguished from the case where it is followed by a node
	segment. Repair techniques for the respective cases are provided in the	segment. Repair techniques for the respective cases are provided in the
	following subsections.</t>	following subsections.</t>

		<section anchor="link-protect-adj-sid-adj-sid" numbered="true" toc="defa
	<section anchor="link-protect-adj-sid-adj-sid"	ult">
	title="Protecting [Adjacency, Adjacency] segment lists">	<name>Protecting [Adjacency, Adjacency] Segment Lists</name>
	<t>If the next segment in the list is an Adjacency segment, then the	<t>If the next segment in the list is an Adjacency segment, then the
	packet has to be conveyed to F.</t>	packet has to be conveyed to F.</t>

		<t>To do so, S <bcp14>MUST</bcp14> apply a "NEXT" operation on Adj-Sid
	<t>To do so, S MUST apply a "NEXT" operation on Adj-Sid(S-F) and then	(S-F) and then
	one or more “PUSH” operations. If the repair list, while avoiding	one or more "PUSH" operations. If the repair list, while avoiding
	S-F, terminates on F, S only pushes the segments of the repair list.	S-F, terminates on F, S only pushes the segments of the repair list.
	Otherwise, S pushes a node segment of F, followed by the segments of	Otherwise, S pushes a node segment of F, followed by the segments of
	the repair list. For details on the "NEXT" and "PUSH" operations,	the repair list. For details on the "NEXT" and "PUSH" operations,

	refer to <xref target="RFC8402"/>.</t>	refer to <xref target="RFC8402" format="default"/>.</t>

	<t>Upon failure of S-F, a packet reaching S with a segment list	<t>Upon failure of S-F, a packet reaching S with a segment list
	matching [adj-sid(S-F),adj-sid(F-M),...] will thus leave S with a segm ent	matching [adj-sid(S-F),adj-sid(F-M),...] will thus leave S with a segm ent
	list matching [RL(F),node(F),adj-sid(F-M),...], where RL(F) is the	list matching [RL(F),node(F),adj-sid(F-M),...], where RL(F) is the
	repair list for destination F.</t>	repair list for destination F.</t>
	</section>	</section>

		<section anchor="link-protect-adj-sid-node-sid" numbered="true" toc="def
	<section anchor="link-protect-adj-sid-node-sid"	ault">
	title="Protecting [Adjacency, Node] segment lists">	<name>Protecting [Adjacency, Node] Segment Lists</name>
	<t>If the next segment in the stack is a node segment, say for node	<t>If the next segment in the stack is a node segment, say for node
	T, the segment list on the packet matches	T, the segment list on the packet matches
	[adj-sid(S-F),node(T),...].</t>	[adj-sid(S-F),node(T),...].</t>

		<t>In this case, S <bcp14>MUST</bcp14> apply a "NEXT" operation on the
	<t>In this case, S MUST apply a "NEXT" operation on the Adjacency	Adjacency
	segment related to S-F, followed by a "PUSH" of a repair list	segment related to S-F, followed by a "PUSH" of a repair list
	redirecting the traffic to a node Q, whose path to node segment T is	redirecting the traffic to a node Q, whose path to node segment T is
	not affected by the failure.</t>	not affected by the failure.</t>


	<t>Upon failure of S-F, packets reaching S with a segment list	<t>Upon failure of S-F, packets reaching S with a segment list

	matching [adj-sid(S-F), node(T), ...], would leave S with a segment li st	matching [adj-sid(S-F), node(T), ...] would leave S with a segment lis t
	matching [RL(Q),node(T), ...].</t>	matching [RL(Q),node(T), ...].</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>


	<section anchor="dataplane" title="Dataplane specific considerations">	<section anchor="dataplane" numbered="true" toc="default">
	<section anchor="mpls-dataplane" title="MPLS dataplane considerations">	<name>Dataplane-Specific Considerations</name>
	<t>MPLS dataplane for Segment Routing is described in <xref	<section anchor="mpls-dataplane" numbered="true" toc="default">
	target="RFC8660"/>.</t>	<name>MPLS Dataplane Considerations</name>
		<t>The MPLS dataplane for Segment Routing (SR) is described in <xref tar
		get="RFC8660" format="default"/>.</t>
	<t>The following dataplane behaviors apply when creating a repair list	<t>The following dataplane behaviors apply when creating a repair list

	using an MPLS dataplane: <list style="numbers">	using an MPLS dataplane:</t>
		<ol spacing="normal" type="1"><li>
	<t>If the active segment is a node segment that has been signaled	<t>If the active segment is a node segment that has been signaled

	with penultimate hop popping and the repair list ends with an	with penultimate hop popping, and the repair list ends with an
	adjacency segment terminating on a node that advertised NEXT	adjacency segment terminating on a node that advertised the "NEXT"
	operation <xref target="RFC8402"/> of the active segment, then the	operation <xref target="RFC8402" format="default"/> of the active se
	active segment MUST be popped before pushing the repair list.</t>	gment, then the
		active segment <bcp14>MUST</bcp14> be popped before pushing the repa
	<t>If the active segment is a node segment but the other conditions	ir list.</t>
	in 1. are not met, the active segment MUST be popped then pushed	</li>
		<li>
		<t>If the active segment is a node segment, but the other conditions
		in 1. are not met, the active segment <bcp14>MUST</bcp14> be popped
		and then pushed
	again with a label value computed according to the Segment Routing	again with a label value computed according to the Segment Routing

	Global Block of Q, where Q is the endpoint of the repair	Global Block (SRGB) of Q, where Q is the endpoint of the repair
	list. Finally, the repair list MUST be pushed.</t>	list. Finally, the repair list <bcp14>MUST</bcp14> be pushed.</t>
	</list></t>	</li>
		</ol>
	</section>	</section>

		<section anchor="srv6-dataplane" numbered="true" toc="default">
	<section anchor="srv6-dataplane" title="SRv6 dataplane considerations">	<name>SRv6 Dataplane Considerations</name>
	<t>SRv6 dataplane and programming instructions are described	<t>SRv6 dataplane and programming instructions are described

	respectively in <xref target="RFC8754"/> and <xref	respectively in <xref target="RFC8754" format="default"/> and <xref
	target="RFC8986"/>.</t>	target="RFC8986" format="default"/>.</t>

	<t>The TI-LFA path computation algorithm is the same as in the SR-MPLS	<t>The TI-LFA path computation algorithm is the same as in the SR-MPLS

	dataplane. Note however that the Adjacency SIDs are typically globally	dataplane. Note, however, that the Adjacency SIDs are typically globally
	routed. In such case, there is no need for preceding an adjacency SID	routed. In such a case, there is no need for preceding an adjacency SID
	with a Prefix-SID <xref target="RFC8402"/> and the resulting repair	with a Prefix-SID <xref target="RFC8402" format="default"/>, and the res
		ulting repair
	list is likely shorter.</t>	list is likely shorter.</t>


	<t>If the traffic is protected at a Transit Node, then an SRv6 SID	<t>If the traffic is protected at a Transit Node, then an SRv6 SID
	list is added on the packet to apply the repair list. The addition of	list is added on the packet to apply the repair list. The addition of

	the repair list follows the headend behaviors as specified in section	the repair list follows the head-end behaviors as specified in
	5 of <xref target="RFC8986"/>.</t>	<xref target="RFC8986" sectionFormat="of" section="5"/>.</t>

	<t>If the traffic is protected at an SR Segment Endpoint Node, first	<t>If the traffic is protected at an SR Segment Endpoint Node, first

	the Segment Endpoint packet processing is executed. Then the packet is	the Segment Endpoint packet processing is executed. Then, the packet is
	protected as if its were a transit packet.</t>	protected as if it were a transit packet.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="tilfa-sr-algo" numbered="true" toc="default">
	<section anchor="tilfa-sr-algo" title="TI-LFA and SR algorithms">	<name>TI-LFA and SR Algorithms</name>
	<t>SR allows an operator to bind an algorithm to a prefix-SID (as	<t>SR allows an operator to bind an algorithm to a Prefix-SID (as
	defined in <xref target="RFC8402"/>. The algorithm value dictates how	defined in <xref target="RFC8402" format="default"/>). The algorithm value
		dictates how
	the path to the prefix is computed. The SR default algorithm is known	the path to the prefix is computed. The SR default algorithm is known

	has the "Shortest Path" algorithm. The SR default algorithm allows an	as the "Shortest Path" algorithm. The SR default algorithm allows an
	operator to override the IGP shortest path by using local policies. When	operator to override the IGP shortest path by using local policies. When
	TI-LFA uses Node-SIDs associated with the default algorithm, there is no	TI-LFA uses Node-SIDs associated with the default algorithm, there is no

	guarantee that the path will be loop-free as a local policy may have	guarantee that the path will be loop-free, as a local policy may have
	overriden the expected IGP path. As the local policies are defined by	overridden the expected IGP path. As the local policies are defined by
	the operator, it becomes the responsibility of this operator to ensure	the operator, it becomes the responsibility of this operator to ensure
	that the deployed policies do not affect the TI-LFA deployment. It	that the deployed policies do not affect the TI-LFA deployment. It

	should be noted that such situation can already happen today with	should be noted that such a situation can already happen today with
	existing mechanisms as remote LFA.</t>	existing mechanisms such as RLFA.</t>
		<t><xref target="RFC9350" format="default"/> defines a Flexible Algorithm
	<t><xref target="RFC9350"/> defines a flexible algorithm (FlexAlgo)	framework to be associated with Prefix-SIDs. A Flexible Algorithm allows a
	framework to be associated with Prefix-SIDs. FlexAlgo allows a user to	user to
	associate a constrained path to a Prefix-SID rather than using the	associate a constrained path to a Prefix-SID rather than using the

	regular IGP shortest path. An implementation MAY support TI-LFA to	regular IGP shortest path. An implementation <bcp14>MAY</bcp14> support TI
	protect Node-SIDs associated with a Flex Algo. In such a case, rather	-LFA to
		protect Node-SIDs associated with a Flexible Algorithm. In such a case, ra
		ther
	than computing the expected post-convergence path based on the regular	than computing the expected post-convergence path based on the regular

	SPF, an implementation SHOULD use the constrained SPF algorithm bound to	SPF, an implementation <bcp14>SHOULD</bcp14> use the constrained SPF algor
	the Flex Algo (using the Flex Algo Definition) instead of the regular	ithm bound to
		the Flexible Algorithm (using the Flexible Algorithm Definition) instead o
		f the regular
	Dijkstra in all the SPF/rSPF computations that are occurring during the	Dijkstra in all the SPF/rSPF computations that are occurring during the
	TI-LFA computation. This includes the computation of the P-Space and	TI-LFA computation. This includes the computation of the P-Space and
	Q-Space as well as the post-convergence path. Furthermore, the	Q-Space as well as the post-convergence path. Furthermore, the

	implementation SHOULD only use Node-SIDs/Adj-SIDs bound to the Flex Algo	implementation <bcp14>SHOULD</bcp14> only use Node-SIDs/Adj-SIDs bound to the Flexible Algorithm
	and/or unprotected Adj-SIDs of the regular SPF to build the repair	and/or unprotected Adj-SIDs of the regular SPF to build the repair

	list. The use of regular Dijkstra for the TI-LFA computation or building	list. The use of regular Dijkstra for the TI-LFA computation or for buildi
	of the repair path using SIDs other than those recommended does not	ng
	ensure that the traffic going over TI-LFA repair path during the	the repair path using SIDs other than those recommended does not
	fast-reroute period is honoring the Flex Algo constraints.</t>	ensure that the traffic going over the TI-LFA repair path during the
		FRR period is honoring the Flexible Algorithm constraints.</t>
	</section>	</section>

		<section anchor="adj-sid-repair-list" numbered="true" toc="default">
	<section anchor="adj-sid-repair-list"	<name>Usage of Adjacency Segments in the Repair List</name>
	title="Usage of Adjacency segments in the repair list">
	<t>The repair list of segments computed by TI-LFA may contain one or	<t>The repair list of segments computed by TI-LFA may contain one or
	more adjacency segments. An adjacency segment may be protected or not	more adjacency segments. An adjacency segment may be protected or not
	protected.</t>	protected.</t>


	<figure anchor="cascaded-frr">	<figure anchor="cascaded-frr">

	<artwork>	<artwork name="" type="" align="left" alt=""><![CDATA[

	S --- R2 --- R3 ---- R4 --- R5 --- D	S --- R2 --- R3 ---- R4 --- R5 --- D
	* \| \ *	* \| \ *
	* \| \ *	* \| \ *
	R7 ** R8	R7 ** R8
	* \|	* \|
	* \|	* \|
	R9 -- R10	R9 -- R10

		]]></artwork>
	</artwork>
	</figure>	</figure>

		<t>In <xref target="cascaded-frr" format="default"/>, all the metrics are
	<t>In <xref target="cascaded-frr"/>, all the metrics are equal to 1	equal to 1
	except R2-R7,R7-R8,R8-R4,R7-R9 which have a metric of 1000. Considering	except R2-R7,R7-R8,R8-R4,R7-R9, which have a metric of 1000. Considering
	R2 as a PLR to protect against the failure of node R3 for the traffic	R2 as a PLR to protect against the failure of node R3 for the traffic
	S->D, the repair list computed by R2 will be	S->D, the repair list computed by R2 will be

	[adj-sid(R7-R8),adj-sid(R8-R4)] and the outgoing interface will be to	[adj-sid(R7-R8),adj-sid(R8-R4)], and the outgoing interface will be to
	R7. If R3 fails, R2 pushes the repair list onto the incoming packet to	R7. If R3 fails, R2 pushes the repair list onto the incoming packet to
	D. During the FRR, if R7-R8 fails and if TI-LFA has picked a protected	D. During the FRR, if R7-R8 fails and if TI-LFA has picked a protected
	adjacency segment for adj-sid(R7-R8), R7 will push an additional repair	adjacency segment for adj-sid(R7-R8), R7 will push an additional repair

	list onto the packet following the procedures defined in <xref	list onto the packet following the procedures defined in <xref target="rep
	target="repairlist"/>.</t>	airlist" format="default"/>.</t>

		<!--[rfced] May we update "non protected" to "unprotected" in the
		sentence below?

		Original:
		To avoid the possibility of this double FRR activation, an
		implementation of TI-LFA MAY pick only non protected adjacency
		segments when building the repair list.

		Perhaps:
		To avoid the possibility of this double FRR activation, an
		implementation of TI-LFA MAY pick only unprotected adjacency
		segments when building the repair list.
		-->

	<t>To avoid the possibility of this double FRR activation, an	<t>To avoid the possibility of this double FRR activation, an

	implementation of TI-LFA MAY pick only non protected adjacency segments	implementation of TI-LFA <bcp14>MAY</bcp14> pick only non-protected adjace
	when building the repair list. However, this is important to note that	ncy segments
		when building the repair list. However, it is important to note that
	FRR in general is intended to protect for a single pre-planned failure.	FRR in general is intended to protect for a single pre-planned failure.
	If the failure that happens is worse than expected or multiple failures	If the failure that happens is worse than expected or multiple failures
	happen, FRR is not guaranteed to work. In such a case, fast IGP	happen, FRR is not guaranteed to work. In such a case, fast IGP
	convergence remains important to restore traffic as quickly as	convergence remains important to restore traffic as quickly as
	possible.</t>	possible.</t>


	</section>	</section>

		<section anchor="security" numbered="true" toc="default">
	<section anchor="security" title="Security Considerations">	<name>Security Considerations</name>
	<t>The techniques described in this document are internal functionalities	<t>The techniques described in this document are internal functionalities
	to a router that can guarantee an upper bound on the time taken to	to a router that can guarantee an upper bound on the time taken to
	restore traffic flow upon the failure of a directly connected link or	restore traffic flow upon the failure of a directly connected link or
	node. As these techniques steer traffic to the post-convergence path as	node. As these techniques steer traffic to the post-convergence path as
	quickly as possible, this serves to minimize the disruption associated	quickly as possible, this serves to minimize the disruption associated

	with a local failure which can be seen as a modest security	with a local failure, which can be seen as a modest security
	enhancement. The protection mechanisms does not protect external	enhancement. The protection mechanism does not protect external
	destinations, but rather provides quick restoration for destination that	destinations, but rather provides quick restoration for destinations that
	are internal to a routing domain.</t>	are internal to a routing domain.</t>

		<t>The security considerations described in <xref target="RFC5286" format=
	<t>Security considerations described in <xref target="RFC5286"/> and	"default"/> and
	<xref target="RFC7490"/> apply to this document. Similarly, as the	<xref target="RFC7490" format="default"/> apply to this document. Similarl
	solution described in the document is based on Segment Routing	y, as the
	technology, reader should be aware of the security considerations	solution described in this document is based on SR
	related to this technology (<xref target="RFC8402"/>) and its dataplane	technology, the reader should be aware of the security considerations
	instantiations (<xref target="RFC8660"/>, <xref target="RFC8754"/> and	related to this technology (see <xref target="RFC8402" format="default"/>)
	<xref target="RFC8986"/>). However, this document does not introduce	and its dataplane
	additional security concern.</t>	instantiations (see <xref target="RFC8660" format="default"/>, <xref targe
	</section>	t="RFC8754" format="default"/>, and
		<xref target="RFC8986" format="default"/>). However, this document does no
	<section anchor="iana" title="IANA Considerations">	t introduce
	<t>No requirements for IANA</t>	additional security concerns.</t>
	</section>

	<section anchor="contributors" title="Contributors">
	<t>In addition to the authors listed on the front page, the following
	co-authors have also contributed to this document: <list style="symbol">
	<t>Francois Clad, Cisco Systems</t>

	<t>Pablo Camarillo, Cisco Systems</t>
	</list></t>
	</section>	</section>

		<section anchor="iana" numbered="true" toc="default">
	<section anchor="ack" title="Acknowledgments">	<name>IANA Considerations</name>
	<t>The authors would like to thank Les Ginsberg, Stewart Bryant, Alexander	<t>This document has no IANA actions.</t>
	Vainsthein, Chris Bowers, Shraddha Hedge, Wes Hardaker, Gunter Van de
	Velde and John Scudder for their valuable comments.</t>
	</section>	</section>
	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">	<displayreference target="I-D.bashandy-rtgwg-segment-routing-uloop" to="SR-L
	&RFC2119;	OOP"/>
		<references>
	&RFC7916;	<name>References</name>
		<references>
	&RFC8174;	<name>Normative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	&RFC8402;	119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	&RFC8660;	916.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	&RFC8754;	174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	&RFC8986;	402.xml"/>
	</references>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		660.xml"/>
	<references title="Informative References">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<?rfc include="reference.RFC.5714" ?>	754.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<?rfc include="reference.RFC.5715" ?>	986.xml"/>
		</references>
	<?rfc include="reference.RFC.5286" ?>	<references>
		<name>Informative References</name>
	<?rfc include="reference.RFC.6976" ?>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		714.xml"/>
	<?rfc include="reference.RFC.7490" ?>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		715.xml"/>
	<?rfc include="reference.RFC.8333" ?>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		286.xml"/>
	<?rfc include="reference.I-D.bashandy-rtgwg-segment-routing-uloop"?>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		976.xml"/>
	&FLEXALGO;	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		490.xml"/>
	&RFC9256;	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		333.xml"/>
	&RFC6571;

	&RFC8665;


	&RFC8667;	<!-- [I-D.bashandy-rtgwg-segment-routing-uloop]
		draft-bashandy-rtgwg-segment-routing-uloop-17
		IESG State: Expired as of 03/19/25.
		-->
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
		bashandy-rtgwg-segment-routing-uloop.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		350.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		256.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		571.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		665.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		667.xml"/>
		</references>
	</references>	</references>

	<section anchor="advantages-post-conv-path"	<section anchor="advantages-post-conv-path" numbered="true" toc="default">
	title="Advantages of using the expected post-convergence path durin	<name>Advantages of Using the Expected Post-Convergence Path During FRR</n
	g FRR">	ame>
	<t><xref target="RFC7916"/> raised several operational considerations	<t><xref target="RFC7916" format="default"/> raises several operational co
	when using LFA or remote LFA. <xref target="RFC7916"/> Section 3	nsiderations
		when using LFA or RLFA. <xref target="RFC7916" sectionFormat="of" section=
		"3"/>
	presents a case where a high bandwidth link between two core routers is	presents a case where a high bandwidth link between two core routers is

	protected through a PE router connected with low bandwidth links. In	protected through a Provider Edge (PE) router connected with low bandwidth links. In
	such a case, congestion may happen when the FRR backup path is	such a case, congestion may happen when the FRR backup path is

	activated. <xref target="RFC7916"/> introduces a local policy framework	activated. <xref target="RFC7916" format="default"/> introduces a local po licy framework
	to let the operator tuning manually the best alternate election based on	to let the operator tuning manually the best alternate election based on
	its own requirements.</t>	its own requirements.</t>


	<t>From a network capacity planning point of view, it is often assumed	<t>From a network capacity planning point of view, it is often assumed
	for simplicity that if a link L fails on a particular node X, the	for simplicity that if a link L fails on a particular node X, the
	bandwidth consumed on L will be spread over some of the remaining links	bandwidth consumed on L will be spread over some of the remaining links
	of X. The remaining links to be used are determined by the IGP routing	of X. The remaining links to be used are determined by the IGP routing
	considering that the link L has failed (we assume that the traffic uses	considering that the link L has failed (we assume that the traffic uses
	the post-convergence path starting from the node X). In <xref	the post-convergence path starting from the node X). In <xref

	target="figure1"/>, we consider a network with all metrics equal to 1	target="figure1" format="default"/>, we consider a network with all
	except the metrics on links used by PE1, PE2 and PE3 which are 1000. An	metrics equal to 1 except the metrics on links used by PE1, PE2, and PE3,
	easy network capacity planning method is to consider that if the link L	which are 1000. An easy network capacity planning method is to consider
	(X-B) fails, the traffic actually flowing through L will be spread over	that if the link L (X-B) fails, the traffic actually flowing through L
	the remaining links of X (X-H, X-D, X-A). Considering the IGP metrics,	will be spread over the remaining links of X (X-H, X-D,
	only X-H and X-D can be used in reality to carry the traffic flowing	X-A). Considering the IGP metrics, only X-H and X-D can be used in
	through the link L. As a consequence, the bandwidth of links X-H and X-D	reality to carry the traffic flowing through the link L. As a
	is sized according to this rule. We should observe that this capacity	consequence, the bandwidth of links X-H and X-D is sized according to
	planning policy works, however it is not fully accurate.</t>	this rule. We should observe that this capacity planning policy works;
		however, it is not fully accurate.</t>
	<t>In <xref target="figure1"/>, considering that the source of traffic	<t>In <xref target="figure1" format="default"/>, considering that the sour
		ce of traffic
	is only from PE1 and PE4, when the link L fails, depending on the	is only from PE1 and PE4, when the link L fails, depending on the
	convergence speed of the nodes, X may reroute its forwarding entries to	convergence speed of the nodes, X may reroute its forwarding entries to

	the remote PEs onto X-H or X-D; however in a similar timeframe, PE1 will	the remote PEs onto X-H or X-D; however, in a similar timeframe, PE1 will
	also reroute a subset of its traffic (the subset destined to PE2) out of	also reroute a subset of its traffic (the subset destined to PE2) out of

	its nominal path reducing the quantity of traffic received by X. The	its nominal path, reducing the quantity of traffic received by X. The
	capacity planning rule presented previously has the drawback of	capacity planning rule presented previously has the drawback of

	oversizing the network, however it allows to prevent any transient	oversizing the network; however, it allows for preventing any transient
	congestion (when for example X reroutes traffic before PE1 does).</t>	congestion (for example, when X reroutes traffic before PE1 does).</t>

	<figure anchor="figure1">	<figure anchor="figure1">

	<artwork>	<artwork name="" type="" align="left" alt=""><![CDATA[

	H --- I --- J	H --- I --- J
	\| \| \	\| \| \
	PE4 \| \| PE3	PE4 \| \| PE3
	\ \| (L) \| /	\ \| (L) \| /
	A --- X --- B --- G	A --- X --- B --- G
	/ \| \| \	/ \| \| \
	PE1 \| \| PE2	PE1 \| \| PE2
	\ \| \| /	\ \| \| /
	C --- D --- E --- F	C --- D --- E --- F

		]]></artwork>
	</artwork>
	</figure>	</figure>

	<t>Based on this assumption, in order to facilitate the operation of	<t>Based on this assumption, in order to facilitate the operation of

	FRR, and limit the implementation of local FRR policies, traffic can be	FRR and limit the implementation of local FRR policies, traffic can be
	steered by the PLR onto its expected post-convergence path during the	steered by the PLR onto its expected post-convergence path during the
	FRR phase. In our example, when link L fails, X switches the traffic	FRR phase. In our example, when link L fails, X switches the traffic
	destined to PE3 and PE2 on the post-convergence paths. This is perfectly	destined to PE3 and PE2 on the post-convergence paths. This is perfectly

	inline with the capacity planning rule that was presented before and	in line with the capacity planning rule that was presented before and
	also inline with the fact X may converge before PE1 (or any other	also in line with the fact that X may converge before PE1 (or any other
	upstream router) and may spread the X-B traffic onto the	upstream router) and may spread the X-B traffic onto the
	post-convergence paths rooted at X.</t>	post-convergence paths rooted at X.</t>

		<t>It should be noted that some networks may have a different capacity
	<t>It should be noted, that some networks may have a different capacity
	planning rule, leading to an allocation of less bandwidth on X-H and X-D	planning rule, leading to an allocation of less bandwidth on X-H and X-D
	links. In such a case, using the post-convergence paths rooted at X	links. In such a case, using the post-convergence paths rooted at X

	during FRR may introduce some congestion on X-H and X-D links. However	during FRR may introduce some congestion on X-H and X-D links. However,
	it is important to note, that a transient congestion may possibly	it is important to note that a transient congestion may possibly
	happen, even without FRR activated, for instance when X converges before	happen even without FRR activated, for instance, when X converges before
	the upstream routers. Operators are still free to use the policy	the upstream routers. Operators are still free to use the policy

	framework defined in <xref target="RFC7916"/> if the usage of the	framework defined in <xref target="RFC7916" format="default"/> if the usag e of the
	post-convergence paths rooted at the PLR is not suitable.</t>	post-convergence paths rooted at the PLR is not suitable.</t>


	<t>Readers should be aware that FRR protection is pre-computing a backup	<t>Readers should be aware that FRR protection is pre-computing a backup

	path to protect against a particular type of failure (link, node, SRLG).	path to protect against a particular type of failure (link, node, or SRLG)
	When using the post-convergence path as FRR backup path, the computed	.
		When using the post-convergence path as an FRR backup path, the computed
	post-convergence path is the one considering the failure we are	post-convergence path is the one considering the failure we are
	protecting against. This means that FRR is using an expected	protecting against. This means that FRR is using an expected
	post-convergence path, and this expected post-convergence path may be	post-convergence path, and this expected post-convergence path may be
	actually different from the post-convergence path used if the failure	actually different from the post-convergence path used if the failure
	that happened is different from the failure FRR was protecting against.	that happened is different from the failure FRR was protecting against.
	As an example, if the operator has implemented a protection against a	As an example, if the operator has implemented a protection against a
	node failure, the expected post-convergence path used during FRR will be	node failure, the expected post-convergence path used during FRR will be
	the one considering that the node has failed. However, even if a single	the one considering that the node has failed. However, even if a single
	link is failing or a set of links is failing (instead of the full node),	link is failing or a set of links is failing (instead of the full node),
	the node-protecting post-convergence path will be used. The consequence	the node-protecting post-convergence path will be used. The consequence
	is that the path used during FRR is not optimal with respect to the	is that the path used during FRR is not optimal with respect to the
	failure that has actually occurred.</t>	failure that has actually occurred.</t>


	<t>Another consideration to take into account is: while using the	<t>Another consideration to take into account is as follows: While using
	expected post-convergence path for SR traffic using node segments only	the expected post-convergence path for SR traffic using node segments
	(for instance, PE to PE traffic using shortest path) has some	only (for instance, PE to PE traffic using the shortest path) has some
	advantages, these advantages reduce when SR policies (<xref	advantages, these advantages reduce when SR policies <xref
	target="RFC9256"/>) are involved. A segment-list used in an SR policy is	target="RFC9256" format="default"/> are involved. A segment list used in
	computed to obey a set of path constraints defined locally at the	an SR policy is computed to obey a set of path constraints defined
	head-end or centrally in a controller. TI-LFA cannot be aware of such	locally at the head-end or centrally in a controller. TI-LFA cannot be
	path constraints and there is no reason to expect the TI-LFA backup path	aware of such path constraints, and there is no reason to expect the
	protecting one segments in that segment list to obey those constraints.	TI-LFA backup path protecting one segment in that segment list to obey
	When SR policies are used and the operator wants to have a backup path	those constraints. When SR policies are used and the operator wants to
	which still follows the policy requirements, this backup path should be	have a backup path that still follows the policy requirements, this
	computed as part of the SR policy in the ingress node (or central	backup path should be computed as part of the SR policy in the ingress
	controller) and the SR policy should not rely on local protection.	node (or central controller), and the SR policy should not rely on local
	Another option could be to use FlexAlgo (<xref target="RFC9350"/>) to	protection. Another option could be to use a Flexible Algorithm <xref
	express the set of constraints and use a single node segment associated	target="RFC9350" format="default"/> to express the set of constraints
	with a FlexAlgo to reach the destination. When using a node segment	and use a single node segment associated with a Flexible Algorithm to reac
	associated with a FlexAlgo, TI-LFA keeps providing an optimal backup by	h the
	applying the appropriate set of constraints. The relationship between	destination. When using a node segment associated with a Flexible Algorith
	TI-LFA and the SR-algorithm is detailed in <xref	m,
	target="tilfa-sr-algo"/>.</t>	TI-LFA keeps providing an optimal backup by applying the appropriate set
		of constraints. The relationship between TI-LFA and the SR algorithm is
		detailed in <xref target="tilfa-sr-algo" format="default"/>.</t>
	</section>	</section>

		<section anchor="analysis" numbered="true" toc="default">
	<section anchor="analysis"	<name>Analysis Based on Real Network Topologies</name>
	title="Analysis based on real network topologies">	<t>This section presents an analysis performed on real service provider an
	<t>This section presents analysis performed on real service provider and	d
	large enterprise network topologies. The objective of the analysis is to	large enterprise network topologies. The objective of the analysis is to
	assess the number of SIDs required in an explicit path when the	assess the number of SIDs required in an explicit path when the
	mechanisms described in this document are used to protect against the	mechanisms described in this document are used to protect against the
	failure scenarios within the scope of this document. The number of	failure scenarios within the scope of this document. The number of
	segments described in this section are applicable to instantiating	segments described in this section are applicable to instantiating

	segment routing over the MPLS forwarding plane.</t>	SR over the MPLS forwarding plane.</t>

	<t>The measurement below indicate that for link and local SRLG
	protection, a 1 SID repair path delivers more than 99% coverage. For
	node protection a 2 SIDs repair path yields 99% coverage.</t>


	<t>Table 1 below lists the characteristics of the networks used in our	<t>The measurement below indicates that, for link and local SRLG
		protection, a 1-SID repair path delivers more than 99% coverage. For
		node protection, a 2-SID repair path yields 99% coverage.</t>
		<t><xref target="t-1"/> below lists the characteristics of the networks us
		ed in our
	measurements. The number of links refers to the number of	measurements. The number of links refers to the number of
	"bidirectional" links (not directed edges of the graph). The	"bidirectional" links (not directed edges of the graph). The
	measurements are carried out as follows:</t>	measurements are carried out as follows:</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>
	<t>For each network, the algorithms described in this document are	<t>For each network, the algorithms described in this document are
	applied to protect all prefixes against link, node, and local SRLG	applied to protect all prefixes against link, node, and local SRLG

	failure</t>	failure.</t>
		</li>
		<li>
	<t>For each prefix, the number of SIDs used by the repair path is	<t>For each prefix, the number of SIDs used by the repair path is

	recorded</t>	recorded.</t>
		</li>
	<t>The percentage of number of SIDs are listed in Tables 2A/B, 3A/B,	<li>
	and 4A/B</t>	<t>The percentage of number of SIDs are listed in Tables <xref target=
	</list></t>	"t-2" format="counter"/>, <xref target="t-3" format="counter"/>, <xref target="t
		-4" format="counter"/>, <xref target="t-5" format="counter"/>, <xref target="t-6
		" format="counter"/>, and <xref target="t-7" format="counter"/>.</t>
		</li>
		</ul>
	<t>The measurements listed in the tables indicate that for link and	<t>The measurements listed in the tables indicate that for link and

	local SRLG protection, 1 SID repair path is sufficient to protect more	local SRLG protection, a 1-SID repair path is sufficient to protect more
	than 99% of the prefix in almost all cases. For node protection 2 SIDs	than 99% of the prefix in almost all cases. For node protection, 2-SID
	repair paths yield 99% coverage.</t>	repair paths yield 99% coverage.</t>


	<figure>	<table anchor="t-1">
	<artwork>	<name>Data Set Definition</name>
	+-------------+------------+------------+------------+------------+	<thead>
	\| Network \| Nodes \| Links \|Node-to-Link\| SRLG info? \|	<tr>
	\| \| \| \| Ratio \| \|	<th>Network</th>
	+-------------+------------+------------+------------+------------+	<th>Nodes</th>
	\| T1 \| 408 \| 665 \| 1.63 \| Yes \|	<th>Links</th>
	+-------------+------------+------------+------------+------------+	<th>Node-to-Link Ratio</th>
	\| T2 \| 587 \| 1083 \| 1.84 \| No \|	<th>SRLG Info?</th>
	+-------------+------------+------------+------------+------------+	</tr>
	\| T3 \| 93 \| 401 \| 4.31 \| Yes \|	</thead>
	+-------------+------------+------------+------------+------------+	<tbody>
	\| T4 \| 247 \| 393 \| 1.59 \| Yes \|	<tr>
	+-------------+------------+------------+------------+------------+	<td>T1</td>
	\| T5 \| 34 \| 96 \| 2.82 \| Yes \|	<td>408</td>
	+-------------+------------+------------+------------+------------+	<td>665</td>
	\| T6 \| 50 \| 78 \| 1.56 \| No \|	<td>1.63</td>
	+-------------+------------+------------+------------+------------+	<td>Yes</td>
	\| T7 \| 82 \| 293 \| 3.57 \| No \|	</tr>
	+-------------+------------+------------+------------+------------+	<tr>
	\| T8 \| 35 \| 41 \| 1.17 \| Yes \|	<td>T2</td>
	+-------------+------------+------------+------------+------------+	<td>587</td>
	\| T9 \| 177 \| 1371 \| 7.74 \| Yes \|	<td>1083</td>
	+-------------+------------+------------+------------+------------+	<td>1.84</td>
	Table 1: Data Set Definition	<td>No</td>
	</artwork>	</tr>
	</figure>	<tr>
		<td>T3</td>
		<td>93</td>
		<td>401</td>
		<td>4.31</td>
		<td>Yes</td>
		</tr>
		<tr>
		<td>T4</td>
		<td>247</td>
		<td>393</td>
		<td>1.59</td>
		<td>Yes</td>
		</tr>
		<tr>
		<td>T5</td>
		<td>34</td>
		<td>96</td>
		<td>2.82</td>
		<td>Yes</td>
		</tr>
		<tr>
		<td>T6</td>
		<td>50</td>
		<td>78</td>
		<td>1.56</td>
		<td>No</td>
		</tr>
		<tr>
		<td>T7</td>
		<td>82</td>
		<td>293</td>
		<td>3.57</td>
		<td>No</td>
		</tr>
		<tr>
		<td>T8</td>
		<td>35</td>
		<td>41</td>
		<td>1.17</td>
		<td>Yes</td>
		</tr>
		<tr>
		<td>T9</td>
		<td>177</td>
		<td>1371</td>
		<td>7.74</td>
		<td>Yes</td>
		</tr>
		</tbody>
		</table>

	<t>The rest of this section presents the measurements done on the actual	<t>The rest of this section presents the measurements done on the actual

	topologies. The convention that we use is as follows</t>	topologies. The conventions that we use are as follows:</t>
		<ul spacing="normal">
	<t><list style="symbols">	<li>
	<t>0 SIDs: the calculated repair path starts with a directly	<t>0 SIDs: The calculated repair path starts with a directly
	connected neighbor that is also a loop free alternate, in which case	connected neighbor that is also a loop-free alternate; in which case,
	there is no need to explicitly route the traffic using additional	there is no need to explicitly route the traffic using additional

	SIDs. This scenario is described in <xref	SIDs. This scenario is described in <xref target="direct_backup" forma
	target="direct_backup"/>.</t>	t="default"/>.</t>
		</li>
	<t>1 SIDs: the repair node is a PQ node, in which case only 1 SID is	<li>
		<t>1 SID: The repair node is a PQ node; in which case, only 1 SID is
	needed to guarantee a loop-free path. This scenario is covered in	needed to guarantee a loop-free path. This scenario is covered in

	<xref target="pq_backup"/>.</t>	<xref target="pq_backup" format="default"/>.</t>
		</li>
		<li>
	<t>2 or more SIDs: The repair path consists of 2 or more SIDs as	<t>2 or more SIDs: The repair path consists of 2 or more SIDs as

	described in <xref target="adj_pq_backup"/> and <xref	described in Sections <xref target="adj_pq_backup" format="counter"/>
	target="remote_pq_backup"/>. We do not cover the case for 2 SIDs	and
	(<xref target="adj_pq_backup"/>) separately because there was no	<xref target="remote_pq_backup" format="counter"/>. We do not cover
	granularity in the result. Also we treat the node-SID+adj-SID and	the case for 2 SIDs (<xref target="adj_pq_backup"
	node-SID + node-SID the same because they do not differ from the	format="default"/>) separately because there was no granularity in
	data plane point of view.</t>	the result. Also, we treat the node-SID + adj-SID and node-SID +
	</list></t>	node-SID the same because they do not differ from the data plane
		point of view.</t>
		</li>
		</ul>
		<t>Tables <xref target="t-2" format="counter"/> and <xref
		target="t-3" format="counter"/> below summarize the measurements on
		the number of SIDs needed for link protection.</t>


	<t>Table 2A and 2B below summarize the measurements on the number of	<table anchor="t-2">
	SIDs needed for link protection</t>	<name>Link Protection (Repair Size Distribution)</name>
		<thead>
		<tr>
		<th>Network</th>
		<th>0 SIDs</th>
		<th>1 SID</th>
		<th>2 SIDs</th>
		<th>3 SIDs</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>T1</td>
		<td>74.3%</td>
		<td>25.3%</td>
		<td>0.5%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T2</td>
		<td>81.1%</td>
		<td>18.7%</td>
		<td>0.2%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T3</td>
		<td>95.9%</td>
		<td>4.1%</td>
		<td>0.1%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T4</td>
		<td>62.5%</td>
		<td>35.7%</td>
		<td>1.8%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T5</td>
		<td>85.7%</td>
		<td>14.3%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T6</td>
		<td>81.2%</td>
		<td>18.7%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T7</td>
		<td>98.9%</td>
		<td>1.1%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T8</td>
		<td>94.1%</td>
		<td>5.9%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T9</td>
		<td>98.9%</td>
		<td>1.0%</td>
		<td>0.0%</td>
		<td>0.0%</td> </tr> </tbody> </table> <table anchor="t-3">
		<name>Link Protection (Repair Size Cumulative Distribution)</name>
		<thead>
		<tr>
		<th>Network</th>
		<th>0 SIDs</th>
		<th>1 SID</th>
		<th>2 SIDs</th>
		<th>3 SIDs</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>T1</td>
		<td>74.2%</td>
		<td>99.5%</td>
		<td>99.9%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T2</td>
		<td>81.1%</td>
		<td>99.8%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T3</td>
		<td>95.9%</td>
		<td>99.9%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T4</td>
		<td>62.5%</td>
		<td>98.2%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T5</td>
		<td>85.7%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T6</td>
		<td>81.2%</td>
		<td>99.9%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T7</td>
		<td>98.8%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T8</td>
		<td>94.1%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T9</td>
		<td>98.9%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		</tbody>
		</table>


	<figure>	<t>Tables <xref target="t-4" format="counter"/> and <xref target="t-5"
	<artwork>	format="counter"/> summarize the measurements on the number of SIDs needed for
	+-------------+------------+------------+------------+------------+	local SRLG protection.</t>
	\| Network \| 0 SIDs \| 1 SID \| 2 SIDs \| 3 SIDs \|
	+-------------+------------+------------+------------+------------+
	\| T1 \| 74.3% \| 25.3% \| 0.5% \| 0.0% \|
	+-------------+------------+------------+------------+------------+
	\| T2 \| 81.1% \| 18.7% \| 0.2% \| 0.0% \|
	+-------------+------------+------------+------------+------------+
	\| T3 \| 95.9% \| 4.1% \| 0.1% \| 0.0% \|
	+-------------+------------+------------+------------+------------+
	\| T4 \| 62.5% \| 35.7% \| 1.8% \| 0.0% \|
	+-------------+------------+------------+------------+------------+
	\| T5 \| 85.7% \| 14.3% \| 0.0% \| 0.0% \|
	+-------------+------------+------------+------------+------------+
	\| T6 \| 81.2% \| 18.7% \| 0.0% \| 0.0% \|
	+-------------+------------+------------+------------+------------+
	\| T7 \| 98.9% \| 1.1% \| 0.0% \| 0.0% \|
	+-------------+------------+------------+------------+------------+
	\| T8 \| 94.1% \| 5.9% \| 0.0% \| 0.0% \|
	+-------------+------------+------------+------------+------------+
	\| T9 \| 98.9% \| 1.0% \| 0.0% \| 0.0% \|
	+-------------+------------+------------+------------+------------+
	Table 2A: Link protection (repair size distribution)


	+-------------+------------+------------+------------+------------+	<table anchor="t-4">
	\| Network \| 0 SIDs \| 1 SID \| 2 SIDs \| 3 SIDs \|	<name>Local SRLG Protection (Repair Size Distribution)</name>
	+-------------+------------+------------+------------+------------+	<thead>
	\| T1 \| 74.2% \| 99.5% \| 99.9% \| 100.0% \|	<tr>
	+-------------+------------+------------+------------+------------+	<th>Network</th>
	\| T2 \| 81.1% \| 99.8% \| 100.0% \| 100.0% \|	<th>0 SIDs</th>
	+-------------+------------+------------+------------+------------+	<th>1 SID</th>
	\| T3 \| 95.9% \| 99.9% \| 100.0% \| 100.0% \|	<th>2 SIDs</th>
	+-------------+------------+------------+------------+------------+	<th>3 SIDs</th>
	\| T4 \| 62.5% \| 98.2% \| 100.0% \| 100.0% \|	</tr>
	+-------------+------------+------------+------------+------------+	</thead>
	\| T5 \| 85.7% \| 100.0% \| 100.0% \| 100.0% \|	<tbody>
	+-------------+------------+------------+------------+------------+	<tr>
	\| T6 \| 81.2% \| 99.9% \| 100.0% \| 100.0% \|	<td>T1</td>
	+-------------+------------+------------+------------+------------+	<td>74.2%</td>
	\| T7 \| 98,8% \| 100.0% \| 100.0% \| 100.0% \|	<td>25.3%</td>
	+-------------+------------+------------+------------+------------+	<td>0.5%</td>
	\| T8 \| 94,1% \| 100.0% \| 100.0% \| 100.0% \|	<td>0.0%</td>
	+-------------+------------+------------+------------+------------+	</tr>
	\| T9 \| 98,9% \| 100.0% \| 100.0% \| 100.0% \|	<tr>
	+-------------+------------+------------+------------+------------+	<td>T2</td>
	Table 2B: Link protection repair size cumulative distribution	<td colspan="4">No SRLG information</td>
	Table 3A and 3B summarize the measurements on the number of SIDs	</tr>
	needed for local SRLG protection.	<tr>
		<td>T3</td>
		<td>93.6%</td>
		<td>6.3%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T4</td>
		<td>62.5%</td>
		<td>35.6%</td>
		<td>1.8%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T5</td>
		<td>83.1%</td>
		<td>16.8%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T6</td>
		<td colspan="4">No SRLG information</td>
		</tr>
		<tr>
		<td>T7</td>
		<td colspan="4">No SRLG information</td>
		</tr>
		<tr>
		<td>T8</td>
		<td>85.2%</td>
		<td>14.8%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T9</td>
		<td>98.9%</td>
		<td>1.1%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		</tbody>
		</table>


	+-------------+------------+------------+------------+------------+	<table anchor="t-5">
	\| Network \| 0 SIDs \| 1 SID \| 2 SIDs \| 3 SIDs \|	<name>Local SRLG Protection (Repair Size Cumulative Distribution)</name>
	+-------------+------------+------------+------------+------------+	<thead>
	\| T1 \| 74.2% \| 25.3% \| 0.5% \| 0.0% \|	<tr>
	+-------------+------------+------------+------------+------------+	<th>Network</th>
	\| T2 \| No SRLG Information \|	<th>0 SIDs</th>
	+-------------+------------+------------+------------+------------+	<th>1 SID</th>
	\| T3 \| 93.6% \| 6.3% \| 0.0% \| 0.0% \|	<th>2 SIDs</th>
	+-------------+------------+------------+------------+------------+	<th>3 SIDs</th>
	\| T4 \| 62.5% \| 35.6% \| 1.8% \| 0.0% \|	</tr>
	+-------------+------------+------------+------------+------------+	</thead>
	\| T5 \| 83.1% \| 16.8% \| 0.0% \| 0.0% \|	<tbody>
	+-------------+------------+------------+------------+------------+	<tr>
	\| T6 \| No SRLG Information \|	<td>T1</td>
	+-------------+---------------------------------------------------+	<td>74.2%</td>
	\| T7 \| No SRLG Information \|	<td>99.5%</td>
	+-------------+------------+------------+------------+------------+	<td>99.9%</td>
	\| T8 \| 85.2% \| 14.8% \| 0.0% \| 0.0% \|	<td>100.0%</td>
	+-------------+------------+------------+------------+------------+	</tr>
	\| T9 \| 98,9% \| 1.1% \| 0.0% \| 0.0% \|	<tr>
	+-------------+------------+------------+------------+------------+	<td>T2</td>
	Table 3A: Local SRLG protection repair size distribution	<td colspan="4">No SRLG information</td>
		</tr>
		<tr>
		<td>T3</td>
		<td>93.6%</td>
		<td>99.9%</td>
		<td>100.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T4</td>
		<td>62.5%</td>
		<td>98.2%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T5</td>
		<td>83.1%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T6</td>
		<td colspan="4">No SRLG information</td>
		</tr>
		<tr>
		<td>T7</td>
		<td colspan="4">No SRLG information</td>
		</tr>
		<tr>
		<td>T8</td>
		<td>85.2%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T9</td>
		<td>98.9%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		</tbody>
		</table>


	+-------------+------------+------------+------------+------------+	<t>The remaining two tables summarize the measurements on the number of
	\| Network \| 0 SIDs \| 1 SID \| 2 SIDs \| 3 SIDs \|	SIDs needed for node protection.</t>
	+-------------+------------+------------+------------+------------+
	\| T1 \| 74.2% \| 99.5% \| 99.9% \| 100.0% \|
	+-------------+------------+------------+------------+------------+
	\| T2 \| No SRLG Information \|
	+-------------+------------+------------+------------+------------+
	\| T3 \| 93.6% \| 99.9% \| 100.0% \| 0.0% \|
	+-------------+------------+------------+------------+------------+
	\| T4 \| 62.5% \| 98.2% \| 100.0% \| 100.0% \|
	+-------------+------------+------------+------------+------------+
	\| T5 \| 83.1% \| 100.0% \| 100.0% \| 100.0% \|
	+-------------+------------+------------+------------+------------+
	\| T6 \| No SRLG Information \|
	+-------------+---------------------------------------------------+
	\| T7 \| No SRLG Information \|
	+-------------+------------+------------+------------+------------+
	\| T8 \| 85.2% \| 100.0% \| 100.0% \| 100.0% \|
	+-------------+------------+------------+------------+------------+
	\| T9 \| 98.9% \| 100.0% \| 100.0% \| 100.0% \|
	+-------------+------------+------------+------------+------------+
	Table 3B: Local SRLG protection repair size Cumulative distribution
	The remaining two tables summarize the measurements on the number of
	SIDs needed for node protection.


	+---------+----------+----------+----------+----------+----------+	<table anchor="t-6">
	\| Network \| 0 SIDs \| 1 SID \| 2 SIDs \| 3 SIDs \| 4 SIDs \|	<name>Node Protection (Repair Size Distribution)</name>
	+---------+----------+----------+----------+----------+----------+	<thead>
	\| T1 \| 49.8% \| 47.9% \| 2.1% \| 0.1% \| 0.0% \|	<tr>
	+---------+----------+----------+----------+----------+----------+	<th>Network</th>
	\| T2 \| 36,5% \| 59.6% \| 3.6% \| 0.2% \| 0.0% \|	<th>0 SIDs</th>
	+---------+----------+----------+----------+----------+----------+	<th>1 SID</th>
	\| T3 \| 73.3% \| 25.6% \| 1.1% \| 0.0% \| 0.0% \|	<th>2 SIDs</th>
	+---------+----------+----------+----------+----------+----------+	<th>3 SIDs</th>
	\| T4 \| 36.1% \| 57.3% \| 6.3% \| 0.2% \| 0.0% \|	<th>4 SIDs</th>
	+---------+----------+----------+----------+----------+----------+	</tr>
	\| T5 \| 73.2% \| 26.8% \| 0% \| 0% \| 0% \|	</thead>
	+---------+----------+----------+----------+----------+----------+	<tbody>
	\| T6 \| 78.3% \| 21.3% \| 0.3% \| 0% \| 0% \|	<tr>
	+---------+----------+----------+----------+----------+----------+	<td>T1</td>
	\| T7 \| 66.1% \| 32.8% \| 1.1% \| 0% \| 0% \|	<td>49.8%</td>
	+---------+----------+----------+----------+----------+----------+	<td>47.9%</td>
	\| T8 \| 59.7% \| 40.2% \| 0% \| 0% \| 0% \|	<td>2.1%</td>
	+---------+----------+----------+----------+----------+----------+	<td>0.1%</td>
	\| T9 \| 98.9% \| 1.0% \| 0% \| 0% \| 0% \|	<td>0.0%</td>
	+---------+----------+----------+----------+----------+----------+	</tr>
	Table 4A: Node protection (repair size distribution)	<tr>
		<td>T2</td>
		<td>36.5%</td>
		<td>59.6%</td>
		<td>3.6%</td>
		<td>0.2%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T3</td>
		<td>73.3%</td>
		<td>25.6%</td>
		<td>1.1%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T4</td>
		<td>36.1%</td>
		<td>57.3%</td>
		<td>6.3%</td>
		<td>0.2%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T5</td>
		<td>73.2%</td>
		<td>26.8%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T6</td>
		<td>78.3%</td>
		<td>21.3%</td>
		<td>0.3%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T7</td>
		<td>66.1%</td>
		<td>32.8%</td>
		<td>1.1%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T8</td>
		<td>59.7%</td>
		<td>40.2%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		<tr>
		<td>T9</td>
		<td>98.9%</td>
		<td>1.0%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		<td>0.0%</td>
		</tr>
		</tbody>
		</table>


	+---------+----------+----------+----------+----------+----------+	<table anchor="t-7">
	\| Network \| 0 SIDs \| 1 SID \| 2 SIDs \| 3 SIDs \| 4 SIDs \|	<name>Node Protection (Repair Size Cumulative Distribution)</name>
	+---------+----------+----------+----------+----------+----------+	<thead>
	\| T1 \| 49.7% \| 97.6% \| 99.8% \| 99.9% \| 100% \|	<tr>
	+---------+----------+----------+----------+----------+----------+	<th>Network</th>
	\| T2 \| 36.5% \| 96.1% \| 99.7% \| 99.9% \| 100% \|	<th>0 SIDs</th>
	+---------+----------+----------+----------+----------+----------+	<th>1 SID</th>
	\| T3 \| 73.3% \| 98.9% \| 99.9% \| 100.0% \| 100% \|	<th>2 SIDs</th>
	+---------+----------+----------+----------+----------+----------+	<th>3 SIDs</th>
	\| T4 \| 36.1% \| 93.4% \| 99.8% \| 99.9% \| 100% \|	<th>4 SIDs</th>
	+---------+----------+----------+----------+----------+----------+	</tr>
	\| T5 \| 73.2% \| 100.0% \| 100.0% \| 100.0% \| 100% \|	</thead>
	+---------+----------+----------+----------+----------+----------+	<tbody>
	\| T6 \| 78.4% \| 99.7% \| 100.0% \| 100.0% \| 100% \|	<tr>
	+---------+----------+----------+----------+----------+----------+	<td>T1</td>
	\| T7 \| 66.1% \| 98.9% \| 100.0% \| 100.0% \| 100% \|	<td>49.7%</td>
	+---------+----------+----------+----------+----------+----------+	<td>97.6%</td>
	\| T8 \| 59.7% \| 100.0% \| 100.0% \| 100.0% \| 100% \|	<td>99.8%</td>
	+---------+----------+----------+----------+----------+----------+	<td>99.9%</td>
	\| T9 \| 98.9% \| 100.0% \| 100.0% \| 100.0% \| 100% \|	<td>100.0%</td>
	+---------+----------+----------+----------+----------+----------+	</tr>
	Table 4B: Node protection (repair size cumulative distribution)	<tr>
	</artwork>	<td>T2</td>
	</figure>	<td>36.5%</td>
		<td>96.1%</td>
		<td>99.7%</td>
		<td>99.9%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T3</td>
		<td>73.3%</td>
		<td>98.9%</td>
		<td>99.9%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T4</td>
		<td>36.1%</td>
		<td>93.4%</td>
		<td>99.8%</td>
		<td>99.9%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T5</td>
		<td>73.2%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T6</td>
		<td>78.4%</td>
		<td>99.7%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T7</td>
		<td>66.1%</td>
		<td>98.9%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T8</td>
		<td>59.7%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		<tr>
		<td>T9</td>
		<td>98.9%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		<td>100.0%</td>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="ack" numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>The authors would like to thank <contact fullname="Les Ginsberg"/>,
		<contact fullname="Stewart Bryant"/>, <contact fullname="Alexander
		Vainsthein"/>, <contact fullname="Chris Bowers"/>, <contact
		fullname="Shraddha Hedge"/>, <contact fullname="Wes Hardaker"/>,
		<contact fullname="Gunter Van de Velde"/>, and <contact fullname="John
		Scudder"/> for their valuable comments.</t>
	</section>	</section>


	</back>	<section anchor="contributors" numbered="false" toc="default">
		<name>Contributors</name>
		<t>In addition to the authors listed on the front page, the following
		co-authors have also contributed to this document:</t>
		<contact fullname="Francois Clad">
		<organization>Cisco Systems</organization>
		</contact>
		<contact fullname="Pablo Camarillo">
		<organization>Cisco Systems</organization>
		</contact>
		</section>


		</back>
	</rfc>	</rfc>


		<!-- [rfced] Terminology:

		a) We note different formatting and spacing for the following items
		throughout this document (some examples below). Please review and let
		us know if/how these items should be made consistent.

		spacing and apostrophe:
		P'(R,X)
		P'(R, X)
		P(R,X)

		spacing:
		[adj-sid(S-F),node(T),...]
		[adj-sid(S-F), node(T), ...]

		b) We note different capitalization and hyphenation for the following terms
		throughout this document (see some examples below). How should these be
		updated for consistency?

		Adjacency segment vs. adjacency segment
		Adjacency SIDs vs. adjacency SIDs

		Adj-SID vs. Adj-Sid vs. adj-SID vs. adj-sid
		Node SID vs. Node-SID vs. node-SID

		P-Space vs. P-space
		Q-Space vs. Q-space

		c) May we update all instances of "dataplane" to "data plane" for consistency
		with RFC 8660?

		d) FYI - For consistency with RFC 9350, we have updated the terms below as
		follows:

		OLD -> NEW

		FlexAlgo / Flex Algo -> Flexible Algorithm
		Flex Algo Definition -> Flexible Algorithm Definition
		-->

		<!-- [rfced] Abbreviations:

		a) We note that "DLFA" has been expanded inconsistently throughout
		the document. For consistency, may we update all of these expansions
		to be "Directed Loop-Free Alternates"?

		Original:
		remote LFAs with directed forwarding (DLFA)
		DLFA: Remote LFA with Directed forwarding
		DLFA (LFA with directed forwarding)
		Directed Loop-Free Alternates (DLFA)

		Perhaps:
		Directed Loop-Free Alternates (DLFA)

		b) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be
		expanded upon first use. How may we expand "rSPF" in the text below?

		Original:
		...in all the SPF/rSPF computations that are occurring
		during the TI-LFA computation.

		c) Both the expansion and the acronym for the following terms are used
		throughout the document. Would you like to update to using the expansion
		upon first usage and the acronym for the rest of the document for consistency?

		Point of Local Repair (PLR)
		Repair List (RL)
		Segment Routing (SR)

		d) FYI - We have added expansions for the following abbreviations
		per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
		expansion in the document carefully to ensure correctness.

		Segment Routing over MPLS (SR-MPLS)
		Segment Routing over IPv6 (SRv6)
		Provider Edge (PE)
		-->

		<!-- [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.

		Note that our script did not flag any words in particular, but this should
		still be reviewed as a best practice. -->

End of changes. 206 change blocks.
	850 lines changed or deleted	1338 lines changed or added
This html diff was produced by rfcdiff 1.48.