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 "&#160;">
C.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC5384 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbhy "&#8209;">
C.5286.xml"> <!ENTITY wj "&#8288;">
<!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 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 sortrefs="yes"?> 902" submissionType="IETF" obsoletes="" updates="" xml:lang="en" sortRefs="true"
symRefs="true" tocInclude="true" version="3">
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<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>HPE</organization>
<address> <address>
<postal> <postal>
<street/> <country>USA</country>
</postal>
<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>
<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="October"/>
<area>RTG</area>
<workgroup>rtgwg</workgroup>
<keyword>example</keyword>
<keyword>TILFA</keyword>
<keyword>LFA</keyword>
<keyword>FRR</keyword>
<keyword>fast reroute</keyword>
<keyword>recovery</keyword>
<keyword>SR</keyword>
<keyword>protection</keyword>
<keyword>convergence</keyword>
<abstract> <abstract>
<t>This document presents Topology Independent Loop-free Alternate Fast <t>This document presents Topology Independent Loop-Free Alternate
Reroute (TI-LFA), aimed at providing protection of node and adjacency (TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of
segments within the Segment Routing (SR) framework. This Fast Reroute node and Adjacency segments within the Segment Routing (SR)
(FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, framework. This FRR behavior builds on proven IP FRR concepts being
remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs).
extends these concepts to provide guaranteed coverage in any It extends these concepts to provide guaranteed coverage in any
two-connected networks using a link-state IGP. An important aspect of two-connected networks using a link-state IGP. An important aspect of
TI-LFA is the FRR path selection approach establishing protection over TI-LFA is the FRR path selection approach establishing protection over
the expected post-convergence paths from the point of local repair, the expected post-convergence paths from the Point of Local Repair
reducing the operational need to control the tie-breaks among various FRR (PLR), reducing the operational need to control the tie-breaks among
options.</t> various FRR options.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="acronyms" title="Acronyms"> <section anchor="introduction" numbered="true" toc="default">
<t><list style="symbols"> <name>Introduction</name>
<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>
<t>SR: Segment Routing.</t>
<t>SRLG: Shared Risk Link Group.</t>
<t>TI-LFA: Topology Independent LFA.</t>
</list></t>
</section>
<section anchor="introduction" title="Introduction">
<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 SR, TI-LFA eliminates the need to
<t>By utilizing Segment Routing (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="I-D.bryant-ipfrr-tunnels" forma
t="default"/>. All 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 <t> Utilizing SR also eliminates the need to establish an additional
state within the network for enforcing explicit Fast Reroute (FRR) paths. state within the network for enforcing explicit Fast Reroute (FRR)
This spares the nodes from maintaining supplementary state and frees the paths. This spares the nodes from maintaining a supplementary state and
operator from the necessity to implement additional protocols or protocol frees the operator from the necessity to implement additional protocols
sessions solely to augment protection coverage.</t> or protocol 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 data plane 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>This document is structured as follows:</t>
<t><xref target="terminology"/> defines the main notations used in the <ul>
document. They are in line with <xref target="RFC5714"/>.</t> <li><xref target="terminology" format="default"/> defines the main
notations used in the document. They are in line with <xref
<t><xref target="base"/> defines the main principles of TI-LFA backup target="RFC5714" format="default"/>.</li>
path computation.</t> <li><xref target="base" format="default"/> defines the main principles of
TI-LFA backup path computation.</li>
<t><xref target="pq_space_intersect"/> suggests to compute the P-Space <li><xref target="pq_space_intersect" format="default"/> suggests to
and Q-Space properties defined in <xref target="terminology"/>, for the compute the P-space and Q-space properties defined in <xref
specific case of nodes lying over the post-convergence paths towards the target="terminology" format="default"/> for the specific case of nodes
protected destinations.</t> lying over the post-convergence paths towards the protected
destinations.</li>
<t>Using the properties defined in <xref target="pq_space_intersect"/>, <li><xref target="tilfa_repair_path" format="default"/> describes how to c
<xref target="tilfa_repair_path"/> describes how to compute protection ompute protection lists that encode a
lists that encode a loop-free post-convergence path towards the loop-free post-convergence path towards the destination using the
destination.</t> properties defined in <xref target="pq_space_intersect"
format="default"/>.</li>
<t><xref target="repairlist"/> defines the segment operations to be <li><xref target="repairlist" format="default"/> defines the segment
applied by the PLR to ensure consistency with the forwarding state of operations to be applied by the PLR to ensure consistency with the
the repair node.</t> forwarding state of the repair node.</li>
<li><xref target="dataplane" format="default"/> discusses aspects that are
<t><xref target="dataplane"/> discusses aspects that are specific to the specific to the
dataplane.</t> data plane.</li>
<li><xref target="tilfa-sr-algo" format="default"/> discusses the relation
<t><xref target="tilfa-sr-algo"/> discusses relationship between TI-LFA ship between TI-LFA
and the SR-algorithm.</t> and the SR algorithm.</li>
<li><xref target="adj-sid-repair-list" format="default"/> provides an
<t>Certain considerations are needed when adjacency segments are used in a overview of the certain considerations that are needed when Adjacency
repare list. <xref target="adj-sid-repair-list"/> provides an overview segments are used in a Repair List (RL).</li>
of these considerations.</t> <li><xref target="security" format="default"/> discusses security consider
ations.</li>
<t><xref target="security"/> discusses security considerations.</t> <li><xref target="advantages-post-conv-path" format="default"/> highlights
advantages of
<t><xref target="advantages-post-conv-path"/> highlights advantages of using the expected post-convergence path during FRR.</li>
using the expected post-convergence path during FRR.</t> <li><xref target="analysis" format="default"/> summarizes the measurements
from implementing the
<t>By implementing the algorithms detailed in this document within actual algorithms detailed in this document within actual service
service provider and large enterprise network environments, real-life provider and large enterprise network environments. Real-life
measurements are presented regarding the number of SIDs utilized by measurements are presented regarding the number of SIDs utilized
repair paths. These measurements are summarized in <xref target="analysis" by repair paths.</li>
/>.</t> </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
of the network after the resource X has failed.</t>
<t>PLR stands for "Point of Local Repair". It is the router that applies
fast traffic restoration after detecting failure in a directly attached
link, set of links, and/or node.</t>
<t>Similar to <xref target="RFC7490"/>, the concept of P-Space and
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
link S-F, a node F, or a 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.</t>
<t>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.</t>
<t>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 </t>
<t>EP(P, Q) is an explicit SR path from a node P to a node Q.</t>
<t>Primary Interface: Primary Outgoing Interface: One of the outgoing
interfaces towards a destination according to the IGP link-state
protocol</t>
<t>Primary Link: A link connected to the primary interface</t>
<t>adj-sid(S-F): Adjacency Segment from node S to node F</t>
<section anchor="conventions" title="Conventions used in this document"> <section anchor="acronyms" numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Abbreviations and Notations</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <dl spacing="normal" newline="false">
"OPTIONAL" in this document are to be interpreted as described in BCP <dt>DLFA:</dt><dd>Directed Loop-Free Alternate</dd>
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only <dt>FRR:</dt><dd>Fast Reroute</dd>
when, they appear in all capitals, as shown here.</t> <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>The main notations used in this document are defined as follows:</t>
<ul>
<li>The terms "old" and "new" topologies refer to the LSDB state before
and after the considered failure, respectively.</li>
<li>SPT_old(R) is the SPT rooted at node R in the initial state of the
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 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&nbsp;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
subsequent sections provide some guidance on how to leverage P-Spaces and path. These optimizations are out of scope of this document; however, the
Q-Spaces to optimize the size of the segment list.</t> subsequent sections provide some guidance on how to leverage P-spaces and
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
repair list.</t> target="tilfa_repair_path" format="default"/> to compute the TI-LFA
RL.</t>
<section anchor="extp_space" <section anchor="extp_space" numbered="true" toc="default">
title="Extended P-Space property computation for a resource X, ov <name>Extended P-space Property Computation for a Resource X over Post-C
er post-convergence paths"> onvergence Paths</name>
<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 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
network to determine the Q-Space. It will be up to each implementation ination in the
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"> <section anchor="tilfa_repair_path" numbered="true" toc="default">
<t>The TI-LFA repair path consists of an outgoing interface and a <name>TI-LFA Repair Path</name>
list of segments (repair list (RL)) to insert on the SR header in <t>The TI-LFA repair path consists of an outgoing interface and a list
accordance with the dataplane used. The repair list encodes the explicit, of segments (a Repair List (RL)) to insert on the SR header in
and possibly post-convergence, path to the destination, which avoids the accordance with the data plane used. The RL encodes the
protected resource X and, at the same time, is guaranteed to be loop-free explicit (and possibly post-convergence) path to the destination, which
irrespective of the state of FIBs along the nodes belonging to the avoids the protected resource X. At the same time, the RL is
explicit path as long as the states of the FIBs are programmed according guaranteed to be loop-free, irrespective of the state of FIBs along the
to a link-state IGP. Thus, there is no need for any co-ordination or nodes belonging to the explicit path, as long as the states of the FIBs
message exchange between the PLR and any other router in the network.</t> are programmed according to a link-state IGP. Thus, there is no need
for any coordination or message exchange between the PLR and any other
<t>The TI-LFA repair path is found by intersecting P(S,X) and Q(D,X) with router in the network.</t>
the post-convergence path to D and computing the explicit SR- based path <t>The TI-LFA repair path is found by intersecting P(S, X) and Q(D, X) wit
EP(P, Q) from a node P in P(S,X) to a node Q in Q(D,X) when these nodes h
are not adjacent along the post convergence path. The TI-LFA repair list 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
are not adjacent along the post-convergence path. The TI-LFA RL
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 &lt;N2 -&gt; R1 -&gt; R2 -&gt; R3 -&gt; D&gt; (we failure of N1 is &lt;N2 -&gt; R1 -&gt; R2 -&gt; R3 -&gt; D&gt; (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) following PCPath (R1 -&gt; R2 -&gt; R3): &lt;Adj-Sid(R1-R2), node. An SR-explicit path is then computed from R1 (P node) to R3 (Q
Adj-Sid(R2-R3)&gt;.</t> node) following PCPath (R1 -&gt; R2 -&gt; R3): &lt;Adj-SID(R1-R2),
</list> As a result, the TI-LFA repair list of S for destination D Adj-SID(R2-R3)&gt;.</t>
considering the failure of node N1 is: &lt;Node-SID(R1), Adj-Sid(R1-R2), </li>
Adj-Sid(R20R3)&gt;.</t> </ul>
<t> As a result, the TI-LFA RL of S for destination D
<t>Most often, the TI-LFA repair list has a simpler form, as described considering the failure of node N1 is: &lt;Node-SID(R1), Adj-SID(R1-R2),
in the following sections. <xref target="analysis"/> provides statistics Adj-SID(R2-R3)&gt;.</t>
<t>Most often, the TI-LFA RL has a simpler form, as described
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 tha
t
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 RL 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
<t>When a node P is in P(S,X) and a node Q is in Q(D,x) and both are on on
the post-convergence path and both are adjacent to each other, the the post-convergence path and are adjacent to each other, the
repair list is made of two segments: A node segment to P (to be RL 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 Directed Loop-Free
<t>This is comparable to a post-convergence DLFA (LFA with directed Alternate (DLFA) 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
<t>In some cases, there is no adjacent P and Q node along the post- post&nbhy;convergence path. As mentioned in <xref target="base"
convergence path. As mentioned in <xref target="base"/>, a list of format="default"/>, a list of Adjacency SIDs can be used to encode the
adjacency SIDs can be used to encode the path between P and Q. path between P and Q. However, the PLR can perform additional
However, the PLR can perform additional computations to compute a list computations to compute a shorter list of segments that represent a
of segments that represent a loop-free path from P to Q. How these loop-free path from P to Q. How these computations are done is out of
computations are done is out of scope of this document and is left to 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 RLs using
<t>The following sections describe how to build the repair lists using the terminology defined in <xref target="RFC8402" format="default"/>. The
the terminology defined in <xref target="RFC8402"/>. The procedures procedures
described in this section are equally applicable to both SR-MPLS and described in this section are equally applicable to both the Segment Routi
SRv6 dataplane, while the dataplane-specific considerations are ng over MPLS (SR-MPLS) and
described in <xref target="dataplane"/>.</t> the Segment Routing over IPv6 (SRv6) data plane, while the data plane-spec
ific considerations are
<t>In this section, the process by which a protecting router S handles 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 RL <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 RL. The way the RL is added depends
on the dataplane used (see <xref target="dataplane"/>).</t> on the data plane 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 an RL 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 RL,
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 RL. 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 RL. 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 RL, 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 RL.
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 RL. 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 matching [adj-sid(S-F), adj-sid(F-M), ...] will thus leave S with a se
ent gment
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> RL 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), ...]
[adj-sid(S-F),node(T),...].</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 an RL
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 matching [adj-sid(S-F), node(T), ...] would leave S with a segment lis
st 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>Data Plane-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 Data Plane Considerations</name>
<t>The MPLS data plane for SR is described in <xref target="RFC8660" for
<t>The following dataplane behaviors apply when creating a repair list mat="default"/>.</t>
using an MPLS dataplane: <list style="numbers"> <t>The following data plane behaviors apply when creating an RL
using an MPLS data plane:</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 RL ends with an
adjacency segment terminating on a node that advertised NEXT Adjacency segment terminating on the penultimate node of the
operation <xref target="RFC8402"/> of the active segment, then the active segment, then the active segment <bcp14>MUST</bcp14> be
active segment MUST be popped before pushing the repair list.</t> popped before pushing the RL.</t>
</li>
<t>If the active segment is a node segment but the other conditions <li>
in 1. are not met, the active segment MUST be popped then pushed <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 RL. Finally
list. Finally, the repair list MUST be pushed.</t> , the RL <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 Data Plane Considerations</name>
<t>SRv6 dataplane and programming instructions are described <t>SRv6 data plane 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 data plane. Note, however, that the Adjacency SIDs are typically globall
routed. In such case, there is no need for preceding an adjacency SID y
with a Prefix-SID <xref target="RFC8402"/> and the resulting repair routed. In such a case, there is no need for preceding an Adjacency SID
list is likely shorter.</t> with a Prefix-SID <xref target="RFC8402" format="default"/>, and the res
ulting RL 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 RL. The addition of
the repair list follows the headend behaviors as specified in section the RL 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
Dijkstra in all the SPF/rSPF computations that are occurring during the the Flexible Algorithm (using the Flexible Algorithm Definition) instead o
TI-LFA computation. This includes the computation of the P-Space and f the regular
Q-Space as well as the post-convergence path. Furthermore, the Dijkstra in all the SPF/reverse SPF computations that are occurring during
implementation SHOULD only use Node-SIDs/Adj-SIDs bound to the Flex Algo the
and/or unprotected Adj-SIDs of the regular SPF to build the repair TI-LFA computation. This includes the computation of the P-space and
list. The use of regular Dijkstra for the TI-LFA computation or building Q-space as well as the post-convergence path. Furthermore, the
of the repair path using SIDs other than those recommended does not implementation <bcp14>SHOULD</bcp14> only use Node-SIDs/Adj-SIDs bound to
ensure that the traffic going over TI-LFA repair path during the the Flexible Algorithm
fast-reroute period is honoring the Flex Algo constraints.</t> and/or unprotected Adj-SIDs of the regular SPF to build the RL. The use of
regular Dijkstra for the TI-LFA computation or for building
the repair path using SIDs other than those recommended does not
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 RL 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
<t>In <xref target="cascaded-frr"/>, all the metrics are equal to 1 are equal to 1 except R2-R7,R7-R8,R8-R4,R7-R9, which have a metric of
except R2-R7,R7-R8,R8-R4,R7-R9 which have a metric of 1000. Considering 1000. Considering R2 as a PLR to protect against the failure of node R3
R2 as a PLR to protect against the failure of node R3 for the traffic for the traffic S-&gt;D, the RL computed by R2 will be
S-&gt;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 RL 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 RL onto t
list onto the packet following the procedures defined in <xref he packet following the procedures defined in <xref
target="repairlist"/>.</t> target="repairlist" format="default"/>.</t>
<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 unprotected
when building the repair list. However, this is important to note that Adjacency segments when building the RL. However, it is
FRR in general is intended to protect for a single pre-planned failure. important to note that FRR in general is intended to protect for a
If the failure that happens is worse than expected or multiple failures single pre-planned failure. If the failure that happens is worse than
happen, FRR is not guaranteed to work. In such a case, fast IGP expected or multiple failures happen, FRR is not guaranteed to work. In
convergence remains important to restore traffic as quickly as such a case, fast IGP convergence remains important to restore traffic
possible.</t> as quickly as 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 data plane
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"/>
<displayreference target="I-D.bryant-ipfrr-tunnels" to="IPFRR-TUNNELS"/>
&RFC7916; <references>
<name>References</name>
&RFC8174; <references>
<name>Normative References</name>
&RFC8402; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
&RFC8660; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
916.xml"/>
&RFC8754; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
&RFC8986; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</references> 402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<references title="Informative References"> 660.xml"/>
<?rfc include="reference.RFC.5714" ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<?rfc include="reference.RFC.5715" ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
<?rfc include="reference.RFC.5286" ?> </references>
<references>
<?rfc include="reference.RFC.6976" ?> <name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.7490" ?> 714.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.8333" ?> 715.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.I-D.bashandy-rtgwg-segment-routing-uloop"?> 286.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
&FLEXALGO; 976.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
&RFC9256; 490.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&RFC6571; 333.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
&RFC8665; bashandy-rtgwg-segment-routing-uloop.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
&RFC8667; bryant-ipfrr-tunnels.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 repair path of 1 SID or less delivers more than 99% coverage
. For
node protection, a repair path of 2 SIDs or less 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
</list></t> target="t-2" format="counter"/>, <xref target="t-3"
format="counter"/>, <xref target="t-4" format="counter"/>, <xref
<t>The measurements listed in the tables indicate that for link and target="t-5" format="counter"/>, <xref target="t-6"
local SRLG protection, 1 SID repair path is sufficient to protect more format="counter"/>, and <xref target="t-7" format="counter"/>.</t>
than 99% of the prefix in almost all cases. For node protection 2 SIDs </li>
repair paths yield 99% coverage.</t> </ul>
<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%</td>
</tr>
<tr>
<td>T2</td>
<td>81.1%</td>
<td>99.8%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T3</td>
<td>95.9%</td>
<td>99.9%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T4</td>
<td>62.5%</td>
<td>98.2%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T5</td>
<td>85.7%</td>
<td>100%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T6</td>
<td>81.2%</td>
<td>99.9%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T7</td>
<td>98.8%</td>
<td>100%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T8</td>
<td>94.1%</td>
<td>100%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T9</td>
<td>98.9%</td>
<td>100%</td>
<td>100%</td>
<td>100%</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%</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%</td>
<td>0.0%</td>
</tr>
<tr>
<td>T4</td>
<td>62.5%</td>
<td>98.2%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T5</td>
<td>83.1%</td>
<td>100%</td>
<td>100%</td>
<td>100%</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%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T9</td>
<td>98.9%</td>
<td>100%</td>
<td>100%</td>
<td>100%</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%</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%</td>
</tr>
<tr>
<td>T3</td>
<td>73.3%</td>
<td>98.9%</td>
<td>99.9%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T4</td>
<td>36.1%</td>
<td>93.4%</td>
<td>99.8%</td>
<td>99.9%</td>
<td>100%</td>
</tr>
<tr>
<td>T5</td>
<td>73.2%</td>
<td>100%</td>
<td>100%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T6</td>
<td>78.4%</td>
<td>99.7%</td>
<td>100%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T7</td>
<td>66.1%</td>
<td>98.9%</td>
<td>100%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T8</td>
<td>59.7%</td>
<td>100%</td>
<td>100%</td>
<td>100%</td>
<td>100%</td>
</tr>
<tr>
<td>T9</td>
<td>98.9%</td>
<td>100%</td>
<td>100%</td>
<td>100%</td>
<td>100%</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>
 End of changes. 160 change blocks. 
961 lines changed or deleted 1292 lines changed or added

This html diff was produced by rfcdiff 1.48.