rfc9855xml2.original.xml   rfc9855.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF nsus="true" docName="draft-ietf-rtgwg-segment-routing-ti-lfa-21" number="9855" i
C.2119.xml"> pr="trust200902" submissionType="IETF" obsoletes="" updates="" xml:lang="en" sor
<!ENTITY RFC5384 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF tRefs="true" symRefs="true" tocInclude="true" prepTime="2025-10-28T21:59:38" ind
C.5286.xml"> exInclude="true" scripts="Common,Latin" tocDepth="3">
<!ENTITY RFC5714 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <link href="https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-
C.5714.xml"> ti-lfa-21" rel="prev"/>
<!ENTITY RFC5715 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <link href="https://dx.doi.org/10.17487/rfc9855" rel="alternate"/>
C.5715.xml"> <link href="urn:issn:2070-1721" rel="alternate"/>
<!ENTITY RFC6571 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6571.xml">
<!ENTITY RFC6976 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6976.xml">
<!ENTITY RFC7490 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7490.xml">
<!ENTITY RFC7916 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7916.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8333 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8333.xml">
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8402.xml">
<!ENTITY RFC8660 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8660.xml">
<!ENTITY RFC8665 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8665.xml">
<!ENTITY RFC8667 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8667.xml">
<!ENTITY RFC8754 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8754.xml">
<!ENTITY RFC8986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8986.xml">
<!ENTITY RFC9256 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9256.xml">
<!ENTITY I-D.bashandy-rtgwg-segment-routing-uloop SYSTEM "https://xml2rfc.ietf.o
rg/public/rfc/bibxml3/reference.I-D.bashandy-rtgwg-segment-routing-uloop.xml">
<!ENTITY FLEXALGO SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9350.xml">
]>
<rfc category="std" consensus="true"
docName="draft-ietf-rtgwg-segment-routing-ti-lfa-21" ipr="trust200902"
submissionType="IETF">
<!-- Generated by id2xml 1.4.4 on 2018-12-03T18:16:52Z -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc 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 Ro
Routing</title> uting</title>
<seriesInfo name="RFC" value="9855" stream="IETF"/>
<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy"> <author fullname="Ahmed Bashandy" initials="A." surname="Bashandy">
<organization>Individual</organization> <organization showOnFrontPage="true">HPE</organization>
<address> <address>
<postal> <postal>
<street/> <country>USA</country>
<city/>
<country/>
</postal> </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 showOnFrontPage="true">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 showOnFrontPage="true">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 showOnFrontPage="true">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 showOnFrontPage="true">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 showOnFrontPage="true">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 month="10" year="2025"/>
<abstract> <area>RTG</area>
<t>This document presents Topology Independent Loop-free Alternate Fast <workgroup>rtgwg</workgroup>
Reroute (TI-LFA), aimed at providing protection of node and adjacency <keyword>example</keyword>
segments within the Segment Routing (SR) framework. This Fast Reroute <keyword>TILFA</keyword>
(FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, <keyword>LFA</keyword>
remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It <keyword>FRR</keyword>
extends these concepts to provide guaranteed coverage in any <keyword>fast reroute</keyword>
<keyword>recovery</keyword>
<keyword>SR</keyword>
<keyword>protection</keyword>
<keyword>convergence</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">This document presents Topology Inde
pendent Loop-Free Alternate
(TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of
node and Adjacency segments within the Segment Routing (SR)
framework. This FRR behavior builds on proven IP FRR concepts being
LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs).
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>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9855" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-terminology">Terminology</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><
xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ab
breviations-and-notations">Abbreviations and Notations</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><
xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.
2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-co
nventions-used-in-this-do">Conventions Used in This Document</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-base-principle">Base Principle</xr
ef></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-intersecting-p-space-and-q-">Inter
secting P-space and Q-space with Post-Convergence Paths</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-extended-p-space-prope
rty-c">Extended P-space Property Computation for a Resource X over Post-Converge
nce Paths</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-q-space-property-compu
tatio">Q-space Property Computation for a Resource X over Post-Convergence Paths
</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-scaling-considerations
-when">Scaling Considerations When Computing Q-space</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-ti-lfa-repair-path">TI-LFA Repair
Path</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-frr-path-using-a-direc
t-nei">FRR Path Using a Direct Neighbor</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-frr-path-using-a-pq-no
de">FRR Path Using a PQ Node</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-frr-path-using-a-p-nod
e-and">FRR Path Using a P Node and Q Node That Are Adjacent</xref></t>
</li>
<li pn="section-toc.1-1.5.2.4">
<t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent=
"5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-connecting-distant-p-a
nd-q-">Connecting Distant P and Q Nodes Along Post-Convergence Paths</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-building-ti-lfa-repair-list">Build
ing TI-LFA Repair Lists for SR Segments</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-active-segment-is-
a-nod">The Active Segment Is a Node Segment</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-active-segment-is-
an-ad">The Active Segment Is an Adjacency Segment</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.2.2">
<li pn="section-toc.1-1.6.2.2.2.1">
<t indent="0" pn="section-toc.1-1.6.2.2.2.1.1"><xref derived
Content="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-protecting
-adjacency-adjace">Protecting [Adjacency, Adjacency] Segment Lists</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.2.2.1"><xref derived
Content="6.2.2" format="counter" sectionFormat="of" target="section-6.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-protecting
-adjacency-node-s">Protecting [Adjacency, Node] Segment Lists</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-data-plane-specific-conside">Data
Plane-Specific Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-mpls-data-plane-consid
erati">MPLS Data Plane Considerations</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-srv6-data-plane-consid
erati">SRv6 Data Plane Considerations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-ti-lfa-and-sr-algorithms">TI-LFA a
nd SR Algorithms</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-usage-of-adjacency-segments">Usage
of Adjacency Segments in the Repair List</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-advantages-of-u
sing-the-exp">Advantages of Using the Expected Post-Convergence Path During FRR<
/xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-analysis-based-
on-real-netw">Analysis Based on Real Network Topologies</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
f></t>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="acronyms" title="Acronyms"> <section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
<t><list style="symbols"> lse" pn="section-1">
<t>DLFA: Remote LFA with Directed forwarding.</t> <name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">This document outlines a local repair mecha
<t>FRR: Fast Re-route.</t> nism that leverages Segment
<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
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" s
ectionFormat="of" derivedContent="SR-LOOP"/>.</t>
<t>The term topology independent (TI) describes the capability providing <t indent="0" pn="section-1-2">The term Topology Independent (TI) describe
a loop free backup path that is effective accross all network s the capability providing
topologies. This provides a major improvement compared to LFA <xref a loop-free backup path that is effective across all network
target="RFC5286"/> and remote LFA <xref target="RFC7490"/> which cannot topologies. This provides a major improvement compared to LFA <xref target
provide a complete protection coverage in some topologies as described in ="RFC5286" format="default" sectionFormat="of" derivedContent="RFC5286"/> and RL
<xref target="RFC6571"/>.</t> FA <xref target="RFC7490" format="default" sectionFormat="of" derivedContent="RF
C7490"/>, which cannot provide a complete
<t>When the network reconverges after failure, micro-loops <xref protection coverage in some topologies as described in <xref target="RFC65
target="RFC5715"/> can form due to transient inconsistencies in 71" format="default" sectionFormat="of" derivedContent="RFC6571"/>.</t>
the forwarding tables of different routers. If it is determined <t indent="0" pn="section-1-3">When the network reconverges after failure,
that micro-loops are a significant issue in the deployment, then micro-loops <xref target="RFC5715" format="default" sectionFormat="of" derivedC
a suitable loop-free convergence method, such as one of those ontent="RFC5715"/> can form due to transient
described in <xref target="RFC5715"/>, <xref target="RFC6976"/>, inconsistencies in the forwarding tables of different routers. If it is
<xref target="RFC8333"/>, or <xref determined that micro-loops are a significant issue in the deployment,
target="I-D.bashandy-rtgwg-segment-routing-uloop"/> should be then a suitable loop-free convergence method should be implemented, such a
implemented.</t> s one of those
described in <xref target="RFC5715" format="default" sectionFormat="of" de
<t>TI-LFA operates locally at the Point of Local Repair (PLR) upon rivedContent="RFC5715"/>, <xref target="RFC6976" format="default" sectionFormat=
"of" derivedContent="RFC6976"/>, <xref target="RFC8333" format="default" section
Format="of" derivedContent="RFC8333"/>, or <xref target="I-D.bashandy-rtgwg-segm
ent-routing-uloop" format="default" sectionFormat="of" derivedContent="SR-LOOP"/
>.</t>
<t indent="0" pn="section-1-4">TI-LFA operates locally at the Point of Loc
al 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" bare="false" empty="false" indent="3" pn="section-1-5
Interior Gateway Protocol (IGP) convergence as delineated in <xref ">
target="RFC5715"/>: <li pn="section-1-5.1">
<list style="symbols"> <t indent="0" pn="section-1-5.1.1">Micro-loops that may or may not for
<t>These micro-loops occur on routes directed towards the m during the distributed IGP convergence as delineated in <xref target="RFC5715"
destination that do not traverse TI-LFA-configured paths. According format="default" sectionFormat="of" derivedContent="RFC5715"/>:
to <xref target="RFC5714"/>, the formation of such micro-loops can </t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
-1-5.1.2">
<li pn="section-1-5.1.2.1">
<t indent="0" pn="section-1-5.1.2.1.1">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" sectionFormat="of" derivedC
ontent="RFC5714"/>, the formation of such micro-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>
<t>Micro-loops that may or may not develop when the previously failed </ul>
</li>
<li pn="section-1-5.2">
<t indent="0" pn="section-1-5.2.1">Micro-loops that may or may not dev
elop 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 indent="0" pn="section-1-6">TI-LFA paths are activated from the instant
in a local link and remain in effect until the Interior Gateway Protocol the PLR detects a failure
(IGP) convergence at the PLR is fully achieved. Consequently, they are in a local link and remain in effect until the IGP convergence at the PLR
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" se
target="adj_pq_backup"/>, or <xref target="remote_pq_backup"/> of the ctionFormat="of" derivedContent="5.2"/>, <xref target="adj_pq_backup" format="co
unter" sectionFormat="of" derivedContent="5.3"/>, or <xref target="remote_pq_bac
kup" format="counter" sectionFormat="of" derivedContent="5.4"/> 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" sectionFormat="o
f" derivedContent="RFC8333"/>.</t>
<t>TI-LFA procedures are complementary to application of any micro-loop <t indent="0" pn="section-1-7">TI-LFA procedures are complementary to the
avoidance procedures in the case of link or node failure: <list application of any micro-loop
style="symbols"> avoidance procedures in the case of link or node failure:</t>
<t>Link or node failure requires some urgent action to restore the <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-8
traffic that passed thru the failed resource. TI-LFA paths are ">
pre-computed and pre-installed and therefore suitable for urgent <li pn="section-1-8.1">
recovery</t> <t indent="0" pn="section-1-8.1.1">Link or node failure requires some
<t>The paths used in the micro-loop avoidance procedures typically urgent action to restore the
traffic that passed through the failed resource. TI-LFA paths are
pre-computed and pre-installed; therefore, they are suitable for urgen
t
recovery.</t>
</li>
<li pn="section-1-8.2">
<t indent="0" pn="section-1-8.2.1">The paths used in the micro-loop av
oidance 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 indent="0" pn="section-1-9">For each destination (as specified by the I
GP) 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" format="defa
failed. In SRLG protecting mode, the destination is protected assuming ult" sectionFormat="of" derivedContent="Section 2"/>) has failed. In SRLG prote
that a configured set of links sharing fate with the primary link has cting mode, the
failed (e.g. a linecard or a set of links sharing a common transmission destination is protected assuming that a configured set of links sharing
pipe).</t> fate with the primary link has failed (e.g., a linecard or a set of links
sharing a common transmission pipe).</t>
<t>Protection techniques outlined in this document are limited to <t indent="0" pn="section-1-10">Protection techniques outlined in this doc
ument 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 indent="0" pn="section-1-11">By utilizing SR, TI-LFA eliminates the nee
<t>By utilizing Segment Routing (SR), TI-LFA eliminates the need to d 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" sectionFormat="of" derived
Loop-Free Alternates (DLFA) <xref target="RFC5714"/>. All the Segment Content="RFC7490"/> <xref target="RFC7916" format="default" sectionFormat="of" d
erivedContent="RFC7916"/> or Directed
Loop-Free Alternates (DLFAs) <xref target="I-D.bryant-ipfrr-tunnels" forma
t="default" sectionFormat="of" derivedContent="IPFRR-TUNNELS"/>. 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 indent="0" pn="section-1-12"> Utilizing SR also eliminates the need to
<t>Utilizing SR makes the requirement unnecessary to establish additional 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 indent="0" pn="section-1-13">TI-LFA also brings the benefit of the abil
<t>TI-LFA also brings ity to provide a backup
the benefit of the ability to provide a backup path that follows the path that follows the expected post-convergence path considering a
expected post-convergence path considering a particular failure which particular failure, which reduces the need of locally configured
reduces the need of locally configured policies that influence the backup policies that influence the backup path selection <xref target="RFC7916" f
path selection (<xref target="RFC7916"/>). The easiest way to express the ormat="default" sectionFormat="of" derivedContent="RFC7916"/>. The easiest way t
expected post-convergence path in a loop-free manner is to encode it as a o express the
list of adjacency segments. However, this may create a long segment list expected post-convergence path in a loop-free manner is to encode it as
that some hardware may not be able to program. One of the challenges of a list of Adjacency segments. However, this may create a long segment
TI-LFA is to encode the expected post-convergence path by combining list that some hardware may not be able to program. One of the
adjacency segments and node segments. Each implementation may challenges of TI-LFA is to encode the expected post-convergence path by
combining 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" fo
describes some of the post-convergence path related aspects of TI-LFA in rmat="default" sectionFormat="of" derivedContent="Appendix A"/> contains a more
more detail.</t> detailed description of some of the
aspects of TI-LFA related to post-convergence path.</t>
<t><xref target="terminology"/> defines the main notations used in the <t indent="0" pn="section-1-14">This document is structured as follows:</t
document. They are in line with <xref target="RFC5714"/>.</t> >
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1-1
<t><xref target="base"/> defines the main principles of TI-LFA backup 5">
path computation.</t> <li pn="section-1-15.1">
<xref target="terminology" format="default" sectionFormat="of" derived
<t><xref target="pq_space_intersect"/> suggests to compute the P-Space Content="Section 2"/> defines the main
and Q-Space properties defined in <xref target="terminology"/>, for the notations used in the document. They are in line with <xref target="RFC571
specific case of nodes lying over the post-convergence paths towards the 4" format="default" sectionFormat="of" derivedContent="RFC5714"/>.</li>
protected destinations.</t> <li pn="section-1-15.2">
<xref target="base" format="default" sectionFormat="of" derivedContent
<t>Using the properties defined in <xref target="pq_space_intersect"/>, ="Section 3"/> defines the main principles of
<xref target="tilfa_repair_path"/> describes how to compute protection TI-LFA backup path computation.</li>
lists that encode a loop-free post-convergence path towards the <li pn="section-1-15.3">
destination.</t> <xref target="pq_space_intersect" format="default" sectionFormat="of"
derivedContent="Section 4"/> suggests to
<t><xref target="repairlist"/> defines the segment operations to be compute the P-space and Q-space properties defined in <xref target="termin
applied by the PLR to ensure consistency with the forwarding state of ology" format="default" sectionFormat="of" derivedContent="Section 2"/> for the
the repair node.</t> specific case of nodes
lying over the post-convergence paths towards the protected
<t><xref target="dataplane"/> discusses aspects that are specific to the destinations.</li>
dataplane.</t> <li pn="section-1-15.4">
<xref target="tilfa_repair_path" format="default" sectionFormat="of" d
<t><xref target="tilfa-sr-algo"/> discusses relationship between TI-LFA erivedContent="Section 5"/> describes how to compute protection lists that encod
and the SR-algorithm.</t> e a
loop-free post-convergence path towards the destination using the
<t>Certain considerations are needed when adjacency segments are used in a properties defined in <xref target="pq_space_intersect" format="default" s
repare list. <xref target="adj-sid-repair-list"/> provides an overview ectionFormat="of" derivedContent="Section 4"/>.</li>
of these considerations.</t> <li pn="section-1-15.5">
<xref target="repairlist" format="default" sectionFormat="of" derivedC
<t><xref target="security"/> discusses security considerations.</t> ontent="Section 6"/> defines the segment
operations to be applied by the PLR to ensure consistency with the
<t><xref target="advantages-post-conv-path"/> highlights advantages of forwarding state of the repair node.</li>
using the expected post-convergence path during FRR.</t> <li pn="section-1-15.6">
<xref target="dataplane" format="default" sectionFormat="of" derivedCo
<t>By implementing the algorithms detailed in this document within actual ntent="Section 7"/> discusses aspects that are specific to the
service provider and large enterprise network environments, real-life data plane.</li>
measurements are presented regarding the number of SIDs utilized by <li pn="section-1-15.7">
repair paths. These measurements are summarized in <xref target="analysis" <xref target="tilfa-sr-algo" format="default" sectionFormat="of" deriv
/>.</t> edContent="Section 8"/> discusses the relationship between TI-LFA
and the SR algorithm.</li>
<li pn="section-1-15.8">
<xref target="adj-sid-repair-list" format="default" sectionFormat="of"
derivedContent="Section 9"/> provides an
overview of the certain considerations that are needed when Adjacency
segments are used in a Repair List (RL).</li>
<li pn="section-1-15.9">
<xref target="security" format="default" sectionFormat="of" derivedCon
tent="Section 10"/> discusses security considerations.</li>
<li pn="section-1-15.10">
<xref target="advantages-post-conv-path" format="default" sectionForma
t="of" derivedContent="Appendix A"/> highlights advantages of
using the expected post-convergence path during FRR.</li>
<li pn="section-1-15.11">
<xref target="analysis" format="default" sectionFormat="of" derivedCon
tent="Appendix B"/> summarizes the measurements from implementing the
algorithms detailed in this document within actual service
provider and large enterprise network environments. Real-life
measurements are presented regarding the number of SIDs utilized
by repair paths.</li>
</ul>
</section> </section>
<section anchor="terminology" numbered="true" toc="include" removeInRFC="fal
<section anchor="terminology" title="Terminology"> se" pn="section-2">
<t>The main notations used in this document are defined as follows.</t> <name slugifiedName="name-terminology">Terminology</name>
<section anchor="acronyms" numbered="true" toc="include" removeInRFC="fals
<t>The terms "old" and "new" topologies refer to the Link State Database e" pn="section-2.1">
(LSDB) state before and after the considered failure, respectively.</t> <name slugifiedName="name-abbreviations-and-notations">Abbreviations and
Notations</name>
<t>SPT_old(R) is the Shortest Path Tree rooted at node R in the initial <dl spacing="normal" newline="false" indent="3" pn="section-2.1-1">
state of the network.</t> <dt pn="section-2.1-1.1">DLFA:</dt>
<dd pn="section-2.1-1.2">Directed Loop-Free Alternate</dd>
<t>SPT_new(R, X) is the Shortest Path Tree rooted at node R in the state <dt pn="section-2.1-1.3">FRR:</dt>
of the network after the resource X has failed.</t> <dd pn="section-2.1-1.4">Fast Reroute</dd>
<dt pn="section-2.1-1.5">IGP:</dt>
<t>PLR stands for "Point of Local Repair". It is the router that applies <dd pn="section-2.1-1.6">Interior Gateway Protocol</dd>
fast traffic restoration after detecting failure in a directly attached <dt pn="section-2.1-1.7">LFA:</dt>
link, set of links, and/or node.</t> <dd pn="section-2.1-1.8">Loop-Free Alternate</dd>
<dt pn="section-2.1-1.9">LSDB:</dt>
<t>Similar to <xref target="RFC7490"/>, the concept of P-Space and <dd pn="section-2.1-1.10">Link State Database</dd>
Q-Space is used for TI-LFA.</t> <dt pn="section-2.1-1.11">PLR:</dt>
<dd pn="section-2.1-1.12">Point of Local Repair</dd>
<t>The P-space P(R,X) of a router R with regard to a resource X (e.g. a <dt pn="section-2.1-1.13">RL:</dt>
link S-F, a node F, or a SRLG) is the set of routers reachable from R <dd pn="section-2.1-1.14">Repair List</dd>
using the pre-convergence shortest paths without any of those paths <dt pn="section-2.1-1.15">RLFA:</dt>
(including equal-cost path splits) transiting through X. A P node is a <dd pn="section-2.1-1.16">Remote Loop-Free Alternate</dd>
node that belongs to the P-space.</t> <dt pn="section-2.1-1.17">SID:</dt>
<dd pn="section-2.1-1.18">Segment Identifier</dd>
<t>Consider the set of neighbors of a router R and a resource X. Exclude <dt pn="section-2.1-1.19">SPF:</dt>
from that set, the neighbors that are reachable from R using X. The <dd pn="section-2.1-1.20">Shortest Path First</dd>
Extended P-Space P'(R,X) of a node R with regard to a resource X is the <dt pn="section-2.1-1.21">SPT:</dt>
union of the P-spaces of the neighbors in that reduced set of neighbors <dd pn="section-2.1-1.22">Shortest Path Tree</dd>
with regard to the resource X.</t> <dt pn="section-2.1-1.23">SR:</dt>
<dd pn="section-2.1-1.24">Segment Routing</dd>
<t>The Q-space Q(R,X) of a router R with regard to a resource X is the <dt pn="section-2.1-1.25">SRLG:</dt>
set of routers from which R can be reached without any path (including <dd pn="section-2.1-1.26">Shared Risk Link Group</dd>
equal-cost path splits) transiting through X. A Q node is a node that <dt pn="section-2.1-1.27">TI-LFA:</dt>
belongs to the Q-space </t> <dd pn="section-2.1-1.28">Topology Independent Loop-Free Alternate</dd
>
<t>EP(P, Q) is an explicit SR path from a node P to a node Q.</t> </dl>
<t indent="0" pn="section-2.1-2">The main notations used in this documen
<t>Primary Interface: Primary Outgoing Interface: One of the outgoing t are defined as follows:</t>
interfaces towards a destination according to the IGP link-state <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-2
protocol</t> .1-3">
<li pn="section-2.1-3.1">The terms "old" and "new" topologies refer to
<t>Primary Link: A link connected to the primary interface</t> the LSDB state before
and after the considered failure, respectively.</li>
<t>adj-sid(S-F): Adjacency Segment from node S to node F</t> <li pn="section-2.1-3.2">SPT_old(R) is the SPT rooted at node R in the
initial state of the
<section anchor="conventions" title="Conventions used in this document"> network.</li>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <li pn="section-2.1-3.3">SPT_new(R, X) is the SPT rooted at node R in
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and the state of the
"OPTIONAL" in this document are to be interpreted as described in BCP network after the resource X has failed.</li>
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only <li pn="section-2.1-3.4">The PLR is the router that applies fast traff
when, they appear in all capitals, as shown here.</t> ic restoration after
detecting failure in a directly attached link, set of links, and/or
node.</li>
<li pn="section-2.1-3.5">Similar to <xref target="RFC7490" format="def
ault" sectionFormat="of" derivedContent="RFC7490"/>, the concept of P-space and
Q-space is used for TI-LFA.</li>
<li pn="section-2.1-3.6">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 pn="section-2.1-3.7">Consider the set of neighbors of a router R a
nd 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 pn="section-2.1-3.8">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 pn="section-2.1-3.9">EP(P, Q) is an explicit SR path from a node P
to a node Q.</li>
<li pn="section-2.1-3.10">The primary interface and primary outgoing i
nterface are one of the outgoing
interfaces towards a destination according to the IGP link-state
protocol.</li>
<li pn="section-2.1-3.11">The primary link is a link connected to the
primary interface.</li>
<li pn="section-2.1-3.12">The Adj-SID(S-F) is the Adjacency segment fr
om node S to node F.</li>
</ul>
</section>
<section anchor="conventions" numbered="true" toc="include" removeInRFC="f
alse" pn="section-2.2">
<name slugifiedName="name-conventions-used-in-this-do">Conventions Used
in This Document</name>
<t indent="0" pn="section-2.2-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP 14 <xref target="RFC2119" format="default" s
ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa
ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they app
ear in all capitals, as
shown here.
</t>
</section> </section>
</section> </section>
<section anchor="base" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="base" title="Base principle"> "section-3">
<t>The basic algorithm to compute the repair path is to pre-compute <name slugifiedName="name-base-principle">Base Principle</name>
SPT_new(R,X) and for each destination, encode the repair path as a <t indent="0" pn="section-3-1">The basic algorithm to compute the repair p
ath is to pre-compute
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 indent="0" pn="section-3-2">An implementation is free to use any local
<t>An implementation is free to use any local optimization to provide 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="include" removeInR
<section anchor="pq_space_intersect" FC="false" pn="section-4">
title="Intersecting P-Space and Q-Space with post-convergence paths <name slugifiedName="name-intersecting-p-space-and-q-">Intersecting P-spac
"> e and Q-space with Post-Convergence Paths</name>
<t>One of the challenges of defining an SR path following the expected <t indent="0" pn="section-4-1">One of the challenges of defining an SR pat
h 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" sectionFormat="of" derivedConte
path from the PLR to the protected destination and compute an SR nt="RFC7490"/>) of the nodes along the
explicit path from P to Q when they are not adjacent. Such properties expected post-convergence path from the PLR to the protected destination
will be used in <xref target="tilfa_repair_path"/> to compute the TI-LFA and compute an SR explicit path from P to Q when they are not
repair list.</t> adjacent. Such properties will be used in <xref target="tilfa_repair_path"
format="default" sectionFormat="of" derivedContent="Section 5"/> to compute the
<section anchor="extp_space" TI-LFA
title="Extended P-Space property computation for a resource X, ov RL.</t>
er post-convergence paths"> <section anchor="extp_space" numbered="true" toc="include" removeInRFC="fa
<t>The objective is to determine which nodes on the post-convergence lse" pn="section-4.1">
<name slugifiedName="name-extended-p-space-property-c">Extended P-space
Property Computation for a Resource X over Post-Convergence Paths</name>
<t indent="0" pn="section-4.1-1">The objective is to determine which nod
es 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 indent="0" pn="section-4.1-2">This can be found by:</t>
<t>This can be found by: <list style="symbols"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4
<t>Excluding neighbors which are not on the post-convergence path .1-3">
when computing P'(R,X)</t> <li pn="section-4.1-3.1">
<t indent="0" pn="section-4.1-3.1.1">excluding neighbors that are no
<t>Then, intersecting the set of nodes belonging to the t on the post-convergence path
when computing P'(R, X), then</t>
</li>
<li pn="section-4.1-3.2">
<t indent="0" pn="section-4.1-3.2.1">intersecting the set of nodes b
elonging 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="include" removeInRFC="false
<section anchor="q_space" " pn="section-4.2">
title="Q-Space property computation for a resource X, over post <name slugifiedName="name-q-space-property-computatio">Q-space Property
-convergence paths"> Computation for a Resource X over Post-Convergence Paths</name>
<t>The goal is to determine which nodes on the post-convergence path <t indent="0" pn="section-4.2-1">The goal is to determine which nodes on
from the Point of Local Repair (PLR) R to the destination D are in the the post-convergence path
Q-Space of destination D with regard to resource X (where X can be a 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
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 indent="0" pn="section-4.2-2">This can be found by intersecting the s
<t>This can be found by intersecting the set of nodes belonging to the et 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="include" removeInRF
<section anchor="q_space_scaling" C="false" pn="section-4.3">
title="Scaling considerations when computing Q-Space"> <name slugifiedName="name-scaling-considerations-when">Scaling Considera
<t><xref target="RFC7490"/> raises scaling concerns about computing a tions When Computing Q-space</name>
Q-Space per destination. Similar concerns may affect TI-LFA <t indent="0" pn="section-4.3-1"><xref target="RFC7490" format="default"
sectionFormat="of" derivedContent="RFC7490"/> raises scaling concerns about com
puting a
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" sectionFormat="o
network to determine the Q-Space. It will be up to each implementation f" derivedContent="RFC7490"/> for every destination 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" numbered="true" toc="include" removeInRF
<section anchor="tilfa_repair_path" title="TI-LFA Repair path"> C="false" pn="section-5">
<t>The TI-LFA repair path consists of an outgoing interface and a <name slugifiedName="name-ti-lfa-repair-path">TI-LFA Repair Path</name>
list of segments (repair list (RL)) to insert on the SR header in <t indent="0" pn="section-5-1">The TI-LFA repair path consists of an outgo
accordance with the dataplane used. The repair list encodes the explicit, ing interface and a list
and possibly post-convergence, path to the destination, which avoids the of segments (a Repair List (RL)) to insert on the SR header in
protected resource X and, at the same time, is guaranteed to be loop-free accordance with the data plane used. The RL encodes the
irrespective of the state of FIBs along the nodes belonging to the explicit (and possibly post-convergence) path to the destination, which
explicit path as long as the states of the FIBs are programmed according avoids the protected resource X. At the same time, the RL is
to a link-state IGP. Thus, there is no need for any co-ordination or guaranteed to be loop-free, irrespective of the state of FIBs along the
message exchange between the PLR and any other router in the network.</t> nodes belonging to the explicit path, as long as the states of the FIBs
are programmed according to a link-state IGP. Thus, there is no need
<t>The TI-LFA repair path is found by intersecting P(S,X) and Q(D,X) with for any coordination or message exchange between the PLR and any other
the post-convergence path to D and computing the explicit SR- based path router in the network.</t>
EP(P, Q) from a node P in P(S,X) to a node Q in Q(D,X) when these nodes <t indent="0" pn="section-5-2">The TI-LFA repair path is found by intersec
are not adjacent along the post convergence path. The TI-LFA repair list ting P(S, X) and Q(D, X) with
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" align="left" suppress-title="false" pn="figu
<figure anchor="sample-topo1" title="Sample topology with TI-LFA"> re-1">
<artwork> <name slugifiedName="name-sample-topology-with-ti-lfa">Sample Topology w
ith TI-LFA</name>
S ------- N1 ----------- D <artwork name="" type="" align="left" alt="" pn="section-5-3.1">
*\ | \ | 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 indent="0" pn="section-5-4">As an example, in <xref target="sample-topo
<t>As an example, in <xref target="sample-topo1"/>, the focus is on the 1" format="default" sectionFormat="of" derivedContent="Figure 1"/>, the focus 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" bare="false" empty="false" indent="3" pn="section-5-5
<t><list style="symbols"> ">
<t>First, P(S, N1) is computed and results in [N3, N2, R1].</t> <li pn="section-5-5.1">
<t indent="0" pn="section-5-5.1.1">First, P(S, N1) is computed and res
<t>Then, Q(D, N1) is computed and results in [R3].</t> ults in [N3, N2, R1].</t>
</li>
<t>The expected post-convergence path from S to D considering the <li pn="section-5-5.2">
<t indent="0" pn="section-5-5.2.1">Then, Q(D, N1) is computed and resu
lts in [R3].</t>
</li>
<li pn="section-5-5.3">
<t indent="0" pn="section-5-5.3.1">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 pn="section-5-5.4">
deeper downstream node in PCPath, it can be assumed to be used as P <t indent="0" pn="section-5-5.4.1">P(S, N1) intersection with PCPath i
node (this is an example and an implementation could use a different s [N2, R1]. With R1 being the
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 pn="section-5-5.5">
node. An SR explicit path is then computed from R1 (P node) to R3 (Q <t indent="0" pn="section-5-5.5.1">Q(D, N1) intersection with PCPath i
node) following PCPath (R1 -&gt; R2 -&gt; R3): &lt;Adj-Sid(R1-R2), s [R3], so R3 is picked as a Q
Adj-Sid(R2-R3)&gt;.</t> node. An SR-explicit path is then computed from R1 (P node) to R3 (Q
</list> As a result, the TI-LFA repair list of S for destination D node) following PCPath (R1 -&gt; R2 -&gt; R3): &lt;Adj-SID(R1-R2),
considering the failure of node N1 is: &lt;Node-SID(R1), Adj-Sid(R1-R2), Adj-SID(R2-R3)&gt;.</t>
Adj-Sid(R20R3)&gt;.</t> </li>
</ul>
<t>Most often, the TI-LFA repair list has a simpler form, as described <t indent="0" pn="section-5-6"> As a result, the TI-LFA RL of S for destin
in the following sections. <xref target="analysis"/> provides statistics ation D
considering the failure of node N1 is: &lt;Node-SID(R1), Adj-SID(R1-R2),
Adj-SID(R2-R3)&gt;.</t>
<t indent="0" pn="section-5-7">Most often, the TI-LFA RL has a simpler for
m, as described
in the following sections. <xref target="analysis" format="default" sectio
nFormat="of" derivedContent="Appendix B"/> provides 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="include" removeInRFC=
<section anchor="direct_backup" title="FRR path using a direct neighbor"> "false" pn="section-5.1">
<t>When a direct neighbor is in P(S,X) and Q(D,x) and the link to that <name slugifiedName="name-frr-path-using-a-direct-nei">FRR Path Using a
Direct Neighbor</name>
<t indent="0" pn="section-5.1-1">When a direct neighbor is in P(S, X) an
d Q(D, x), and the link to that
direct neighbor is on the post-convergence path, the outgoing interface direct neighbor is on the post-convergence path, the outgoing interface
is set to that neighbor and the repair segment list is empty.</t> is set to that neighbor and the repair segment list is empty.</t>
<t indent="0" pn="section-5.1-2">This is comparable to a post-convergenc
<t>This is comparable to a post-convergence LFA FRR repair.</t> e LFA FRR repair.</t>
</section> </section>
<section anchor="pq_backup" numbered="true" toc="include" removeInRFC="fal
<section anchor="pq_backup" title="FRR path using a PQ node"> se" pn="section-5.2">
<t>When a remote node R is in P(S,X) and Q(D,x) and on the <name slugifiedName="name-frr-path-using-a-pq-node">FRR Path Using a PQ
post-convergence path, the repair list is made of a single node segment Node</name>
to R and the outgoing interface is set to the outgoing interface used <t indent="0" pn="section-5.2-1">When a remote node R is in P(S, X) and
Q(D, x) and on the
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 reach R.</t> to reach R.</t>
<t indent="0" pn="section-5.2-2">This is comparable to a post-convergenc
<t>This is comparable to a post-convergence RLFA repair tunnel.</t> e RLFA repair tunnel.</t>
</section> </section>
<section anchor="adj_pq_backup" numbered="true" toc="include" removeInRFC=
<section anchor="adj_pq_backup" "false" pn="section-5.3">
title="FRR path using a P node and Q node that are adjacent"> <name slugifiedName="name-frr-path-using-a-p-node-and">FRR Path Using a
<t>When a node P is in P(S,X) and a node Q is in Q(D,x) and both are on P Node and Q Node That Are Adjacent</name>
the post-convergence path and both are adjacent to each other, the <t indent="0" pn="section-5.3-1">When a node P is in P(S, X) and a node
repair list is made of two segments: A node segment to P (to be Q is in Q(D, x), and both are on
processed first), followed by an adjacency segment from P to Q.</t> the post-convergence path and are adjacent to each other, the
RL is made of two segments: a node segment to P (to be
<t>This is comparable to a post-convergence DLFA (LFA with directed processed first), followed by an Adjacency segment from P to Q.</t>
forwarding) repair tunnel.</t> <t indent="0" pn="section-5.3-2">This is comparable to a post-convergenc
e Directed Loop-Free
Alternate (DLFA) repair tunnel.</t>
</section> </section>
<section anchor="remote_pq_backup" numbered="true" toc="include" removeInR
<section anchor="remote_pq_backup" FC="false" pn="section-5.4">
title="Connecting distant P and Q nodes along post-convergence pa <name slugifiedName="name-connecting-distant-p-and-q-">Connecting Distan
ths"> t P and Q Nodes Along Post-Convergence Paths</name>
<t>In some cases, there is no adjacent P and Q node along the post- <t indent="0" pn="section-5.4-1">In some cases, there is no adjacent P a
convergence path. As mentioned in <xref target="base"/>, a list of nd Q node along the
adjacency SIDs can be used to encode the path between P and Q. post‑convergence path. As mentioned in <xref target="base" format="defau
However, the PLR can perform additional computations to compute a list lt" sectionFormat="of" derivedContent="Section 3"/>, a list of Adjacency SIDs ca
of segments that represent a loop-free path from P to Q. How these n be used to encode the
computations are done is out of scope of this document and is left to path between P and Q. However, the PLR can perform additional
implementation.</t> computations to compute a shorter list of segments that represent a
loop-free path from P to Q. How these computations are done is out of
scope of this document and is left to implementation.</t>
</section> </section>
</section> </section>
<section anchor="repairlist" numbered="true" toc="include" removeInRFC="fals
<section anchor="repairlist" title="Building TI-LFA repair lists for SR Segm e" pn="section-6">
ents"> <name slugifiedName="name-building-ti-lfa-repair-list">Building TI-LFA Rep
<t>The following sections describe how to build the repair lists using air Lists for SR Segments</name>
the terminology defined in <xref target="RFC8402"/>. The procedures <t indent="0" pn="section-6-1">The following sections describe how to buil
described in this section are equally applicable to both SR-MPLS and d the RLs using
SRv6 dataplane, while the dataplane-specific considerations are the terminology defined in <xref target="RFC8402" format="default" section
described in <xref target="dataplane"/>.</t> Format="of" derivedContent="RFC8402"/>. The procedures
described in this section are equally applicable to both the Segment Routi
<t>In this section, the process by which a protecting router S handles ng over MPLS (SR-MPLS) and
the Segment Routing over IPv6 (SRv6) data plane, while the data plane-spec
ific considerations are
described in <xref target="dataplane" format="default" sectionFormat="of"
derivedContent="Section 7"/>.</t>
<t indent="0" pn="section-6-2">This section explains the process by which
a protecting router S handles
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="include" remo
<section anchor="link-protect-node-sid" veInRFC="false" pn="section-6.1">
title="The active segment is a node segment"> <name slugifiedName="name-the-active-segment-is-a-nod">The Active Segmen
<t>The active segment MUST be kept on the SR header unchanged and the t Is a Node Segment</name>
repair list MUST be added. The active segment becomes the first <t indent="0" pn="section-6.1-1">The active segment <bcp14>MUST</bcp14>
segment after the repair list. The way the repair list is added depends be kept on the SR header unchanged and the
on the dataplane used (see <xref target="dataplane"/>).</t> RL <bcp14>MUST</bcp14> be added. The active segment becomes the first
segment after the RL. The way the RL is added depends
on the data plane used (see <xref target="dataplane" format="default" se
ctionFormat="of" derivedContent="Section 7"/>).</t>
</section> </section>
<section anchor="link-protect-adj-sid" numbered="true" toc="include" remov
<section anchor="link-protect-adj-sid" eInRFC="false" pn="section-6.2">
title="The active segment is an adjacency segment"> <name slugifiedName="name-the-active-segment-is-an-ad">The Active Segmen
<t>The FRR behavior applied by S for any packet received with an t Is an Adjacency Segment</name>
active adjacency segment S-F, for which protection was enabled, is <t indent="0" pn="section-6.2-1">This section defines the FRR behavior a
defined here. Since protection has been enabled for the segment S-F and pplied by S for any packet
signaled in the IGP (for instance, using protocol extensions from <xref received with an active Adjacency segment S-F for which protection was
target="RFC8667"/> and <xref target="RFC8665"/>), a calculator of any enabled. Since protection has been enabled for the segment S-F and
SR policy utilizing this segment is aware that it may be transiently signaled in the IGP (for instance, using protocol extensions from
rerouted out of S-F in the event of an S-F failure.</t> <xref target="RFC8667" format="default" sectionFormat="of" derivedConten
t="RFC8667"/> and <xref target="RFC8665" format="default" sectionFormat="of" der
<t>The simplest approach for link protection of an adjacency segment ivedContent="RFC8665"/>), a calculator of any SR policy utilizing this
S-F is to create a repair list that will carry the traffic to F. To do segment is aware that it may be transiently rerouted out of S-F in the
so, one or more “PUSH” operations are performed. If the repair list, event of an S-F failure.</t>
<t indent="0" pn="section-6.2-2">The simplest approach for link protecti
on of an Adjacency segment
S-F is to create an RL that will carry the traffic to F. To do
so, one or more "PUSH" operations are performed. If the RL,
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" sectionForm
at="of" derivedContent="RFC8402"/>.</t>
<t>This method, which merges back the traffic at the remote end of the <t indent="0" pn="section-6.2-3">This method, which merges back the traf
adjacency segment, has the advantage of keeping as much as possible the fic at the remote end of the
traffic on the pre-failure path. When SR policies are involved and Adjacency segment, has the advantage of keeping as much traffic as
strict compliance with the policy is required, an end-to-end protection possible on the pre-failure path. When SR policies are involved and
(beyond the scope of this document) should be preferred over the local strict compliance with the policy is required, an end-to-end
repair mechanism described above.</t> protection (beyond the scope of this document) should be preferred
over the local repair mechanism described above.</t>
<t> Note, however, that when the SR source node is using traffic <t indent="0" pn="section-6.2-4"> Note, however, that when the SR source
engineering (TE), it will generally not be possible for the PLR to know node is using Traffic
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 indent="0" pn="section-6.2-5">The case where the active segment is fo
<t>The case where the active segment is followed by another adjacency llowed 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="incl
<section anchor="link-protect-adj-sid-adj-sid" ude" removeInRFC="false" pn="section-6.2.1">
title="Protecting [Adjacency, Adjacency] segment lists"> <name slugifiedName="name-protecting-adjacency-adjace">Protecting [Adj
<t>If the next segment in the list is an Adjacency segment, then the acency, Adjacency] Segment Lists</name>
<t indent="0" pn="section-6.2.1-1">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 indent="0" pn="section-6.2.1-2">To do so, S <bcp14>MUST</bcp14> app
<t>To do so, S MUST apply a "NEXT" operation on Adj-Sid(S-F) and then ly a "NEXT" operation on Adj-SID(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" sectionFormat="of" de
rivedContent="RFC8402"/>.</t>
<t>Upon failure of S-F, a packet reaching S with a segment list <t indent="0" pn="section-6.2.1-3">Upon failure of S-F, a packet reach
matching [adj-sid(S-F),adj-sid(F-M),...] will thus leave S with a segm ing S with a segment list
ent matching [adj-sid(S-F), adj-sid(F-M), ...] will thus leave S with a se
list matching [RL(F),node(F),adj-sid(F-M),...], where RL(F) is the gment
repair list for destination F.</t> list matching [RL(F), node(F), adj-sid(F-M), ...], where RL(F) is the
RL for destination F.</t>
</section> </section>
<section anchor="link-protect-adj-sid-node-sid" numbered="true" toc="inc
<section anchor="link-protect-adj-sid-node-sid" lude" removeInRFC="false" pn="section-6.2.2">
title="Protecting [Adjacency, Node] segment lists"> <name slugifiedName="name-protecting-adjacency-node-s">Protecting [Adj
<t>If the next segment in the stack is a node segment, say for node acency, Node] Segment Lists</name>
T, the segment list on the packet matches <t indent="0" pn="section-6.2.2-1">If the next segment in the stack is
[adj-sid(S-F),node(T),...].</t> a node segment, say for node
T, the segment list on the packet matches [adj-sid(S-F), node(T), ...]
<t>In this case, S MUST apply a "NEXT" operation on the Adjacency .</t>
segment related to S-F, followed by a "PUSH" of a repair list <t indent="0" pn="section-6.2.2-2">In this case, S <bcp14>MUST</bcp14>
apply a "NEXT" operation on the Adjacency
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 indent="0" pn="section-6.2.2-3">Upon failure of S-F, packets reachi
<t>Upon failure of S-F, packets reaching S with a segment list ng 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" numbered="true" toc="include" removeInRFC="false
<section anchor="dataplane" title="Dataplane specific considerations"> " pn="section-7">
<section anchor="mpls-dataplane" title="MPLS dataplane considerations"> <name slugifiedName="name-data-plane-specific-conside">Data Plane-Specific
<t>MPLS dataplane for Segment Routing is described in <xref Considerations</name>
target="RFC8660"/>.</t> <section anchor="mpls-dataplane" numbered="true" toc="include" removeInRFC
="false" pn="section-7.1">
<t>The following dataplane behaviors apply when creating a repair list <name slugifiedName="name-mpls-data-plane-considerati">MPLS Data Plane C
using an MPLS dataplane: <list style="numbers"> onsiderations</name>
<t>If the active segment is a node segment that has been signaled <t indent="0" pn="section-7.1-1">The MPLS data plane for SR is described
with penultimate hop popping and the repair list ends with an in <xref target="RFC8660" format="default" sectionFormat="of" derivedContent="R
adjacency segment terminating on a node that advertised NEXT FC8660"/>.</t>
operation <xref target="RFC8402"/> of the active segment, then the <t indent="0" pn="section-7.1-2">The following data plane behaviors appl
active segment MUST be popped before pushing the repair list.</t> y when creating an RL
using an MPLS data plane:</t>
<t>If the active segment is a node segment but the other conditions <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.
in 1. are not met, the active segment MUST be popped then pushed 1-3"><li pn="section-7.1-3.1" derivedCounter="1.">
<t indent="0" pn="section-7.1-3.1.1">If the active segment is a node
segment that has been signaled
with penultimate hop popping, and the RL ends with an
Adjacency segment terminating on the penultimate node of the
active segment, then the active segment <bcp14>MUST</bcp14> be
popped before pushing the RL.</t>
</li>
<li pn="section-7.1-3.2" derivedCounter="2.">
<t indent="0" pn="section-7.1-3.2.1">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="include" removeInRFC
<section anchor="srv6-dataplane" title="SRv6 dataplane considerations"> ="false" pn="section-7.2">
<t>SRv6 dataplane and programming instructions are described <name slugifiedName="name-srv6-data-plane-considerati">SRv6 Data Plane C
respectively in <xref target="RFC8754"/> and <xref onsiderations</name>
target="RFC8986"/>.</t> <t indent="0" pn="section-7.2-1">SRv6 data plane and programming instruc
tions are described
<t>The TI-LFA path computation algorithm is the same as in the SR-MPLS respectively in <xref target="RFC8754" format="default" sectionFormat="o
dataplane. Note however that the Adjacency SIDs are typically globally f" derivedContent="RFC8754"/> and <xref target="RFC8986" format="default" sectio
routed. In such case, there is no need for preceding an adjacency SID nFormat="of" derivedContent="RFC8986"/>.</t>
with a Prefix-SID <xref target="RFC8402"/> and the resulting repair <t indent="0" pn="section-7.2-2">The TI-LFA path computation algorithm i
list is likely shorter.</t> s the same as in the SR-MPLS
data plane. Note, however, that the Adjacency SIDs are typically globall
<t>If the traffic is protected at a Transit Node, then an SRv6 SID y
list is added on the packet to apply the repair list. The addition of routed. In such a case, there is no need for preceding an Adjacency SID
the repair list follows the headend behaviors as specified in section with a Prefix-SID <xref target="RFC8402" format="default" sectionFormat=
5 of <xref target="RFC8986"/>.</t> "of" derivedContent="RFC8402"/>, and the resulting RL is likely shorter.</t>
<t indent="0" pn="section-7.2-3">If the traffic is protected at a Transi
<t>If the traffic is protected at an SR Segment Endpoint Node, first t Node, then an SRv6 SID
the Segment Endpoint packet processing is executed. Then the packet is list is added on the packet to apply the RL. The addition of
protected as if its were a transit packet.</t> the RL follows the head-end behaviors as specified in
<xref target="RFC8986" sectionFormat="of" section="5" format="default" d
erivedLink="https://rfc-editor.org/rfc/rfc8986#section-5" derivedContent="RFC898
6"/>.</t>
<t indent="0" pn="section-7.2-4">If the traffic is protected at an SR Se
gment Endpoint Node, first
the Segment Endpoint packet processing is executed. Then, the packet is
protected as if it were a transit packet.</t>
</section> </section>
</section> </section>
<section anchor="tilfa-sr-algo" numbered="true" toc="include" removeInRFC="f
<section anchor="tilfa-sr-algo" title="TI-LFA and SR algorithms"> alse" pn="section-8">
<t>SR allows an operator to bind an algorithm to a prefix-SID (as <name slugifiedName="name-ti-lfa-and-sr-algorithms">TI-LFA and SR Algorith
defined in <xref target="RFC8402"/>. The algorithm value dictates how ms</name>
<t indent="0" pn="section-8-1">SR allows an operator to bind an algorithm
to a Prefix-SID (as
defined in <xref target="RFC8402" format="default" sectionFormat="of" deri
vedContent="RFC8402"/>). 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 indent="0" pn="section-8-2"><xref target="RFC9350" format="default" sec
<t><xref target="RFC9350"/> defines a flexible algorithm (FlexAlgo) tionFormat="of" derivedContent="RFC9350"/> defines a Flexible Algorithm
framework to be associated with Prefix-SIDs. FlexAlgo allows a user to framework to be associated with Prefix-SIDs. A Flexible Algorithm allows a
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="include" removeIn
<section anchor="adj-sid-repair-list" RFC="false" pn="section-9">
title="Usage of Adjacency segments in the repair list"> <name slugifiedName="name-usage-of-adjacency-segments">Usage of Adjacency
<t>The repair list of segments computed by TI-LFA may contain one or Segments in the Repair List</name>
more adjacency segments. An adjacency segment may be protected or not <t indent="0" pn="section-9-1">The RL of segments computed by TI-LFA may c
ontain one or
more Adjacency segments. An Adjacency segment may be protected or not
protected.</t> protected.</t>
<figure anchor="cascaded-frr" align="left" suppress-title="false" pn="figu
<figure anchor="cascaded-frr"> re-2">
<artwork> <artwork name="" type="" align="left" alt="" pn="section-9-2.1">
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 indent="0" pn="section-9-3">In <xref target="cascaded-frr" format="defa
<t>In <xref target="cascaded-frr"/>, all the metrics are equal to 1 ult" sectionFormat="of" derivedContent="Figure 2"/>, all the metrics
except R2-R7,R7-R8,R8-R4,R7-R9 which have a metric of 1000. Considering are equal to 1 except R2-R7,R7-R8,R8-R4,R7-R9, which have a metric of
R2 as a PLR to protect against the failure of node R3 for the traffic 1000. Considering R2 as a PLR to protect against the failure of node R3
S-&gt;D, the repair list computed by R2 will be for the traffic S-&gt;D, the RL computed by R2 will be
[adj-sid(R7-R8),adj-sid(R8-R4)] and the outgoing interface will be to [adj-sid(R7-R8), adj-sid(R8-R4)], and the outgoing interface will be to
R7. If R3 fails, R2 pushes the repair list onto the incoming packet to R7. If R3 fails, R2 pushes the RL 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" format="
target="repairlist"/>.</t> default" sectionFormat="of" derivedContent="Section 6"/>.</t>
<t indent="0" pn="section-9-4">To avoid the possibility of this double FRR
<t>To avoid the possibility of this double FRR activation, an 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="include" removeInRFC="false"
<section anchor="security" title="Security Considerations"> pn="section-10">
<t>The techniques described in this document are internal functionalities <name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-10-1">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 indent="0" pn="section-10-2">The security considerations described in <
<t>Security considerations described in <xref target="RFC5286"/> and xref target="RFC5286" format="default" sectionFormat="of" derivedContent="RFC528
<xref target="RFC7490"/> apply to this document. Similarly, as the 6"/> and
solution described in the document is based on Segment Routing <xref target="RFC7490" format="default" sectionFormat="of" derivedContent=
technology, reader should be aware of the security considerations "RFC7490"/> apply to this document. Similarly, as the
related to this technology (<xref target="RFC8402"/>) and its dataplane solution described in this document is based on SR
instantiations (<xref target="RFC8660"/>, <xref target="RFC8754"/> and technology, the reader should be aware of the security considerations
<xref target="RFC8986"/>). However, this document does not introduce related to this technology (see <xref target="RFC8402" format="default" se
additional security concern.</t> ctionFormat="of" derivedContent="RFC8402"/>) and its data plane
</section> instantiations (see <xref target="RFC8660" format="default" sectionFormat=
"of" derivedContent="RFC8660"/>, <xref target="RFC8754" format="default" section
<section anchor="iana" title="IANA Considerations"> Format="of" derivedContent="RFC8754"/>, and
<t>No requirements for IANA</t> <xref target="RFC8986" format="default" sectionFormat="of" derivedContent=
</section> "RFC8986"/>). However, this document does not introduce
additional security concerns.</t>
<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="include" removeInRFC="false" pn=
<section anchor="ack" title="Acknowledgments"> "section-11">
<t>The authors would like to thank Les Ginsberg, Stewart Bryant, Alexander <name slugifiedName="name-iana-considerations">IANA Considerations</name>
Vainsthein, Chris Bowers, Shraddha Hedge, Wes Hardaker, Gunter Van de <t indent="0" pn="section-11-1">This document has no IANA actions.</t>
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 pn="section-12">
<name slugifiedName="name-references">References</name>
&RFC8174; <references pn="section-12.1">
<name slugifiedName="name-normative-references">Normative References</na
&RFC8402; me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
&RFC8660; 119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
&RFC8754; <title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
&RFC8986; <author fullname="S. Bradner" initials="S." surname="Bradner"/>
</references> <date month="March" year="1997"/>
<abstract>
<references title="Informative References"> <t indent="0">In many standards track documents several words are
<?rfc include="reference.RFC.5714" ?> used to signify the requirements in the specification. These words are often cap
italized. This document defines these words as they should be interpreted in IET
<?rfc include="reference.RFC.5715" ?> F documents. This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for improvements.</t
<?rfc include="reference.RFC.5286" ?> >
</abstract>
<?rfc include="reference.RFC.6976" ?> </front>
<seriesInfo name="BCP" value="14"/>
<?rfc include="reference.RFC.7490" ?> <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
<?rfc include="reference.RFC.8333" ?> </reference>
<reference anchor="RFC7916" target="https://www.rfc-editor.org/info/rfc7
<?rfc include="reference.I-D.bashandy-rtgwg-segment-routing-uloop"?> 916" quoteTitle="true" derivedAnchor="RFC7916">
<front>
&FLEXALGO; <title>Operational Management of Loop-Free Alternates</title>
<author fullname="S. Litkowski" initials="S." role="editor" surname=
&RFC9256; "Litkowski"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
&RFC6571; <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="K. Raza" initials="K." surname="Raza"/>
&RFC8665; <author fullname="M. Horneffer" initials="M." surname="Horneffer"/>
<author fullname="P. Sarkar" initials="P." surname="Sarkar"/>
&RFC8667; <date month="July" year="2016"/>
<abstract>
<t indent="0">Loop-Free Alternates (LFAs), as defined in RFC 5286,
constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection fo
r IP traffic (and, by extension, MPLS LDP traffic). Following early deployment e
xperiences, this document provides operational feedback on LFAs, highlights some
limitations, and proposes a set of refinements to address those limitations. It
also proposes required management specifications.</t>
<t indent="0">This proposal is also applicable to remote-LFA solut
ions.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7916"/>
<seriesInfo name="DOI" value="10.17487/RFC7916"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by clari
fying that only UPPERCASE usage of the key words have the defined special meanin
gs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8
402" quoteTitle="true" derivedAnchor="RFC8402">
<front>
<title>Segment Routing Architecture</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="S. Previdi" initials="S." role="editor" surname="P
revidi"/>
<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
<author fullname="R. Shakir" initials="R." surname="Shakir"/>
<date month="July" year="2018"/>
<abstract>
<t indent="0">Segment Routing (SR) leverages the source routing pa
radigm. A node steers a packet through an ordered list of instructions, called "
segments". A segment can represent any instruction, topological or service based
. A segment can have a semantic local to an SR node or global within an SR domai
n. SR provides a mechanism that allows a flow to be restricted to a specific top
ological path, while maintaining per-flow state only at the ingress node(s) to t
he SR domain.</t>
<t indent="0">SR can be directly applied to the MPLS architecture
with no change to the forwarding plane. A segment is encoded as an MPLS label. A
n ordered list of segments is encoded as a stack of labels. The segment to proce
ss is on the top of the stack. Upon completion of a segment, the related label i
s popped from the stack.</t>
<t indent="0">SR can be applied to the IPv6 architecture, with a n
ew type of routing header. A segment is encoded as an IPv6 address. An ordered l
ist of segments is encoded as an ordered list of IPv6 addresses in the routing h
eader. The active segment is indicated by the Destination Address (DA) of the pa
cket. The next active segment is indicated by a pointer in the new routing heade
r.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8402"/>
<seriesInfo name="DOI" value="10.17487/RFC8402"/>
</reference>
<reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8
660" quoteTitle="true" derivedAnchor="RFC8660">
<front>
<title>Segment Routing with the MPLS Data Plane</title>
<author fullname="A. Bashandy" initials="A." role="editor" surname="
Bashandy"/>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="S. Previdi" initials="S." surname="Previdi"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
<author fullname="R. Shakir" initials="R." surname="Shakir"/>
<date month="December" year="2019"/>
<abstract>
<t indent="0">Segment Routing (SR) leverages the source-routing pa
radigm. A node steers a packet through a controlled set of instructions, called
segments, by prepending the packet with an SR header. In the MPLS data plane, th
e SR header is instantiated through a label stack. This document specifies the f
orwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8660"/>
<seriesInfo name="DOI" value="10.17487/RFC8660"/>
</reference>
<reference anchor="RFC8754" target="https://www.rfc-editor.org/info/rfc8
754" quoteTitle="true" derivedAnchor="RFC8754">
<front>
<title>IPv6 Segment Routing Header (SRH)</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="D. Dukes" initials="D." role="editor" surname="Duk
es"/>
<author fullname="S. Previdi" initials="S." surname="Previdi"/>
<author fullname="J. Leddy" initials="J." surname="Leddy"/>
<author fullname="S. Matsushima" initials="S." surname="Matsushima"/
>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<date month="March" year="2020"/>
<abstract>
<t indent="0">Segment Routing can be applied to the IPv6 data plan
e using a new type of Routing Extension Header called the Segment Routing Header
(SRH). This document describes the SRH and how it is used by nodes that are Seg
ment Routing (SR) capable.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8754"/>
<seriesInfo name="DOI" value="10.17487/RFC8754"/>
</reference>
<reference anchor="RFC8986" target="https://www.rfc-editor.org/info/rfc8
986" quoteTitle="true" derivedAnchor="RFC8986">
<front>
<title>Segment Routing over IPv6 (SRv6) Network Programming</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="P. Camarillo" initials="P." role="editor" surname=
"Camarillo"/>
<author fullname="J. Leddy" initials="J." surname="Leddy"/>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<author fullname="S. Matsushima" initials="S." surname="Matsushima"/
>
<author fullname="Z. Li" initials="Z." surname="Li"/>
<date month="February" year="2021"/>
<abstract>
<t indent="0">The Segment Routing over IPv6 (SRv6) Network Program
ming framework enables a network operator or an application to specify a packet
processing program by encoding a sequence of instructions in the IPv6 packet hea
der.</t>
<t indent="0">Each instruction is implemented on one or several no
des in the network and identified by an SRv6 Segment Identifier in the packet.</
t>
<t indent="0">This document defines the SRv6 Network Programming c
oncept and specifies the base set of SRv6 behaviors that enables the creation of
interoperable overlays with underlay optimization.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8986"/>
<seriesInfo name="DOI" value="10.17487/RFC8986"/>
</reference>
</references>
<references pn="section-12.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="I-D.bryant-ipfrr-tunnels" target="https://datatracker
.ietf.org/doc/html/draft-bryant-ipfrr-tunnels-03" quoteTitle="true" derivedAncho
r="IPFRR-TUNNELS">
<front>
<title>IP Fast Reroute using tunnels</title>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils
">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Mike Shand" initials="M." surname="Shand">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<date day="16" month="November" year="2007"/>
<abstract>
<t indent="0">This draft describes an IP fast re-route mechanism t
hat provides backup connectivity in the event of a link or router failure. In th
e absence of single points of failure and asymmetric costs, the mechanism provid
es complete protection against any single failure. If perfect repair is not poss
ible, the identity of all the unprotected links and routers is known in advance.
This IP Fast Reroute advanced method was invented in 2002 and draft (draft-brya
nt-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It
was one of the first methods of achieving full repair coverage in an IP Network
, and as such the draft has been widely referenced in the academic literature. T
he authors DO NOT propose that this IPFRR method be implemented since better IPF
RR advanced method capable of achieving full repair coverage have subsequently b
een invented.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-bryant-ipfrr-tunnels-03
"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC5286" target="https://www.rfc-editor.org/info/rfc5
286" quoteTitle="true" derivedAnchor="RFC5286">
<front>
<title>Basic Specification for IP Fast Reroute: Loop-Free Alternates
</title>
<author fullname="A. Atlas" initials="A." role="editor" surname="Atl
as"/>
<author fullname="A. Zinin" initials="A." role="editor" surname="Zin
in"/>
<date month="September" year="2008"/>
<abstract>
<t indent="0">This document describes the use of loop-free alterna
tes to provide local protection for unicast traffic in pure IP and MPLS/LDP netw
orks in the event of a single failure, whether link, node, or shared risk link g
roup (SRLG). The goal of this technology is to reduce the packet loss that happe
ns while routers converge after a topology change due to a failure. Rapid failur
e repair is achieved through use of precalculated backup next-hops that are loop
-free and safe to use until the distributed network convergence process complete
s. This simple approach does not require any support from other routers. The ext
ent to which this goal can be met by this specification is dependent on the topo
logy of the network. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5286"/>
<seriesInfo name="DOI" value="10.17487/RFC5286"/>
</reference>
<reference anchor="RFC5714" target="https://www.rfc-editor.org/info/rfc5
714" quoteTitle="true" derivedAnchor="RFC5714">
<front>
<title>IP Fast Reroute Framework</title>
<author fullname="M. Shand" initials="M." surname="Shand"/>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<date month="January" year="2010"/>
<abstract>
<t indent="0">This document provides a framework for the developme
nt of IP fast- reroute mechanisms that provide protection against link or router
failure by invoking locally determined repair paths. Unlike MPLS fast-reroute,
the mechanisms are applicable to a network employing conventional IP routing and
forwarding. This document is not an Internet Standards Track specification; it
is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5714"/>
<seriesInfo name="DOI" value="10.17487/RFC5714"/>
</reference>
<reference anchor="RFC5715" target="https://www.rfc-editor.org/info/rfc5
715" quoteTitle="true" derivedAnchor="RFC5715">
<front>
<title>A Framework for Loop-Free Convergence</title>
<author fullname="M. Shand" initials="M." surname="Shand"/>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<date month="January" year="2010"/>
<abstract>
<t indent="0">A micro-loop is a packet forwarding loop that may oc
cur transiently among two or more routers in a hop-by-hop packet forwarding para
digm.</t>
<t indent="0">This framework provides a summary of the causes and
consequences of micro-loops and enables the reader to form a judgement on whethe
r micro-looping is an issue that needs to be addressed in specific networks. It
also provides a survey of the currently proposed mechanisms that may be used to
prevent or to suppress the formation of micro-loops when an IP or MPLS network u
ndergoes topology change due to failure, repair, or management action. When suff
iciently fast convergence is not available and the topology is susceptible to mi
cro-loops, use of one or more of these mechanisms may be desirable. This documen
t is not an Internet Standards Track specification; it is published for informat
ional purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5715"/>
<seriesInfo name="DOI" value="10.17487/RFC5715"/>
</reference>
<reference anchor="RFC6571" target="https://www.rfc-editor.org/info/rfc6
571" quoteTitle="true" derivedAnchor="RFC6571">
<front>
<title>Loop-Free Alternate (LFA) Applicability in Service Provider (
SP) Networks</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="P. Francois" initials="P." role="editor" surname="
Francois"/>
<author fullname="M. Shand" initials="M." surname="Shand"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
<author fullname="N. Leymann" initials="N." surname="Leymann"/>
<author fullname="M. Horneffer" initials="M." surname="Horneffer"/>
<date month="June" year="2012"/>
<abstract>
<t indent="0">In this document, we analyze the applicability of th
e Loop-Free Alternate (LFA) method of providing IP fast reroute in both the core
and access parts of Service Provider networks. We consider both the link and no
de failure cases, and provide guidance on the applicability of LFAs to different
network topologies, with special emphasis on the access parts of the network. T
his document is not an Internet Standards Track specification; it is published f
or informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6571"/>
<seriesInfo name="DOI" value="10.17487/RFC6571"/>
</reference>
<reference anchor="RFC6976" target="https://www.rfc-editor.org/info/rfc6
976" quoteTitle="true" derivedAnchor="RFC6976">
<front>
<title>Framework for Loop-Free Convergence Using the Ordered Forward
ing Information Base (oFIB) Approach</title>
<author fullname="M. Shand" initials="M." surname="Shand"/>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<author fullname="S. Previdi" initials="S." surname="Previdi"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="P. Francois" initials="P." surname="Francois"/>
<author fullname="O. Bonaventure" initials="O." surname="Bonaventure
"/>
<date month="July" year="2013"/>
<abstract>
<t indent="0">This document describes an illustrative framework of
a mechanism for use in conjunction with link-state routing protocols that preve
nts the transient loops that would otherwise occur during topology changes. It d
oes this by correctly sequencing the forwarding information base (FIB) updates o
n the routers.</t>
<t indent="0">This mechanism can be used in the case of non-urgent
(management action) link or node shutdowns and restarts or link metric changes.
It can also be used in conjunction with a fast reroute mechanism that converts
a sudden link or node failure into a non-urgent topology change. This is possibl
e where a complete repair path is provided for all affected destinations.</t>
<t indent="0">After a non-urgent topology change, each router comp
utes a rank that defines the time at which it can safely update its FIB. A metho
d for accelerating this loop-free convergence process by the use of completion m
essages is also described.</t>
<t indent="0">The technology described in this document has been s
ubject to extensive simulation using pathological convergence behavior and real
network topologies and costs. However, the mechanisms described in this document
are purely illustrative of the general approach and do not constitute a protoco
l specification. This document represents a snapshot of the work of the Routing
Area Working Group at the time of publication and is published as a document of
record. Further work is needed before implementation or deployment.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6976"/>
<seriesInfo name="DOI" value="10.17487/RFC6976"/>
</reference>
<reference anchor="RFC7490" target="https://www.rfc-editor.org/info/rfc7
490" quoteTitle="true" derivedAnchor="RFC7490">
<front>
<title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="S. Previdi" initials="S." surname="Previdi"/>
<author fullname="M. Shand" initials="M." surname="Shand"/>
<author fullname="N. So" initials="N." surname="So"/>
<date month="April" year="2015"/>
<abstract>
<t indent="0">This document describes an extension to the basic IP
fast reroute mechanism, described in RFC 5286, that provides additional backup
connectivity for point-to-point link failures when none can be provided by the b
asic mechanisms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7490"/>
<seriesInfo name="DOI" value="10.17487/RFC7490"/>
</reference>
<reference anchor="RFC8333" target="https://www.rfc-editor.org/info/rfc8
333" quoteTitle="true" derivedAnchor="RFC8333">
<front>
<title>Micro-loop Prevention by Introducing a Local Convergence Dela
y</title>
<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="P. Francois" initials="P." surname="Francois"/>
<date month="March" year="2018"/>
<abstract>
<t indent="0">This document describes a mechanism for link-state r
outing protocols that prevents local transient forwarding loops in case of link
failure. This mechanism proposes a two-step convergence by introducing a delay b
etween the convergence of the node adjacent to the topology change and the netwo
rk-wide convergence.</t>
<t indent="0">Because this mechanism delays the IGP convergence, i
t may only be used for planned maintenance or when Fast Reroute (FRR) protects t
he traffic during the time between the link failure and the IGP convergence.</t>
<t indent="0">The mechanism is limited to the link-down event in o
rder to keep the mechanism simple.</t>
<t indent="0">Simulations using real network topologies have been
performed and show that local loops are a significant portion (&gt;50%) of the t
otal forwarding loops.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8333"/>
<seriesInfo name="DOI" value="10.17487/RFC8333"/>
</reference>
<reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8
665" quoteTitle="true" derivedAnchor="RFC8665">
<front>
<title>OSPF Extensions for Segment Routing</title>
<author fullname="P. Psenak" initials="P." role="editor" surname="Ps
enak"/>
<author fullname="S. Previdi" initials="S." role="editor" surname="P
revidi"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="H. Gredler" initials="H." surname="Gredler"/>
<author fullname="R. Shakir" initials="R." surname="Shakir"/>
<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
>
<author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
<date month="December" year="2019"/>
<abstract>
<t indent="0">Segment Routing (SR) allows a flexible definition of
end-to-end paths within IGP topologies by encoding paths as sequences of topolo
gical subpaths called "segments". These segments are advertised by the link-stat
e routing protocols (IS-IS and OSPF).</t>
<t indent="0">This document describes the OSPFv2 extensions requir
ed for Segment Routing.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8665"/>
<seriesInfo name="DOI" value="10.17487/RFC8665"/>
</reference>
<reference anchor="RFC8667" target="https://www.rfc-editor.org/info/rfc8
667" quoteTitle="true" derivedAnchor="RFC8667">
<front>
<title>IS-IS Extensions for Segment Routing</title>
<author fullname="S. Previdi" initials="S." role="editor" surname="P
revidi"/>
<author fullname="L. Ginsberg" initials="L." role="editor" surname="
Ginsberg"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="A. Bashandy" initials="A." surname="Bashandy"/>
<author fullname="H. Gredler" initials="H." surname="Gredler"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<date month="December" year="2019"/>
<abstract>
<t indent="0">Segment Routing (SR) allows for a flexible definitio
n of end-to-end paths within IGP topologies by encoding paths as sequences of to
pological sub-paths, called "segments". These segments are advertised by the lin
k-state routing protocols (IS-IS and OSPF).</t>
<t indent="0">This document describes the IS-IS extensions that ne
ed to be introduced for Segment Routing operating on an MPLS data plane.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8667"/>
<seriesInfo name="DOI" value="10.17487/RFC8667"/>
</reference>
<reference anchor="RFC9256" target="https://www.rfc-editor.org/info/rfc9
256" quoteTitle="true" derivedAnchor="RFC9256">
<front>
<title>Segment Routing Policy Architecture</title>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="K. Talaulikar" initials="K." role="editor" surname
="Talaulikar"/>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<author fullname="A. Bogdanov" initials="A." surname="Bogdanov"/>
<author fullname="P. Mattes" initials="P." surname="Mattes"/>
<date month="July" year="2022"/>
<abstract>
<t indent="0">Segment Routing (SR) allows a node to steer a packet
flow along any path. Intermediate per-path states are eliminated thanks to sour
ce routing. SR Policy is an ordered list of segments (i.e., instructions) that r
epresent a source-routed policy. Packet flows are steered into an SR Policy on a
node where it is instantiated called a headend node. The packets steered into a
n SR Policy carry an ordered list of segments associated with that SR Policy.</t
>
<t indent="0">This document updates RFC 8402 as it details the con
cepts of SR Policy and steering into an SR Policy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9256"/>
<seriesInfo name="DOI" value="10.17487/RFC9256"/>
</reference>
<reference anchor="RFC9350" target="https://www.rfc-editor.org/info/rfc9
350" quoteTitle="true" derivedAnchor="RFC9350">
<front>
<title>IGP Flexible Algorithm</title>
<author fullname="P. Psenak" initials="P." role="editor" surname="Ps
enak"/>
<author fullname="S. Hegde" initials="S." surname="Hegde"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="K. Talaulikar" initials="K." surname="Talaulikar"/
>
<author fullname="A. Gulko" initials="A." surname="Gulko"/>
<date month="February" year="2023"/>
<abstract>
<t indent="0">IGP protocols historically compute the best paths ov
er the network based on the IGP metric assigned to the links. Many network deplo
yments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer tra
ffic over a path that is computed using different metrics or constraints than th
e shortest IGP path. This document specifies a solution that allows IGPs themsel
ves to compute constraint-based paths over the network. This document also speci
fies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer
packets along the constraint-based paths.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9350"/>
<seriesInfo name="DOI" value="10.17487/RFC9350"/>
</reference>
<reference anchor="I-D.bashandy-rtgwg-segment-routing-uloop" target="htt
ps://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-17
" quoteTitle="true" derivedAnchor="SR-LOOP">
<front>
<title>Loop avoidance using Segment Routing</title>
<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils
">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Stephane Litkowski" initials="S." surname="Litkows
ki">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization showOnFrontPage="true">Orange</organization>
</author>
<author fullname="Pierre Francois" initials="P." surname="Francois">
<organization showOnFrontPage="true">INSA Lyon</organization>
</author>
<author fullname="Peter Psenak" initials="P." surname="Psenak">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<date day="29" month="June" year="2024"/>
<abstract>
<t indent="0">This document presents a mechanism aimed at providin
g loop avoidance in the case of IGP network convergence event. The solution reli
es on the temporary use of SR policies ensuring loop-freeness over the post-conv
ergence paths from the converging node to the destination.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-bashandy-rtgwg-segment-
routing-uloop-17"/>
<refcontent>Work in Progress</refcontent>
</reference>
</references>
</references> </references>
<section anchor="advantages-post-conv-path" <section anchor="advantages-post-conv-path" numbered="true" toc="include" re
title="Advantages of using the expected post-convergence path durin moveInRFC="false" pn="section-appendix.a">
g FRR"> <name slugifiedName="name-advantages-of-using-the-exp">Advantages of Using
<t><xref target="RFC7916"/> raised several operational considerations the Expected Post-Convergence Path During FRR</name>
when using LFA or remote LFA. <xref target="RFC7916"/> Section 3 <t indent="0" pn="section-appendix.a-1"><xref target="RFC7916" format="def
ault" sectionFormat="of" derivedContent="RFC7916"/> raises several operational c
onsiderations
when using LFA or RLFA. <xref target="RFC7916" sectionFormat="of" section=
"3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7916#section-3"
derivedContent="RFC7916"/>
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" sectionFormat="of" deri vedContent="RFC7916"/> introduces a local policy 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 indent="0" pn="section-appendix.a-2">From a network capacity planning p
<t>From a network capacity planning point of view, it is often assumed oint 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="figu
target="figure1"/>, we consider a network with all metrics equal to 1 re1" format="default" sectionFormat="of" derivedContent="Figure 3"/>, we conside
except the metrics on links used by PE1, PE2 and PE3 which are 1000. An r a network with all
easy network capacity planning method is to consider that if the link L metrics equal to 1 except the metrics on links used by PE1, PE2, and PE3,
(X-B) fails, the traffic actually flowing through L will be spread over which are 1000. An easy network capacity planning method is to consider
the remaining links of X (X-H, X-D, X-A). Considering the IGP metrics, that if the link L (X-B) fails, the traffic actually flowing through L
only X-H and X-D can be used in reality to carry the traffic flowing will be spread over the remaining links of X (X-H, X-D,
through the link L. As a consequence, the bandwidth of links X-H and X-D X-A). Considering the IGP metrics, only X-H and X-D can be used in
is sized according to this rule. We should observe that this capacity reality to carry the traffic flowing through the link L. As a
planning policy works, however it is not fully accurate.</t> consequence, the bandwidth of links X-H and X-D is sized according to
this rule. We should observe that this capacity planning policy works;
<t>In <xref target="figure1"/>, considering that the source of traffic however, it is not fully accurate.</t>
<t indent="0" pn="section-appendix.a-3">In <xref target="figure1" format="
default" sectionFormat="of" derivedContent="Figure 3"/>, considering that the so
urce 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" align="left" suppress-title="false" pn="figure-3"
<figure anchor="figure1"> >
<artwork> <artwork name="" type="" align="left" alt="" pn="section-appendix.a-4.1"
>
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 indent="0" pn="section-appendix.a-5">Based on this assumption, in order
<t>Based on this assumption, in order to facilitate the operation of 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 indent="0" pn="section-appendix.a-6">It should be noted that some netwo
<t>It should be noted, that some networks may have a different capacity rks 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" sectionFormat ="of" derivedContent="RFC7916"/> if the usage 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 indent="0" pn="section-appendix.a-7">Readers should be aware that FRR p
<t>Readers should be aware that FRR protection is pre-computing a backup rotection 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 indent="0" pn="section-appendix.a-8">Another consideration to take into
<t>Another consideration to take into account is: while using the 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
target="RFC9256"/>) are involved. A segment-list used in an SR policy is " format="default" sectionFormat="of" derivedContent="RFC9256"/> are involved. A
computed to obey a set of path constraints defined locally at the segment list used in
head-end or centrally in a controller. TI-LFA cannot be aware of such an SR policy is computed to obey a set of path constraints defined
path constraints and there is no reason to expect the TI-LFA backup path locally at the head-end or centrally in a controller. TI-LFA cannot be
protecting one segments in that segment list to obey those constraints. aware of such path constraints, and there is no reason to expect the
When SR policies are used and the operator wants to have a backup path TI-LFA backup path protecting one segment in that segment list to obey
which still follows the policy requirements, this backup path should be those constraints. When SR policies are used and the operator wants to
computed as part of the SR policy in the ingress node (or central have a backup path that still follows the policy requirements, this
controller) and the SR policy should not rely on local protection. backup path should be computed as part of the SR policy in the ingress
Another option could be to use FlexAlgo (<xref target="RFC9350"/>) to node (or central controller), and the SR policy should not rely on local
express the set of constraints and use a single node segment associated protection. Another option could be to use a Flexible Algorithm <xref tar
with a FlexAlgo to reach the destination. When using a node segment get="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/> to
associated with a FlexAlgo, TI-LFA keeps providing an optimal backup by express the set of constraints
applying the appropriate set of constraints. The relationship between and use a single node segment associated with a Flexible Algorithm to reac
TI-LFA and the SR-algorithm is detailed in <xref h the
target="tilfa-sr-algo"/>.</t> destination. When using a node segment associated with a Flexible Algorith
m,
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" sectionFormat="o
f" derivedContent="Section 8"/>.</t>
</section> </section>
<section anchor="analysis" numbered="true" toc="include" removeInRFC="false"
<section anchor="analysis" pn="section-appendix.b">
title="Analysis based on real network topologies"> <name slugifiedName="name-analysis-based-on-real-netw">Analysis Based on R
<t>This section presents analysis performed on real service provider and eal Network Topologies</name>
<t indent="0" pn="section-appendix.b-1">This section presents an analysis
performed on real service provider and
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 indent="0" pn="section-appendix.b-2">The measurement below indicates th
<t>The measurement below indicate that for link and local SRLG at, for link and local SRLG
protection, a 1 SID repair path delivers more than 99% coverage. For protection, a repair path of 1 SID or less delivers more than 99% coverage
node protection a 2 SIDs repair path yields 99% coverage.</t> . For
node protection, a repair path of 2 SIDs or less yields 99% coverage.</t>
<t>Table 1 below lists the characteristics of the networks used in our <t indent="0" pn="section-appendix.b-3"><xref target="t-1" format="default
" sectionFormat="of" derivedContent="Table 1"/> below lists the characteristics
of the networks used 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" bare="false" empty="false" indent="3" pn="section-app
<t><list style="symbols"> endix.b-4">
<t>For each network, the algorithms described in this document are <li pn="section-appendix.b-4.1">
<t indent="0" pn="section-appendix.b-4.1.1">For each network, the algo
rithms 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>
<t>For each prefix, the number of SIDs used by the repair path is <li pn="section-appendix.b-4.2">
recorded</t> <t indent="0" pn="section-appendix.b-4.2.1">For each prefix, the numbe
r of SIDs used by the repair path is
<t>The percentage of number of SIDs are listed in Tables 2A/B, 3A/B, recorded.</t>
and 4A/B</t> </li>
</list></t> <li pn="section-appendix.b-4.3">
<t indent="0" pn="section-appendix.b-4.3.1">The percentage of number o
<t>The measurements listed in the tables indicate that for link and f SIDs are listed in Tables <xref target="t-2" format="counter" sectionFormat="o
local SRLG protection, 1 SID repair path is sufficient to protect more f" derivedContent="2"/>, <xref target="t-3" format="counter" sectionFormat="of"
than 99% of the prefix in almost all cases. For node protection 2 SIDs derivedContent="3"/>, <xref target="t-4" format="counter" sectionFormat="of" der
repair paths yield 99% coverage.</t> ivedContent="4"/>, <xref target="t-5" format="counter" sectionFormat="of" derive
dContent="5"/>, <xref target="t-6" format="counter" sectionFormat="of" derivedCo
<figure> ntent="6"/>, and <xref target="t-7" format="counter" sectionFormat="of" derivedC
<artwork> ontent="7"/>.</t>
+-------------+------------+------------+------------+------------+ </li>
| Network | Nodes | Links |Node-to-Link| SRLG info? | </ul>
| | | | Ratio | | <table anchor="t-1" align="center" pn="table-1">
+-------------+------------+------------+------------+------------+ <name slugifiedName="name-data-set-definition">Data Set Definition</name
| T1 | 408 | 665 | 1.63 | Yes | >
+-------------+------------+------------+------------+------------+ <thead>
| T2 | 587 | 1083 | 1.84 | No | <tr>
+-------------+------------+------------+------------+------------+ <th align="left" colspan="1" rowspan="1">Network</th>
| T3 | 93 | 401 | 4.31 | Yes | <th align="left" colspan="1" rowspan="1">Nodes</th>
+-------------+------------+------------+------------+------------+ <th align="left" colspan="1" rowspan="1">Links</th>
| T4 | 247 | 393 | 1.59 | Yes | <th align="left" colspan="1" rowspan="1">Node-to-Link Ratio</th>
+-------------+------------+------------+------------+------------+ <th align="left" colspan="1" rowspan="1">SRLG Info?</th>
| T5 | 34 | 96 | 2.82 | Yes | </tr>
+-------------+------------+------------+------------+------------+ </thead>
| T6 | 50 | 78 | 1.56 | No | <tbody>
+-------------+------------+------------+------------+------------+ <tr>
| T7 | 82 | 293 | 3.57 | No | <td align="left" colspan="1" rowspan="1">T1</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">408</td>
| T8 | 35 | 41 | 1.17 | Yes | <td align="left" colspan="1" rowspan="1">665</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">1.63</td>
| T9 | 177 | 1371 | 7.74 | Yes | <td align="left" colspan="1" rowspan="1">Yes</td>
+-------------+------------+------------+------------+------------+ </tr>
Table 1: Data Set Definition <tr>
</artwork> <td align="left" colspan="1" rowspan="1">T2</td>
</figure> <td align="left" colspan="1" rowspan="1">587</td>
<td align="left" colspan="1" rowspan="1">1083</td>
<t>The rest of this section presents the measurements done on the actual <td align="left" colspan="1" rowspan="1">1.84</td>
topologies. The convention that we use is as follows</t> <td align="left" colspan="1" rowspan="1">No</td>
</tr>
<t><list style="symbols"> <tr>
<t>0 SIDs: the calculated repair path starts with a directly <td align="left" colspan="1" rowspan="1">T3</td>
connected neighbor that is also a loop free alternate, in which case <td align="left" colspan="1" rowspan="1">93</td>
<td align="left" colspan="1" rowspan="1">401</td>
<td align="left" colspan="1" rowspan="1">4.31</td>
<td align="left" colspan="1" rowspan="1">Yes</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T4</td>
<td align="left" colspan="1" rowspan="1">247</td>
<td align="left" colspan="1" rowspan="1">393</td>
<td align="left" colspan="1" rowspan="1">1.59</td>
<td align="left" colspan="1" rowspan="1">Yes</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T5</td>
<td align="left" colspan="1" rowspan="1">34</td>
<td align="left" colspan="1" rowspan="1">96</td>
<td align="left" colspan="1" rowspan="1">2.82</td>
<td align="left" colspan="1" rowspan="1">Yes</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T6</td>
<td align="left" colspan="1" rowspan="1">50</td>
<td align="left" colspan="1" rowspan="1">78</td>
<td align="left" colspan="1" rowspan="1">1.56</td>
<td align="left" colspan="1" rowspan="1">No</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T7</td>
<td align="left" colspan="1" rowspan="1">82</td>
<td align="left" colspan="1" rowspan="1">293</td>
<td align="left" colspan="1" rowspan="1">3.57</td>
<td align="left" colspan="1" rowspan="1">No</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T8</td>
<td align="left" colspan="1" rowspan="1">35</td>
<td align="left" colspan="1" rowspan="1">41</td>
<td align="left" colspan="1" rowspan="1">1.17</td>
<td align="left" colspan="1" rowspan="1">Yes</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T9</td>
<td align="left" colspan="1" rowspan="1">177</td>
<td align="left" colspan="1" rowspan="1">1371</td>
<td align="left" colspan="1" rowspan="1">7.74</td>
<td align="left" colspan="1" rowspan="1">Yes</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-appendix.b-6">The rest of this section presents
the measurements done on the actual
topologies. The conventions that we use are as follows:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app
endix.b-7">
<li pn="section-appendix.b-7.1">
<t indent="0" pn="section-appendix.b-7.1.1">0 SIDs: The calculated rep
air path starts with a directly
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" sectionFormat="of" derivedContent="Section 5.1"/>.</t>
</li>
<t>1 SIDs: the repair node is a PQ node, in which case only 1 SID is <li pn="section-appendix.b-7.2">
<t indent="0" pn="section-appendix.b-7.2.1">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" sectionFormat="of" derivedCo
ntent="Section 5.2"/>.</t>
<t>2 or more SIDs: The repair path consists of 2 or more SIDs as </li>
described in <xref target="adj_pq_backup"/> and <xref <li pn="section-appendix.b-7.3">
target="remote_pq_backup"/>. We do not cover the case for 2 SIDs <t indent="0" pn="section-appendix.b-7.3.1">2 or more SIDs: The repair
(<xref target="adj_pq_backup"/>) separately because there was no path consists of 2 or more SIDs as
granularity in the result. Also we treat the node-SID+adj-SID and described in Sections <xref target="adj_pq_backup" format="counter" se
node-SID + node-SID the same because they do not differ from the ctionFormat="of" derivedContent="5.3"/> and
data plane point of view.</t> <xref target="remote_pq_backup" format="counter" sectionFormat="of" de
</list></t> rivedContent="5.4"/>. We do not cover
the case for 2 SIDs (<xref target="adj_pq_backup" format="default" sec
<t>Table 2A and 2B below summarize the measurements on the number of tionFormat="of" derivedContent="Section 5.3"/>) separately because there was no
SIDs needed for link protection</t> granularity in
the result. Also, we treat the Node-SID + Adj-SID and Node-SID +
<figure> Node-SID the same because they do not differ from the data plane
<artwork> point of view.</t>
+-------------+------------+------------+------------+------------+ </li>
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | </ul>
+-------------+------------+------------+------------+------------+ <t indent="0" pn="section-appendix.b-8">Tables <xref target="t-2" format="
| T1 | 74.3% | 25.3% | 0.5% | 0.0% | counter" sectionFormat="of" derivedContent="2"/> and <xref target="t-3" format="
+-------------+------------+------------+------------+------------+ counter" sectionFormat="of" derivedContent="3"/> below summarize the measurement
| T2 | 81.1% | 18.7% | 0.2% | 0.0% | s on
+-------------+------------+------------+------------+------------+ the number of SIDs needed for link protection.</t>
| T3 | 95.9% | 4.1% | 0.1% | 0.0% | <table anchor="t-2" align="center" pn="table-2">
+-------------+------------+------------+------------+------------+ <name slugifiedName="name-link-protection-repair-size">Link Protection (
| T4 | 62.5% | 35.7% | 1.8% | 0.0% | Repair Size Distribution)</name>
+-------------+------------+------------+------------+------------+ <thead>
| T5 | 85.7% | 14.3% | 0.0% | 0.0% | <tr>
+-------------+------------+------------+------------+------------+ <th align="left" colspan="1" rowspan="1">Network</th>
| T6 | 81.2% | 18.7% | 0.0% | 0.0% | <th align="left" colspan="1" rowspan="1">0 SIDs</th>
+-------------+------------+------------+------------+------------+ <th align="left" colspan="1" rowspan="1">1 SID</th>
| T7 | 98.9% | 1.1% | 0.0% | 0.0% | <th align="left" colspan="1" rowspan="1">2 SIDs</th>
+-------------+------------+------------+------------+------------+ <th align="left" colspan="1" rowspan="1">3 SIDs</th>
| T8 | 94.1% | 5.9% | 0.0% | 0.0% | </tr>
+-------------+------------+------------+------------+------------+ </thead>
| T9 | 98.9% | 1.0% | 0.0% | 0.0% | <tbody>
+-------------+------------+------------+------------+------------+ <tr>
Table 2A: Link protection (repair size distribution) <td align="left" colspan="1" rowspan="1">T1</td>
<td align="left" colspan="1" rowspan="1">74.3%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">25.3%</td>
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | <td align="left" colspan="1" rowspan="1">0.5%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">0.0%</td>
| T1 | 74.2% | 99.5% | 99.9% | 100.0% | </tr>
+-------------+------------+------------+------------+------------+ <tr>
| T2 | 81.1% | 99.8% | 100.0% | 100.0% | <td align="left" colspan="1" rowspan="1">T2</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">81.1%</td>
| T3 | 95.9% | 99.9% | 100.0% | 100.0% | <td align="left" colspan="1" rowspan="1">18.7%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">0.2%</td>
| T4 | 62.5% | 98.2% | 100.0% | 100.0% | <td align="left" colspan="1" rowspan="1">0.0%</td>
+-------------+------------+------------+------------+------------+ </tr>
| T5 | 85.7% | 100.0% | 100.0% | 100.0% | <tr>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">T3</td>
| T6 | 81.2% | 99.9% | 100.0% | 100.0% | <td align="left" colspan="1" rowspan="1">95.9%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">4.1%</td>
| T7 | 98,8% | 100.0% | 100.0% | 100.0% | <td align="left" colspan="1" rowspan="1">0.1%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">0.0%</td>
| T8 | 94,1% | 100.0% | 100.0% | 100.0% | </tr>
+-------------+------------+------------+------------+------------+ <tr>
| T9 | 98,9% | 100.0% | 100.0% | 100.0% | <td align="left" colspan="1" rowspan="1">T4</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">62.5%</td>
Table 2B: Link protection repair size cumulative distribution <td align="left" colspan="1" rowspan="1">35.7%</td>
Table 3A and 3B summarize the measurements on the number of SIDs <td align="left" colspan="1" rowspan="1">1.8%</td>
needed for local SRLG protection. <td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
+-------------+------------+------------+------------+------------+ <tr>
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | <td align="left" colspan="1" rowspan="1">T5</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">85.7%</td>
| T1 | 74.2% | 25.3% | 0.5% | 0.0% | <td align="left" colspan="1" rowspan="1">14.3%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">0.0%</td>
| T2 | No SRLG Information | <td align="left" colspan="1" rowspan="1">0.0%</td>
+-------------+------------+------------+------------+------------+ </tr>
| T3 | 93.6% | 6.3% | 0.0% | 0.0% | <tr>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">T6</td>
| T4 | 62.5% | 35.6% | 1.8% | 0.0% | <td align="left" colspan="1" rowspan="1">81.2%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">18.7%</td>
| T5 | 83.1% | 16.8% | 0.0% | 0.0% | <td align="left" colspan="1" rowspan="1">0.0%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">0.0%</td>
| T6 | No SRLG Information | </tr>
+-------------+---------------------------------------------------+ <tr>
| T7 | No SRLG Information | <td align="left" colspan="1" rowspan="1">T7</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">98.9%</td>
| T8 | 85.2% | 14.8% | 0.0% | 0.0% | <td align="left" colspan="1" rowspan="1">1.1%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">0.0%</td>
| T9 | 98,9% | 1.1% | 0.0% | 0.0% | <td align="left" colspan="1" rowspan="1">0.0%</td>
+-------------+------------+------------+------------+------------+ </tr>
Table 3A: Local SRLG protection repair size distribution <tr>
<td align="left" colspan="1" rowspan="1">T8</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">94.1%</td>
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | <td align="left" colspan="1" rowspan="1">5.9%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">0.0%</td>
| T1 | 74.2% | 99.5% | 99.9% | 100.0% | <td align="left" colspan="1" rowspan="1">0.0%</td>
+-------------+------------+------------+------------+------------+ </tr>
| T2 | No SRLG Information | <tr>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">T9</td>
| T3 | 93.6% | 99.9% | 100.0% | 0.0% | <td align="left" colspan="1" rowspan="1">98.9%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">1.0%</td>
| T4 | 62.5% | 98.2% | 100.0% | 100.0% | <td align="left" colspan="1" rowspan="1">0.0%</td>
+-------------+------------+------------+------------+------------+ <td align="left" colspan="1" rowspan="1">0.0%</td>
| T5 | 83.1% | 100.0% | 100.0% | 100.0% | </tr>
+-------------+------------+------------+------------+------------+ </tbody>
| T6 | No SRLG Information | </table>
+-------------+---------------------------------------------------+ <table anchor="t-3" align="center" pn="table-3">
| T7 | No SRLG Information | <name slugifiedName="name-link-protection-repair-size-">Link Protection
+-------------+------------+------------+------------+------------+ (Repair Size Cumulative Distribution)</name>
| T8 | 85.2% | 100.0% | 100.0% | 100.0% | <thead>
+-------------+------------+------------+------------+------------+ <tr>
| T9 | 98.9% | 100.0% | 100.0% | 100.0% | <th align="left" colspan="1" rowspan="1">Network</th>
+-------------+------------+------------+------------+------------+ <th align="left" colspan="1" rowspan="1">0 SIDs</th>
Table 3B: Local SRLG protection repair size Cumulative distribution <th align="left" colspan="1" rowspan="1">1 SID</th>
The remaining two tables summarize the measurements on the number of <th align="left" colspan="1" rowspan="1">2 SIDs</th>
SIDs needed for node protection. <th align="left" colspan="1" rowspan="1">3 SIDs</th>
</tr>
+---------+----------+----------+----------+----------+----------+ </thead>
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | <tbody>
+---------+----------+----------+----------+----------+----------+ <tr>
| T1 | 49.8% | 47.9% | 2.1% | 0.1% | 0.0% | <td align="left" colspan="1" rowspan="1">T1</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">74.2%</td>
| T2 | 36,5% | 59.6% | 3.6% | 0.2% | 0.0% | <td align="left" colspan="1" rowspan="1">99.5%</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">99.9%</td>
| T3 | 73.3% | 25.6% | 1.1% | 0.0% | 0.0% | <td align="left" colspan="1" rowspan="1">100%</td>
+---------+----------+----------+----------+----------+----------+ </tr>
| T4 | 36.1% | 57.3% | 6.3% | 0.2% | 0.0% | <tr>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">T2</td>
| T5 | 73.2% | 26.8% | 0% | 0% | 0% | <td align="left" colspan="1" rowspan="1">81.1%</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">99.8%</td>
| T6 | 78.3% | 21.3% | 0.3% | 0% | 0% | <td align="left" colspan="1" rowspan="1">100%</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">100%</td>
| T7 | 66.1% | 32.8% | 1.1% | 0% | 0% | </tr>
+---------+----------+----------+----------+----------+----------+ <tr>
| T8 | 59.7% | 40.2% | 0% | 0% | 0% | <td align="left" colspan="1" rowspan="1">T3</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">95.9%</td>
| T9 | 98.9% | 1.0% | 0% | 0% | 0% | <td align="left" colspan="1" rowspan="1">99.9%</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">100%</td>
Table 4A: Node protection (repair size distribution) <td align="left" colspan="1" rowspan="1">100%</td>
</tr>
+---------+----------+----------+----------+----------+----------+ <tr>
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | <td align="left" colspan="1" rowspan="1">T4</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">62.5%</td>
| T1 | 49.7% | 97.6% | 99.8% | 99.9% | 100% | <td align="left" colspan="1" rowspan="1">98.2%</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">100%</td>
| T2 | 36.5% | 96.1% | 99.7% | 99.9% | 100% | <td align="left" colspan="1" rowspan="1">100%</td>
+---------+----------+----------+----------+----------+----------+ </tr>
| T3 | 73.3% | 98.9% | 99.9% | 100.0% | 100% | <tr>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">T5</td>
| T4 | 36.1% | 93.4% | 99.8% | 99.9% | 100% | <td align="left" colspan="1" rowspan="1">85.7%</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">100%</td>
| T5 | 73.2% | 100.0% | 100.0% | 100.0% | 100% | <td align="left" colspan="1" rowspan="1">100%</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">100%</td>
| T6 | 78.4% | 99.7% | 100.0% | 100.0% | 100% | </tr>
+---------+----------+----------+----------+----------+----------+ <tr>
| T7 | 66.1% | 98.9% | 100.0% | 100.0% | 100% | <td align="left" colspan="1" rowspan="1">T6</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">81.2%</td>
| T8 | 59.7% | 100.0% | 100.0% | 100.0% | 100% | <td align="left" colspan="1" rowspan="1">99.9%</td>
+---------+----------+----------+----------+----------+----------+ <td align="left" colspan="1" rowspan="1">100%</td>
| T9 | 98.9% | 100.0% | 100.0% | 100.0% | 100% | <td align="left" colspan="1" rowspan="1">100%</td>
+---------+----------+----------+----------+----------+----------+ </tr>
Table 4B: Node protection (repair size cumulative distribution) <tr>
</artwork> <td align="left" colspan="1" rowspan="1">T7</td>
</figure> <td align="left" colspan="1" rowspan="1">98.8%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T8</td>
<td align="left" colspan="1" rowspan="1">94.1%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T9</td>
<td align="left" colspan="1" rowspan="1">98.9%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-appendix.b-11">Tables <xref target="t-4" format=
"counter" sectionFormat="of" derivedContent="4"/> and <xref target="t-5" format=
"counter" sectionFormat="of" derivedContent="5"/> summarize the measurements on
the number of SIDs needed for
local SRLG protection.</t>
<table anchor="t-4" align="center" pn="table-4">
<name slugifiedName="name-local-srlg-protection-repai">Local SRLG Protec
tion (Repair Size Distribution)</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Network</th>
<th align="left" colspan="1" rowspan="1">0 SIDs</th>
<th align="left" colspan="1" rowspan="1">1 SID</th>
<th align="left" colspan="1" rowspan="1">2 SIDs</th>
<th align="left" colspan="1" rowspan="1">3 SIDs</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">T1</td>
<td align="left" colspan="1" rowspan="1">74.2%</td>
<td align="left" colspan="1" rowspan="1">25.3%</td>
<td align="left" colspan="1" rowspan="1">0.5%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T2</td>
<td colspan="4" align="left" rowspan="1">No SRLG information</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T3</td>
<td align="left" colspan="1" rowspan="1">93.6%</td>
<td align="left" colspan="1" rowspan="1">6.3%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T4</td>
<td align="left" colspan="1" rowspan="1">62.5%</td>
<td align="left" colspan="1" rowspan="1">35.6%</td>
<td align="left" colspan="1" rowspan="1">1.8%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T5</td>
<td align="left" colspan="1" rowspan="1">83.1%</td>
<td align="left" colspan="1" rowspan="1">16.8%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T6</td>
<td colspan="4" align="left" rowspan="1">No SRLG information</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T7</td>
<td colspan="4" align="left" rowspan="1">No SRLG information</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T8</td>
<td align="left" colspan="1" rowspan="1">85.2%</td>
<td align="left" colspan="1" rowspan="1">14.8%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T9</td>
<td align="left" colspan="1" rowspan="1">98.9%</td>
<td align="left" colspan="1" rowspan="1">1.1%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
</tbody>
</table>
<table anchor="t-5" align="center" pn="table-5">
<name slugifiedName="name-local-srlg-protection-repair">Local SRLG Prote
ction (Repair Size Cumulative Distribution)</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Network</th>
<th align="left" colspan="1" rowspan="1">0 SIDs</th>
<th align="left" colspan="1" rowspan="1">1 SID</th>
<th align="left" colspan="1" rowspan="1">2 SIDs</th>
<th align="left" colspan="1" rowspan="1">3 SIDs</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">T1</td>
<td align="left" colspan="1" rowspan="1">74.2%</td>
<td align="left" colspan="1" rowspan="1">99.5%</td>
<td align="left" colspan="1" rowspan="1">99.9%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T2</td>
<td colspan="4" align="left" rowspan="1">No SRLG information</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T3</td>
<td align="left" colspan="1" rowspan="1">93.6%</td>
<td align="left" colspan="1" rowspan="1">99.9%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T4</td>
<td align="left" colspan="1" rowspan="1">62.5%</td>
<td align="left" colspan="1" rowspan="1">98.2%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T5</td>
<td align="left" colspan="1" rowspan="1">83.1%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T6</td>
<td colspan="4" align="left" rowspan="1">No SRLG information</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T7</td>
<td colspan="4" align="left" rowspan="1">No SRLG information</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T8</td>
<td align="left" colspan="1" rowspan="1">85.2%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T9</td>
<td align="left" colspan="1" rowspan="1">98.9%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-appendix.b-14">The remaining two tables summariz
e the measurements on the number of
SIDs needed for node protection.</t>
<table anchor="t-6" align="center" pn="table-6">
<name slugifiedName="name-node-protection-repair-size">Node Protection (
Repair Size Distribution)</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Network</th>
<th align="left" colspan="1" rowspan="1">0 SIDs</th>
<th align="left" colspan="1" rowspan="1">1 SID</th>
<th align="left" colspan="1" rowspan="1">2 SIDs</th>
<th align="left" colspan="1" rowspan="1">3 SIDs</th>
<th align="left" colspan="1" rowspan="1">4 SIDs</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">T1</td>
<td align="left" colspan="1" rowspan="1">49.8%</td>
<td align="left" colspan="1" rowspan="1">47.9%</td>
<td align="left" colspan="1" rowspan="1">2.1%</td>
<td align="left" colspan="1" rowspan="1">0.1%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T2</td>
<td align="left" colspan="1" rowspan="1">36.5%</td>
<td align="left" colspan="1" rowspan="1">59.6%</td>
<td align="left" colspan="1" rowspan="1">3.6%</td>
<td align="left" colspan="1" rowspan="1">0.2%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T3</td>
<td align="left" colspan="1" rowspan="1">73.3%</td>
<td align="left" colspan="1" rowspan="1">25.6%</td>
<td align="left" colspan="1" rowspan="1">1.1%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T4</td>
<td align="left" colspan="1" rowspan="1">36.1%</td>
<td align="left" colspan="1" rowspan="1">57.3%</td>
<td align="left" colspan="1" rowspan="1">6.3%</td>
<td align="left" colspan="1" rowspan="1">0.2%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T5</td>
<td align="left" colspan="1" rowspan="1">73.2%</td>
<td align="left" colspan="1" rowspan="1">26.8%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T6</td>
<td align="left" colspan="1" rowspan="1">78.3%</td>
<td align="left" colspan="1" rowspan="1">21.3%</td>
<td align="left" colspan="1" rowspan="1">0.3%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T7</td>
<td align="left" colspan="1" rowspan="1">66.1%</td>
<td align="left" colspan="1" rowspan="1">32.8%</td>
<td align="left" colspan="1" rowspan="1">1.1%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T8</td>
<td align="left" colspan="1" rowspan="1">59.7%</td>
<td align="left" colspan="1" rowspan="1">40.2%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T9</td>
<td align="left" colspan="1" rowspan="1">98.9%</td>
<td align="left" colspan="1" rowspan="1">1.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
<td align="left" colspan="1" rowspan="1">0.0%</td>
</tr>
</tbody>
</table>
<table anchor="t-7" align="center" pn="table-7">
<name slugifiedName="name-node-protection-repair-size-">Node Protection
(Repair Size Cumulative Distribution)</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Network</th>
<th align="left" colspan="1" rowspan="1">0 SIDs</th>
<th align="left" colspan="1" rowspan="1">1 SID</th>
<th align="left" colspan="1" rowspan="1">2 SIDs</th>
<th align="left" colspan="1" rowspan="1">3 SIDs</th>
<th align="left" colspan="1" rowspan="1">4 SIDs</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">T1</td>
<td align="left" colspan="1" rowspan="1">49.7%</td>
<td align="left" colspan="1" rowspan="1">97.6%</td>
<td align="left" colspan="1" rowspan="1">99.8%</td>
<td align="left" colspan="1" rowspan="1">99.9%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T2</td>
<td align="left" colspan="1" rowspan="1">36.5%</td>
<td align="left" colspan="1" rowspan="1">96.1%</td>
<td align="left" colspan="1" rowspan="1">99.7%</td>
<td align="left" colspan="1" rowspan="1">99.9%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T3</td>
<td align="left" colspan="1" rowspan="1">73.3%</td>
<td align="left" colspan="1" rowspan="1">98.9%</td>
<td align="left" colspan="1" rowspan="1">99.9%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T4</td>
<td align="left" colspan="1" rowspan="1">36.1%</td>
<td align="left" colspan="1" rowspan="1">93.4%</td>
<td align="left" colspan="1" rowspan="1">99.8%</td>
<td align="left" colspan="1" rowspan="1">99.9%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T5</td>
<td align="left" colspan="1" rowspan="1">73.2%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T6</td>
<td align="left" colspan="1" rowspan="1">78.4%</td>
<td align="left" colspan="1" rowspan="1">99.7%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T7</td>
<td align="left" colspan="1" rowspan="1">66.1%</td>
<td align="left" colspan="1" rowspan="1">98.9%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T8</td>
<td align="left" colspan="1" rowspan="1">59.7%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">T9</td>
<td align="left" colspan="1" rowspan="1">98.9%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
<td align="left" colspan="1" rowspan="1">100%</td>
</tr>
</tbody>
</table>
</section>
<section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn=
"section-appendix.c">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.c-1">The authors would like to thank <c
ontact fullname="Les Ginsberg"/>,
<contact fullname="Stewart Bryant"/>, <contact fullname="Alexander V
ainsthein"/>, <contact fullname="Chris Bowers"/>, <contact fullname="Shraddha He
dge"/>, <contact fullname="Wes Hardaker"/>,
<contact fullname="Gunter Van de Velde"/>, and <contact fullname="John
Scudder"/> for their valuable comments.</t>
</section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f
alse" pn="section-appendix.d">
<name slugifiedName="name-contributors">Contributors</name>
<t indent="0" pn="section-appendix.d-1">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 showOnFrontPage="true">Cisco Systems</organization>
</contact>
<contact fullname="Pablo Camarillo">
<organization showOnFrontPage="true">Cisco Systems</organization>
</contact>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.e">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy">
<organization showOnFrontPage="true">HPE</organization>
<address>
<postal>
<country>USA</country>
</postal>
<email>abashandy.ietf@gmail.com</email>
</address>
</author>
<author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
<organization showOnFrontPage="true">Cisco Systems</organization>
<address>
<postal>
<country>France</country>
</postal>
<email>slitkows@cisco.com</email>
</address>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization showOnFrontPage="true">Cisco Systems</organization>
<address>
<postal>
<city>Brussels</city>
<country>Belgium</country>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>
<author fullname="Pierre Francois" initials="P." surname="Francois">
<organization showOnFrontPage="true">INSA Lyon</organization>
<address>
<email>pierre.francois@insa-lyon.fr</email>
</address>
</author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization showOnFrontPage="true">Orange</organization>
<address>
<postal>
<country>France</country>
</postal>
<email>bruno.decraene@orange.com</email>
</address>
</author>
<author fullname="Daniel Voyer" initials="D." surname="Voyer">
<organization showOnFrontPage="true">Bell Canada</organization>
<address>
<postal>
<country>Canada</country>
</postal>
<email>daniel.voyer@bell.ca</email>
</address>
</author>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 123 change blocks. 
1034 lines changed or deleted 2419 lines changed or added

This html diff was produced by rfcdiff 1.48.