<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5384 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml">
<!ENTITY RFC5714 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5714.xml">
<!ENTITY RFC5715 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5715.xml">
<!ENTITY RFC6571 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6571.xml">
<!ENTITY RFC6976 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6976.xml">
<!ENTITY RFC7490 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7490.xml">
<!ENTITY RFC7916 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7916.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8333 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8333.xml">
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC8660 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml">
<!ENTITY RFC8665 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8665.xml">
<!ENTITY RFC8667 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8667.xml">
<!ENTITY RFC8754 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml">
<!ENTITY RFC8986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml">
<!ENTITY RFC9256 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml">
<!ENTITY I-D.bashandy-rtgwg-segment-routing-uloop SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.bashandy-rtgwg-segment-routing-uloop.xml">
<!ENTITY FLEXALGO SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9350.xml">
]> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-rtgwg-segment-routing-ti-lfa-21" number="9855" 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"?> submissionType="IETF" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" prepTime="2025-10-28T21:59:38" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa-21" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9855" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="SR TI-LFA">Topology Independent Fast Reroute using Using Segment Routing</title>
    <seriesInfo name="RFC" value="9855" stream="IETF"/>
    <author fullname="Ahmed Bashandy" initials="A." surname="Bashandy">
      <organization>Individual</organization>
      <organization showOnFrontPage="true">HPE</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <country/>
          <country>USA</country>
        </postal>
        <email>abashandy.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
      <organization>Cisco
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <city/>
          <country>France</country>
        </postal>
        <email>slitkows@cisco.com</email>
      </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization>Cisco
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <city>Brussels</city>
          <country>Belgium</country>
        </postal>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Pierre Francois" initials="P." surname="Francois">
      <organization>INSA
      <organization showOnFrontPage="true">INSA Lyon</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <country/>
        </postal>
        <email>pierre.francois@insa-lyon.fr</email>
      </address>
    </author>
    <author fullname="Bruno Decraene" initials="B." surname="Decraene">
      <organization>Orange</organization>
      <organization showOnFrontPage="true">Orange</organization>
      <address>
        <postal>
          <street/>

          <city>Issy-les-Moulineaux</city>
          <country>France</country>
        </postal>
        <email>bruno.decraene@orange.com</email>
      </address>
    </author>
    <author fullname="Daniel Voyer" initials="D." surname="Voyer">
      <organization>Bell
      <organization showOnFrontPage="true">Bell Canada</organization>
      <address>
        <postal>
          <street/>

          <city/>
          <country>Canada</country>
        </postal>
        <email>daniel.voyer@bell.ca</email>
      </address>
    </author>

    <abstract>
      <t>This
    <date month="10" year="2025"/>
    <area>RTG</area>
    <workgroup>rtgwg</workgroup>
    <keyword>example</keyword>
    <keyword>TILFA</keyword>
    <keyword>LFA</keyword>
    <keyword>FRR</keyword>
    <keyword>fast reroute</keyword>
    <keyword>recovery</keyword>
    <keyword>SR</keyword>
    <keyword>protection</keyword>
    <keyword>convergence</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document presents Topology Independent Loop-free Loop-Free Alternate
      (TI-LFA) Fast Reroute (TI-LFA), (FRR), which is aimed at providing protection of
      node and adjacency Adjacency segments within the Segment Routing (SR)
      framework. This Fast Reroute
      (FRR) FRR behavior builds on proven IP Fast Reroute FRR concepts being
      LFAs,
      remote Remote LFAs (RLFA), (RLFAs), and remote LFAs with directed forwarding (DLFA). 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
      TI-LFA is the FRR path selection approach establishing protection over
      the expected post-convergence paths from the point Point of local repair, Local Repair
      (PLR), reducing the operational need to control the tie-breaks among
      various FRR options.</t>
    </abstract>
  </front>

  <middle>
    <boilerplate>
      <section anchor="acronyms" title="Acronyms">
      <t><list style="symbols">
          <t>DLFA: Remote LFA 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="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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 Directed forwarding.</t>

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

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

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

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

          <t>PLR: Point
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of Local Repair.</t>

          <t>RL: 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" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="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" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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-abbreviations-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-conventions-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" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base-principle">Base Principle</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intersecting-p-space-and-q-">Intersecting P-space and Q-space with Post-Convergence Paths</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-extended-p-space-property-c">Extended P-space Property Computation for a Resource X over Post-Convergence 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 derivedContent="" format="title" sectionFormat="of" target="name-q-space-property-computatio">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 derivedContent="" 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" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ti-lfa-repair-path">TI-LFA Repair list.</t>

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

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

          <t>SPF: Shortest Path</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-frr-path-using-a-direct-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 derivedContent="" format="title" sectionFormat="of" target="name-frr-path-using-a-pq-node">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 derivedContent="" format="title" sectionFormat="of" target="name-frr-path-using-a-p-node-and">FRR Path First.</t>

          <t>SR: 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 derivedContent="" format="title" sectionFormat="of" target="name-connecting-distant-p-and-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" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-building-ti-lfa-repair-list">Building TI-LFA Repair Lists for SR Segments</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-the-active-segment-is-a-nod">The Active Segment Routing.</t>

          <t>SRLG: Shared Risk Link Group.</t>

          <t>TI-LFA: Topology Independent LFA.</t>

        </list></t> 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 derivedContent="" 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="section-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 derivedContent="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 derivedContent="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" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-mpls-data-plane-considerati">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 derivedContent="" format="title" sectionFormat="of" target="name-srv6-data-plane-considerati">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" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ti-lfa-and-sr-algorithms">TI-LFA and 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" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="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" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-normative-references">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 derivedContent="" format="title" sectionFormat="of" target="name-informative-references">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="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advantages-of-using-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="Appendix 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="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.17">
            <t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction">
      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document outlines a local repair mechanism that leverages Segment
      Routing (SR) to restore end-to-end connectivity in the event of a failure
      involving a directly connected network component.  This mechanism is
      designed for standard link-state Interior Gateway Protocol (IGP) shortest
      path scenarios. Non-SR mechanisms for local repair are beyond the scope
      of this document. Non-local failures are addressed in a separate document
      <xref target="I-D.bashandy-rtgwg-segment-routing-uloop"/>.</t>

      <t>The target="I-D.bashandy-rtgwg-segment-routing-uloop" format="default" sectionFormat="of" derivedContent="SR-LOOP"/>.</t>
      <t indent="0" pn="section-1-2">The term topology independent Topology Independent (TI) describes the capability providing
      a loop free loop-free backup path that is effective accross across all network
      topologies. This provides a major improvement compared to LFA <xref
      target="RFC5286"/> target="RFC5286" format="default" sectionFormat="of" derivedContent="RFC5286"/> and remote LFA RLFA <xref target="RFC7490"/> target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/>, which cannot provide a complete
      protection coverage in some topologies as described in <xref target="RFC6571"/>.</t>

      <t>When target="RFC6571" format="default" sectionFormat="of" derivedContent="RFC6571"/>.</t>
      <t indent="0" pn="section-1-3">When the network reconverges after failure, micro-loops <xref
      target="RFC5715"/> target="RFC5715" format="default" sectionFormat="of" derivedContent="RFC5715"/> can form due to transient
      inconsistencies in the forwarding tables of different routers.  If it is
      determined that micro-loops are a significant issue in the deployment,
      then a suitable loop-free convergence method, method should be implemented, such as one of those
      described in <xref target="RFC5715"/>, <xref target="RFC6976"/>,
      <xref target="RFC8333"/>, target="RFC5715" format="default" sectionFormat="of" derivedContent="RFC5715"/>, <xref target="RFC6976" format="default" sectionFormat="of" derivedContent="RFC6976"/>, <xref target="RFC8333" format="default" sectionFormat="of" derivedContent="RFC8333"/>, or <xref
      target="I-D.bashandy-rtgwg-segment-routing-uloop"/> should be
      implemented.</t>

      <t>TI-LFA target="I-D.bashandy-rtgwg-segment-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 Local Repair (PLR) upon
      detecting a failure in one of its direct links. Consequently, this local
      operation does not influence:
      <list style="symbols">
          <t>Micro-loops
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-5">
        <li pn="section-1-5.1">
          <t indent="0" pn="section-1-5.1.1">Micro-loops that may or may not form during the distributed
          Interior Gateway Protocol (IGP) IGP convergence as delineated in <xref
          target="RFC5715"/>:
          <list style="symbols">
	  <t>These target="RFC5715" format="default" sectionFormat="of" derivedContent="RFC5715"/>:
          </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 TI-LFA-configured paths. paths configured for TI-LFA. According
          to <xref target="RFC5714"/>, target="RFC5714" format="default" sectionFormat="of" derivedContent="RFC5714"/>, the formation of such micro-loops can
          prevent traffic from reaching the PLR, thereby bypassing the TI-LFA
          paths established for rerouting.</t>
	  </list></t>
          <t>Micro-loops
            </li>
          </ul>
        </li>
        <li pn="section-1-5.2">
          <t indent="0" pn="section-1-5.2.1">Micro-loops that may or may not develop when the previously failed
          link is restored to functionality.</t>
        </list></t>

      <t>TI-LFA
        </li>
      </ul>
      <t indent="0" pn="section-1-6">TI-LFA paths are activated from the instant the PLR detects a failure
      in a local link and remain in effect until the Interior Gateway Protocol
      (IGP) IGP convergence at the PLR is fully achieved. Consequently, they are
      not susceptible to micro-loops that may arise due to variations in the
      IGP convergence times across different nodes through which these paths
      traverse. This ensures a stable and predictable routing environment,
      minimizing disruptions typically associated with asynchronous network
      behavior. However, an early (relative to the other nodes) IGP convergence
      at the PLR and the consecutive ”early” "early" release of TI-LFA paths may cause
      micro-loops, especially if these paths have been computed using the
      methods described in Section Sections <xref target="pq_backup"/>, <xref
      target="adj_pq_backup"/>, target="pq_backup" format="counter" sectionFormat="of" derivedContent="5.2"/>, <xref target="adj_pq_backup" format="counter" sectionFormat="of" derivedContent="5.3"/>, or <xref target="remote_pq_backup"/> target="remote_pq_backup" format="counter" sectionFormat="of" derivedContent="5.4"/> of the this
      document. One of the possible ways to prevent such micro-loops is local
      convergence delay (<xref target="RFC8333"/>).</t>

      <t>TI-LFA <xref target="RFC8333" format="default" sectionFormat="of" derivedContent="RFC8333"/>.</t>
      <t indent="0" pn="section-1-7">TI-LFA procedures are complementary to the application of any micro-loop
      avoidance procedures in the case of link or node failure: <list
          style="symbols">
          <t>Link failure:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-8">
        <li pn="section-1-8.1">
          <t indent="0" pn="section-1-8.1.1">Link or node failure requires some urgent action to restore the
          traffic that passed thru through the failed resource. TI-LFA paths are
          pre-computed and pre-installed and therefore pre-installed; therefore, they are suitable for urgent
          recovery</t>
          <t>The
          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 avoidance procedures typically
          cannot be pre-computed.</t>
        </list></t>

      <t>For
        </li>
      </ul>
      <t indent="0" pn="section-1-9">For each destination (as specified by the IGP) in the network, TI-LFA
      pre-installs a backup forwarding entry for each protected destination
      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
      one of the following: single link failure, single node failure, or
      single
      SRLG Shared Risk Link Group (SRLG) failure. In link failure mode, the
      destination is protected assuming the failure of the link. In node
      protection mode, the destination is protected assuming that the neighbor
      connected to the primary link (see <xref target="terminology"/> target="terminology" format="default" sectionFormat="of" derivedContent="Section 2"/>) has failed.  In SRLG protecting mode, the
      destination is protected assuming that a configured set of links sharing
      fate with the primary link has failed (e.g. (e.g., a linecard or a set of links
      sharing a common transmission pipe).</t>

      <t>Protection
      <t indent="0" pn="section-1-10">Protection techniques outlined in this document are limited to
      protecting links, nodes, and SRLGs that are within a link-state IGP
      area. Protecting domain exit routers and/or links attached to another
      routing domains are domain is beyond the scope of this document</t>

      <t>By document.</t>
      <t indent="0" pn="section-1-11">By utilizing Segment Routing (SR), SR, TI-LFA eliminates the need to
      establish Targeted Label Distribution Protocol sessions with
      remote nodes for leveraging the benefits of Remote Loop-Free Alternates
      (RLFA)
      (RLFAs) <xref target="RFC7490"/><xref target="RFC7916"/> target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/> <xref target="RFC7916" format="default" sectionFormat="of" derivedContent="RFC7916"/> or Directed
      Loop-Free Alternates (DLFA) (DLFAs) <xref target="RFC5714"/>. target="I-D.bryant-ipfrr-tunnels" format="default" sectionFormat="of" derivedContent="IPFRR-TUNNELS"/>. All the Segment
      Identifiers (SIDs) required are present within the Link State Database
      (LSDB) of the Interior Gateway Protocol (IGP). IGP. Consequently, there is no
      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>

      <t>Utilizing
      <t indent="0" pn="section-1-12"> Utilizing SR makes also eliminates the requirement unnecessary need to establish an additional
      state within the network for enforcing explicit Fast Reroute (FRR)
      paths.  This spares the nodes from maintaining a supplementary state and
      frees the operator from the necessity to implement additional protocols
      or protocol sessions solely to augment protection coverage.</t>

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

      <t><xref target="terminology"/> related to post-convergence path.</t>
      <t indent="0" pn="section-1-14">This document is structured as follows:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1-15">
        <li pn="section-1-15.1">
          <xref target="terminology" format="default" sectionFormat="of" derivedContent="Section 2"/> defines the main
      notations used in the document. They are in line with <xref target="RFC5714"/>.</t>

      <t><xref target="base"/> target="RFC5714" format="default" sectionFormat="of" derivedContent="RFC5714"/>.</li>
        <li pn="section-1-15.2">
          <xref target="base" format="default" sectionFormat="of" derivedContent="Section 3"/> defines the main principles of
      TI-LFA backup path computation.</t>

      <t><xref target="pq_space_intersect"/> computation.</li>
        <li pn="section-1-15.3">
          <xref target="pq_space_intersect" format="default" sectionFormat="of" derivedContent="Section 4"/> suggests to
      compute the P-Space P-space and Q-Space Q-space properties defined in <xref target="terminology"/>, target="terminology" format="default" sectionFormat="of" derivedContent="Section 2"/> for the specific case of nodes
      lying over the post-convergence paths towards the protected destinations.</t>

      <t>Using the properties defined in <xref target="pq_space_intersect"/>,
      <xref target="tilfa_repair_path"/>
      destinations.</li>
        <li pn="section-1-15.4">
          <xref target="tilfa_repair_path" format="default" sectionFormat="of" derivedContent="Section 5"/> describes how to compute protection lists that encode a
      loop-free post-convergence path towards the
      destination.</t>

      <t><xref target="repairlist"/> destination using the
      properties defined in <xref target="pq_space_intersect" format="default" sectionFormat="of" derivedContent="Section 4"/>.</li>
        <li pn="section-1-15.5">
          <xref target="repairlist" format="default" sectionFormat="of" derivedContent="Section 6"/> defines the segment
      operations to be applied by the PLR to ensure consistency with the
      forwarding state of the repair node.</t>

      <t><xref target="dataplane"/> node.</li>
        <li pn="section-1-15.6">
          <xref target="dataplane" format="default" sectionFormat="of" derivedContent="Section 7"/> discusses aspects that are specific to the
      dataplane.</t>

      <t><xref target="tilfa-sr-algo"/>
      data plane.</li>
        <li pn="section-1-15.7">
          <xref target="tilfa-sr-algo" format="default" sectionFormat="of" derivedContent="Section 8"/> discusses the relationship between TI-LFA
      and the SR-algorithm.</t>

      <t>Certain 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 Adjacency
      segments are used in a
      repare list. <xref target="adj-sid-repair-list"/> provides an overview
      of these considerations.</t>

      <t><xref target="security"/> Repair List (RL).</li>
        <li pn="section-1-15.9">
          <xref target="security" format="default" sectionFormat="of" derivedContent="Section 10"/> discusses security considerations.</t>

      <t><xref target="advantages-post-conv-path"/> considerations.</li>
        <li pn="section-1-15.10">
          <xref target="advantages-post-conv-path" format="default" sectionFormat="of" derivedContent="Appendix A"/> highlights advantages of
      using the expected post-convergence path during FRR.</t>

      <t>By FRR.</li>
        <li pn="section-1-15.11">
          <xref target="analysis" format="default" sectionFormat="of" derivedContent="Appendix B"/> summarizes the measurements from implementing the
algorithms detailed in this document within actual service
provider and large enterprise network environments, real-life environments.  Real-life
measurements are presented regarding the number of SIDs utilized
by repair paths. These measurements are summarized in <xref target="analysis"/>.</t> paths.</li>
      </ul>
    </section>
    <section anchor="terminology" title="Terminology">
      <t>The numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <section anchor="acronyms" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-abbreviations-and-notations">Abbreviations and Notations</name>
        <dl spacing="normal" newline="false" indent="3" pn="section-2.1-1">
          <dt pn="section-2.1-1.1">DLFA:</dt>
          <dd pn="section-2.1-1.2">Directed Loop-Free Alternate</dd>
          <dt pn="section-2.1-1.3">FRR:</dt>
          <dd pn="section-2.1-1.4">Fast Reroute</dd>
          <dt pn="section-2.1-1.5">IGP:</dt>
          <dd pn="section-2.1-1.6">Interior Gateway Protocol</dd>
          <dt pn="section-2.1-1.7">LFA:</dt>
          <dd pn="section-2.1-1.8">Loop-Free Alternate</dd>
          <dt pn="section-2.1-1.9">LSDB:</dt>
          <dd pn="section-2.1-1.10">Link State Database</dd>
          <dt pn="section-2.1-1.11">PLR:</dt>
          <dd pn="section-2.1-1.12">Point of Local Repair</dd>
          <dt pn="section-2.1-1.13">RL:</dt>
          <dd pn="section-2.1-1.14">Repair List</dd>
          <dt pn="section-2.1-1.15">RLFA:</dt>
          <dd pn="section-2.1-1.16">Remote Loop-Free Alternate</dd>
          <dt pn="section-2.1-1.17">SID:</dt>
          <dd pn="section-2.1-1.18">Segment Identifier</dd>
          <dt pn="section-2.1-1.19">SPF:</dt>
          <dd pn="section-2.1-1.20">Shortest Path First</dd>
          <dt pn="section-2.1-1.21">SPT:</dt>
          <dd pn="section-2.1-1.22">Shortest Path Tree</dd>
          <dt pn="section-2.1-1.23">SR:</dt>
          <dd pn="section-2.1-1.24">Segment Routing</dd>
          <dt pn="section-2.1-1.25">SRLG:</dt>
          <dd pn="section-2.1-1.26">Shared Risk Link Group</dd>
          <dt pn="section-2.1-1.27">TI-LFA:</dt>
          <dd pn="section-2.1-1.28">Topology Independent Loop-Free Alternate</dd>
        </dl>
        <t indent="0" pn="section-2.1-2">The main notations used in this document are defined as follows.</t>

      <t>The follows:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-2.1-3">
          <li pn="section-2.1-3.1">The terms "old" and "new" topologies refer to the Link State Database
      (LSDB) LSDB state before
	and after the considered failure, respectively.</t>

      <t>SPT_old(R) respectively.</li>
          <li pn="section-2.1-3.2">SPT_old(R) is the Shortest Path Tree SPT rooted at node R in the initial state of the network.</t>

      <t>SPT_new(R,
	network.</li>
          <li pn="section-2.1-3.3">SPT_new(R, X) is the Shortest Path Tree SPT rooted at node R in the state of the
	network after the resource X has failed.</t>

      <t>PLR stands for "Point of Local Repair". It failed.</li>
          <li pn="section-2.1-3.4">The PLR is the router that applies fast traffic restoration after
	detecting failure in a directly attached link, set of links, and/or node.</t>

      <t>Similar
	node.</li>
          <li pn="section-2.1-3.5">Similar to <xref target="RFC7490"/>, target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/>, the concept of P-Space P-space and
      Q-Space
	Q-space is used for TI-LFA.</t>

      <t>The TI-LFA.</li>
          <li pn="section-2.1-3.6">The P-space P(R,X) P(R, X) of a router R with regard to a resource X (e.g. (e.g., a
	link S-F, a node F, or a 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.</t>

      <t>Consider P-space.</li>
          <li pn="section-2.1-3.7">Consider the set of neighbors of a router R and a resource X. Exclude
	from that set, set the neighbors that are reachable from R using X. The
      Extended P-Space P'(R,X)
	extended P-space P'(R, X) of a node R with regard to a resource X is the
	union of the P-spaces of the neighbors in that reduced set of neighbors
	with regard to the resource X.</t>

      <t>The X.</li>
          <li pn="section-2.1-3.8">The Q-space Q(R,X) Q(R, X) of a router R with regard to a resource X is the
	set of routers from which R can be reached without any path (including
	equal-cost path splits) transiting through X. A Q node is a node that
	belongs to the Q-space </t>

      <t>EP(P, Q-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.</t>

      <t>Primary Interface: Primary Outgoing Interface: One Q.</li>
          <li pn="section-2.1-3.10">The primary interface and primary outgoing interface are one of the outgoing
	interfaces towards a destination according to the IGP link-state
      protocol</t>

      <t>Primary Link: A
	protocol.</li>
          <li pn="section-2.1-3.11">The primary link is a link connected to the primary interface</t>

      <t>adj-sid(S-F): interface.</li>
          <li pn="section-2.1-3.12">The Adj-SID(S-F) is the Adjacency Segment segment from node S to node F</t> F.</li>
        </ul>
      </section>
      <section anchor="conventions" title="Conventions used numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in this document">
        <t>The This Document</name>
        <t indent="0" pn="section-2.2-1">
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP
        14 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="base" title="Base principle">
      <t>The numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-base-principle">Base Principle</name>
      <t indent="0" pn="section-3-1">The basic algorithm to compute the repair path is to pre-compute
      SPT_new(R,X) and
      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
      use adjacency Adjacency SIDs only. However, this approach may create very long SID
      lists that hardware may not be able to handle due to MSD (Maximum Maximum SID
      Depth)
      Depth (MSD) limitations.</t>

      <t>An
      <t indent="0" pn="section-3-2">An implementation is free to use any local optimization to provide
      smaller segment lists by combining Node SIDs Node-SIDs and Adjacency SIDs. In
      addition, the usage of Node-SIDs allow to maximize for maximizing ECMPs over the backup
      path. These optimizations are out of scope of this document, however document; however, the
      subsequent sections provide some guidance on how to leverage P-Spaces P-spaces and
      Q-Spaces
      Q-spaces to optimize the size of the segment list.</t>
    </section>
    <section anchor="pq_space_intersect"
             title="Intersecting P-Space numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-intersecting-p-space-and-q-">Intersecting P-space and Q-Space Q-space with post-convergence paths">
      <t>One Post-Convergence Paths</name>
      <t indent="0" pn="section-4-1">One of the challenges of defining an SR path following the expected
      post-convergence path is to reduce the size of the segment list. In
      order to reduce this segment list, an implementation MAY <bcp14>MAY</bcp14>
      determine the
      P-Space/Extended P-Space P-space / extended P-space and Q-Space Q-space properties (defined
      in <xref
      target="RFC7490"/>) target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/>) of the nodes along the
      expected post-convergence path from the PLR to the protected destination
      and compute an SR explicit path from P to Q when they are not
      adjacent. Such properties will be used in <xref target="tilfa_repair_path"/> target="tilfa_repair_path" format="default" sectionFormat="of" derivedContent="Section 5"/> to compute the TI-LFA
      repair list.</t>
      RL.</t>
      <section anchor="extp_space"
               title="Extended P-Space property computation numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-extended-p-space-property-c">Extended P-space Property Computation for a resource X, Resource X over post-convergence paths">
        <t>The Post-Convergence Paths</name>
        <t indent="0" pn="section-4.1-1">The objective is to determine which nodes on the post-convergence
        path from the PLR R to the destination D are in the extended P-space of
        R with regard to resource X (where X can be a link or a set of links
        adjacent to the PLR, PLR or a neighbor node of the PLR).</t>

        <t>This
        <t indent="0" pn="section-4.1-2">This can be found by: <list style="symbols">
            <t>Excluding by:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-3">
          <li pn="section-4.1-3.1">
            <t indent="0" pn="section-4.1-3.1.1">excluding neighbors which that are not on the post-convergence path
            when computing P'(R,X)</t>

            <t>Then, intersecting 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 belonging to the
            post-convergence path from R to D, assuming the failure of X, with
            P'(R, X).</t>
          </list></t>
          </li>
        </ul>
      </section>
      <section anchor="q_space"
               title="Q-Space property computation numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-q-space-property-computatio">Q-space Property Computation for a resource X, Resource X over post-convergence paths">
        <t>The Post-Convergence Paths</name>
        <t indent="0" pn="section-4.2-1">The goal is to determine which nodes on the post-convergence path
        from the Point of Local Repair (PLR) PLR R to the destination D are in the
        Q-Space
        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
        PLR).</t>

        <t>This
        <t indent="0" pn="section-4.2-2">This can be found by intersecting the set of nodes belonging to the
        post-convergence path from R to D, assuming the failure of X, with
        Q(D, X).</t>
      </section>
      <section anchor="q_space_scaling"
               title="Scaling considerations when computing Q-Space">
        <t><xref target="RFC7490"/> numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-scaling-considerations-when">Scaling Considerations When Computing Q-space</name>
        <t indent="0" pn="section-4.3-1"><xref target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/> raises scaling concerns about computing a
        Q-Space
        Q-space per destination. Similar concerns may affect TI-LFA
        computation if an implementation tries to compute a reverse Shortest
        Path Tree (<xref target="RFC7490"/>) (SPT) <xref target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/> for every destination in the
        network to determine the Q-Space. Q-space. It will be up to each implementation
        to determine the good tradeoff between scaling and accuracy of the
        optimization.</t>
      </section>
    </section>
    <section anchor="tilfa_repair_path" title="TI-LFA numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-ti-lfa-repair-path">TI-LFA Repair path">
      <t>The Path</name>
      <t indent="0" pn="section-5-1">The TI-LFA repair path consists of an outgoing interface and a list
      of segments (repair list (a Repair List (RL)) to insert on the SR header in
      accordance with the dataplane data plane used.  The repair list RL encodes the explicit,
      and
      explicit (and possibly post-convergence, post-convergence) path to the destination, which
      avoids the protected resource X and, at X. At the same time, the RL is
      guaranteed to be loop-free loop-free, irrespective of the state of FIBs along the
      nodes belonging to the explicit path path, as long as the states of the FIBs
      are programmed according to a link-state IGP.  Thus, there is no need
      for any co-ordination coordination or message exchange between the PLR and any other
      router in the network.</t>

      <t>The
      <t indent="0" pn="section-5-2">The TI-LFA repair path is found by intersecting P(S,X) P(S, X) and Q(D,X) Q(D, X) with
      the post-convergence path to D and computing the explicit SR- based SR-based path
      EP(P, Q) from a node P in P(S,X) P(S, X) to a node Q in Q(D,X) Q(D, X) when these nodes
      are not adjacent along the post convergence post-convergence path. The TI-LFA repair list RL
      is expressed generally as (Node-SID(P), EP(P, Q)).</t>
      <figure anchor="sample-topo1" title="Sample topology align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-sample-topology-with-ti-lfa">Sample Topology with TI-LFA">
        <artwork> TI-LFA</name>
        <artwork name="" type="" align="left" alt="" pn="section-5-3.1">
  S ------- --------- N1 ----------- --------- D
  *\          | \          |
  * \         |  \         |
  *  \        |   \        |
  *   N2-----R1****R2   N2----- R1***R2 *** R3
  *           *
  N3 ********* **********

    ***** : link with high metric (1k)
    ----- : link with metric 1
</artwork>
      </figure>

      <t>As
      <t indent="0" pn="section-5-4">As an example, in <xref target="sample-topo1"/>, target="sample-topo1" 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>

      <t><list style="symbols">
          <t>First,
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-5">
        <li pn="section-5-5.1">
          <t indent="0" pn="section-5-5.1.1">First, P(S, N1) is computed and results in [N3, N2, R1].</t>

          <t>Then,
        </li>
        <li pn="section-5-5.2">
          <t indent="0" pn="section-5-5.2.1">Then, Q(D, N1) is computed and results in [R3].</t>

          <t>The
        </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
          are naming it PCPath "PCPath" in this example).</t>

          <t>P(S,
        </li>
        <li pn="section-5-5.4">
          <t indent="0" pn="section-5-5.4.1">P(S, N1) intersection with PCPath is [N2, R1], 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 example, and an implementation could use a different
          strategy to choose the P node).</t>

          <t>Q(D,
        </li>
        <li pn="section-5-5.5">
          <t indent="0" pn="section-5-5.5.1">Q(D, N1) intersection with PCPath is [R3], so R3 is picked as a Q
          node. An SR explicit SR-explicit path is then computed from R1 (P node) to R3 (Q
          node) following PCPath (R1 -&gt; R2 -&gt; R3): &lt;Adj-Sid(R1-R2),
          Adj-Sid(R2-R3)&gt;.</t>
        </list> &lt;Adj-SID(R1-R2),
          Adj-SID(R2-R3)&gt;.</t>
        </li>
      </ul>
      <t indent="0" pn="section-5-6"> As a result, the TI-LFA repair list RL of S for destination D
      considering the failure of node N1 is: &lt;Node-SID(R1), Adj-Sid(R1-R2),
      Adj-Sid(R20R3)&gt;.</t>

      <t>Most Adj-SID(R1-R2),
      Adj-SID(R2-R3)&gt;.</t>
      <t indent="0" pn="section-5-7">Most often, the TI-LFA repair list RL has a simpler form, as described
      in the following sections. <xref target="analysis"/> target="analysis" format="default" sectionFormat="of" derivedContent="Appendix B"/> provides statistics
      for the number of SIDs in the explicit path to protect against various
      failures.</t>
      <section anchor="direct_backup" title="FRR path using numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-frr-path-using-a-direct-nei">FRR Path Using a direct neighbor">
        <t>When Direct Neighbor</name>
        <t indent="0" pn="section-5.1-1">When a direct neighbor is in P(S,X) P(S, X) and Q(D,x) Q(D, x), and the link to that
        direct neighbor is on the post-convergence path, the outgoing interface
        is set to that neighbor and the repair segment list is empty.</t>

        <t>This
        <t indent="0" pn="section-5.1-2">This is comparable to a post-convergence LFA FRR repair.</t>
      </section>
      <section anchor="pq_backup" title="FRR path using numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-frr-path-using-a-pq-node">FRR Path Using a PQ node">
        <t>When Node</name>
        <t indent="0" pn="section-5.2-1">When a remote node R is in P(S,X) P(S, X) and Q(D,x) Q(D, x) and on the
        post-convergence path, the repair list RL is made of a single node segment
        to R R, and the outgoing interface is set to the outgoing interface used
        to reach R.</t>

        <t>This
        <t indent="0" pn="section-5.2-2">This is comparable to a post-convergence RLFA repair tunnel.</t>
      </section>
      <section anchor="adj_pq_backup"
               title="FRR path using numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-frr-path-using-a-p-node-and">FRR Path Using a P node Node and Q node that are adjacent">
        <t>When Node That Are Adjacent</name>
        <t indent="0" pn="section-5.3-1">When a node P is in P(S,X) P(S, X) and a node Q is in Q(D,x) Q(D, x), and both are on
        the post-convergence path and both are adjacent to each other, the
        repair list
        RL is made of two segments: A a node segment to P (to be
        processed first), followed by an adjacency Adjacency segment from P to Q.</t>

        <t>This
        <t indent="0" pn="section-5.3-2">This is comparable to a post-convergence DLFA (LFA with directed
        forwarding) Directed Loop-Free
        Alternate (DLFA) repair tunnel.</t>
      </section>
      <section anchor="remote_pq_backup"
               title="Connecting distant numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-connecting-distant-p-and-q-">Connecting Distant P and Q nodes along post-convergence paths">
        <t>In Nodes Along Post-Convergence Paths</name>
        <t indent="0" pn="section-5.4-1">In some cases, there is no adjacent P and Q node along the post-
        convergence
        post‑convergence path. As mentioned in <xref target="base"/>, target="base" format="default" sectionFormat="of" derivedContent="Section 3"/>, a list of
        adjacency Adjacency SIDs can be used to encode the
        path between P and Q. However, the PLR can perform additional
        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 anchor="repairlist" title="Building numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-building-ti-lfa-repair-list">Building TI-LFA repair lists Repair Lists for SR Segments">
      <t>The Segments</name>
      <t indent="0" pn="section-6-1">The following sections describe how to build the repair lists RLs using
      the terminology defined in <xref target="RFC8402"/>. target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>. The procedures
      described in this section are equally applicable to both SR-MPLS the Segment Routing over MPLS (SR-MPLS) and
      SRv6 dataplane,
      the Segment Routing over IPv6 (SRv6) data plane, while the dataplane-specific data plane-specific considerations are
      described in <xref target="dataplane"/>.</t>

      <t>In this section, 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
      interface for the packet, S-F, is explained. packet S-F. The failure of the primary
      outgoing interface may occur due to various triggers, such as link
      failure, neighbor node failure, and others.</t>
      <section anchor="link-protect-node-sid"
               title="The active segment is numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-the-active-segment-is-a-nod">The Active Segment Is a node segment">
        <t>The Node Segment</name>
        <t indent="0" pn="section-6.1-1">The active segment MUST <bcp14>MUST</bcp14> be kept on the SR header unchanged and the
        repair list MUST
        RL <bcp14>MUST</bcp14> be added. The active segment becomes the first
        segment after the repair list. RL. The way the repair list RL is added depends
        on the dataplane data plane used (see <xref target="dataplane"/>).</t> target="dataplane" format="default" sectionFormat="of" derivedContent="Section 7"/>).</t>
      </section>
      <section anchor="link-protect-adj-sid"
               title="The active segment is numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-the-active-segment-is-an-ad">The Active Segment Is an adjacency segment">
        <t>The Adjacency Segment</name>
        <t indent="0" pn="section-6.2-1">This section defines the FRR behavior applied by S for any packet
        received with an active adjacency Adjacency segment S-F, S-F for which protection was enabled, is
        defined here.
        enabled. Since protection has been enabled for the segment S-F and
        signaled in the IGP (for instance, using protocol extensions from
        <xref
        target="RFC8667"/> target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/> and <xref target="RFC8665"/>), target="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/>), a calculator of any SR policy utilizing this
        segment is aware that it may be transiently rerouted out of S-F in the
        event of an S-F failure.</t>

        <t>The
        <t indent="0" pn="section-6.2-2">The simplest approach for link protection of an adjacency Adjacency segment
        S-F is to create a repair list an RL that will carry the traffic to F. To do
        so, one or more “PUSH” "PUSH" operations are performed. If the repair list, RL,
        while avoiding S-F, terminates on F, S only pushes segments of the
        repair list.
        RL. Otherwise, S pushes a node segment of F, followed by the
        segments of the repair list. RL. For details on the "NEXT" and "PUSH"
        operations, refer to <xref target="RFC8402"/>.</t>

        <t>This target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</t>
        <t indent="0" pn="section-6.2-3">This method, which merges back the traffic at the remote end of the
        adjacency
        Adjacency segment, has the advantage of keeping as much traffic as
        possible the
        traffic on the pre-failure path.  When SR policies are involved and
        strict compliance with the policy is required, an end-to-end
        protection (beyond the scope of this document) should be preferred
        over the local repair mechanism described above.</t>

        <t>
        <t indent="0" pn="section-6.2-4"> Note, however, that when the SR source node is using traffic
        engineering 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
        detects the failure, since computation of the TE path is a local matter
        that depends on constraints that may not be known at the
        PLR. Therefore, no method applied at the PLR can guarantee protection
        will follow the post-convergence path.</t>

        <t>The
        <t indent="0" pn="section-6.2-5">The case where the active segment is followed by another adjacency Adjacency
        segment is distinguished from the case where it is followed by a node
        segment. Repair techniques for the respective cases are provided in the
        following subsections.</t>
        <section anchor="link-protect-adj-sid-adj-sid"
                 title="Protecting numbered="true" toc="include" removeInRFC="false" pn="section-6.2.1">
          <name slugifiedName="name-protecting-adjacency-adjace">Protecting [Adjacency, Adjacency] segment lists">
          <t>If 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>

          <t>To
          <t indent="0" pn="section-6.2.1-2">To do so, S MUST <bcp14>MUST</bcp14> apply a "NEXT" operation on Adj-Sid(S-F) Adj-SID(S-F) and then
          one or more “PUSH” "PUSH" operations. If the repair list, RL, while avoiding
          S-F, terminates on F, S only pushes the segments of the repair list. RL.
          Otherwise, S pushes a node segment of F, followed by the segments of
          the repair list. RL. For details on the "NEXT" and "PUSH" operations,
          refer to <xref target="RFC8402"/>.</t>

          <t>Upon target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</t>
          <t indent="0" pn="section-6.2.1-3">Upon failure of S-F, a packet reaching S with a segment list
          matching [adj-sid(S-F),adj-sid(F-M),...] [adj-sid(S-F), adj-sid(F-M), ...] will thus leave S with a segment
          list matching [RL(F),node(F),adj-sid(F-M),...], [RL(F), node(F), adj-sid(F-M), ...], where RL(F) is the
          repair list
          RL for destination F.</t>
        </section>
        <section anchor="link-protect-adj-sid-node-sid"
                 title="Protecting numbered="true" toc="include" removeInRFC="false" pn="section-6.2.2">
          <name slugifiedName="name-protecting-adjacency-node-s">Protecting [Adjacency, Node] segment lists">
          <t>If Segment Lists</name>
          <t indent="0" pn="section-6.2.2-1">If the next segment in the stack is a node segment, say for node
          T, the segment list on the packet matches
          [adj-sid(S-F),node(T),...].</t>

          <t>In [adj-sid(S-F), node(T), ...].</t>
          <t indent="0" pn="section-6.2.2-2">In this case, S MUST <bcp14>MUST</bcp14> apply a "NEXT" operation on the Adjacency
          segment related to S-F, followed by a "PUSH" of a repair list an RL
          redirecting the traffic to a node Q, whose path to node segment T is
          not affected by the failure.</t>

          <t>Upon
          <t indent="0" pn="section-6.2.2-3">Upon failure of S-F, packets reaching S with a segment list
          matching [adj-sid(S-F), node(T), ...], ...] would leave S with a segment list
          matching [RL(Q),node(T), [RL(Q), node(T), ...].</t>
        </section>
      </section>
    </section>
    <section anchor="dataplane" title="Dataplane specific considerations"> numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-data-plane-specific-conside">Data Plane-Specific Considerations</name>
      <section anchor="mpls-dataplane" title="MPLS dataplane considerations">
        <t>MPLS dataplane numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-mpls-data-plane-considerati">MPLS Data Plane Considerations</name>
        <t indent="0" pn="section-7.1-1">The MPLS data plane for Segment Routing SR is described in <xref
        target="RFC8660"/>.</t>

        <t>The target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>.</t>
        <t indent="0" pn="section-7.1-2">The following dataplane data plane behaviors apply when creating a repair list an RL
        using an MPLS dataplane: <list style="numbers">
            <t>If data plane:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.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 popping, and the repair list RL ends with an
            adjacency
            Adjacency segment terminating on a the penultimate node that advertised NEXT
            operation <xref target="RFC8402"/> of the
            active segment, then the active segment MUST <bcp14>MUST</bcp14> be
            popped before pushing the repair list.</t>

            <t>If 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 segment, but the other conditions
            in 1. are not met, the active segment MUST <bcp14>MUST</bcp14> be popped and then pushed
            again with a label value computed according to the Segment Routing
            Global Block (SRGB) of Q, where Q is the endpoint of the repair
            list. RL. Finally, the repair list MUST RL <bcp14>MUST</bcp14> be pushed.</t>
          </list></t>
          </li>
        </ol>
      </section>
      <section anchor="srv6-dataplane" title="SRv6 dataplane considerations">
        <t>SRv6 dataplane numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-srv6-data-plane-considerati">SRv6 Data Plane Considerations</name>
        <t indent="0" pn="section-7.2-1">SRv6 data plane and programming instructions are described
        respectively in <xref target="RFC8754"/> target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/> and <xref
        target="RFC8986"/>.</t>

        <t>The target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>.</t>
        <t indent="0" pn="section-7.2-2">The TI-LFA path computation algorithm is the same as in the SR-MPLS
        dataplane. Note however
        data plane. Note, however, that the Adjacency SIDs are typically globally
        routed. In such a case, there is no need for preceding an adjacency Adjacency SID
        with a Prefix-SID <xref target="RFC8402"/> target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>, and the resulting repair
        list RL is likely shorter.</t>

        <t>If
        <t indent="0" pn="section-7.2-3">If the traffic is protected at a Transit Node, then an SRv6 SID
        list is added on the packet to apply the repair list. RL. The addition of
        the repair list RL follows the headend head-end behaviors as specified in section
        5 of
        <xref target="RFC8986"/>.</t>

        <t>If target="RFC8986" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8986#section-5" derivedContent="RFC8986"/>.</t>
        <t indent="0" pn="section-7.2-4">If the traffic is protected at an SR Segment Endpoint Node, first
        the Segment Endpoint packet processing is executed. Then Then, the packet is
        protected as if its it were a transit packet.</t>
      </section>
    </section>
    <section anchor="tilfa-sr-algo" title="TI-LFA numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-ti-lfa-and-sr-algorithms">TI-LFA and SR algorithms">
      <t>SR Algorithms</name>
      <t indent="0" pn="section-8-1">SR allows an operator to bind an algorithm to a prefix-SID Prefix-SID (as
      defined in <xref target="RFC8402"/>. target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>). The algorithm value dictates how
      the path to the prefix is computed. The SR default algorithm is known
      has
      as the "Shortest Path" algorithm. The SR default algorithm allows an
      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
      guarantee that the path will be loop-free loop-free, as a local policy may have
      overriden
      overridden the expected IGP path. As the local policies are defined by
      the operator, it becomes the responsibility of this operator to ensure
      that the deployed policies do not affect the TI-LFA deployment. It
      should be noted that such a situation can already happen today with
      existing mechanisms such as remote LFA.</t>

      <t><xref target="RFC9350"/> RLFA.</t>
      <t indent="0" pn="section-8-2"><xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/> defines a flexible algorithm (FlexAlgo) Flexible Algorithm
      framework to be associated with Prefix-SIDs. FlexAlgo A Flexible Algorithm allows a user to
      associate a constrained path to a Prefix-SID rather than using the
      regular IGP shortest path. An implementation MAY <bcp14>MAY</bcp14> support TI-LFA to
      protect Node-SIDs associated with a Flex Algo. Flexible Algorithm. In such a case, rather
      than computing the expected post-convergence path based on the regular
      SPF, an implementation SHOULD <bcp14>SHOULD</bcp14> use the constrained SPF algorithm bound to
      the Flex Algo Flexible Algorithm (using the Flex Algo Flexible Algorithm Definition) instead of the regular
      Dijkstra in all the SPF/rSPF SPF/reverse SPF computations that are occurring during the
      TI-LFA computation. This includes the computation of the P-Space P-space and
      Q-Space
      Q-space as well as the post-convergence path. Furthermore, the
      implementation SHOULD <bcp14>SHOULD</bcp14> only use Node-SIDs/Adj-SIDs bound to the Flex Algo Flexible Algorithm
      and/or unprotected Adj-SIDs of the regular SPF to build the repair
      list. RL. The use of regular Dijkstra for the TI-LFA computation or for building
      of
      the repair path using SIDs other than those recommended does not
      ensure that the traffic going over the TI-LFA repair path during the
      fast-reroute
      FRR period is honoring the Flex Algo Flexible Algorithm constraints.</t>
    </section>
    <section anchor="adj-sid-repair-list"
             title="Usage numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-usage-of-adjacency-segments">Usage of Adjacency segments Segments in the repair list">
      <t>The repair list Repair List</name>
      <t indent="0" pn="section-9-1">The RL of segments computed by TI-LFA may contain one or
      more adjacency Adjacency segments. An adjacency Adjacency segment may be protected or not
      protected.</t>
      <figure anchor="cascaded-frr">
        <artwork> anchor="cascaded-frr" align="left" suppress-title="false" pn="figure-2">
        <artwork name="" type="" align="left" alt="" pn="section-9-2.1">
	S --- R2 --- R3 ---- R4 --- R5 --- D
	         *   |  \   *
                   * |   \ *
	            R7 ** R8
	             *    |
                     *    |
	            R9 -- R10
</artwork>
      </figure>

      <t>In <xref target="cascaded-frr"/>,
      <t indent="0" pn="section-9-3">In <xref target="cascaded-frr" format="default" sectionFormat="of" derivedContent="Figure 2"/>, all the metrics
      are equal to 1 except R2-R7,R7-R8,R8-R4,R7-R9 R2-R7,R7-R8,R8-R4,R7-R9, which have a metric of
      1000. Considering R2 as a PLR to protect against the failure of node R3
      for the traffic S-&gt;D, the repair list RL computed by R2 will be
      [adj-sid(R7-R8),adj-sid(R8-R4)]
      [adj-sid(R7-R8), adj-sid(R8-R4)], and the outgoing interface will be to
      R7. If R3 fails, R2 pushes the repair list RL onto the incoming packet to
      D. During the FRR, if R7-R8 fails and if TI-LFA has picked a protected
      adjacency
      Adjacency segment for adj-sid(R7-R8), Adj-SID(R7-R8), R7 will push an additional repair
      list RL onto the packet following the procedures defined in <xref
      target="repairlist"/>.</t>

      <t>To target="repairlist" format="default" sectionFormat="of" derivedContent="Section 6"/>.</t>
      <t indent="0" pn="section-9-4">To avoid the possibility of this double FRR activation, an
      implementation of TI-LFA MAY <bcp14>MAY</bcp14> pick only non protected adjacency unprotected
      Adjacency segments when building the repair list. RL. However, this it is
      important to note that FRR in general is intended to protect for a
      single pre-planned failure.  If the failure that happens is worse than
      expected or multiple failures happen, FRR is not guaranteed to work. In
      such a case, fast IGP convergence remains important to restore traffic
      as quickly as possible.</t>
    </section>
    <section anchor="security" title="Security Considerations">
      <t>The numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <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
      restore traffic flow upon the failure of a directly connected link or
      node. As these techniques steer traffic to the post-convergence path as
      quickly as possible, this serves to minimize the disruption associated
      with a local failure failure, which can be seen as a modest security
      enhancement. The protection mechanisms mechanism does not protect external
      destinations, but rather provides quick restoration for destination destinations that
      are internal to a routing domain.</t>

      <t>Security
      <t indent="0" pn="section-10-2">The security considerations described in <xref target="RFC5286"/> target="RFC5286" format="default" sectionFormat="of" derivedContent="RFC5286"/> and
      <xref target="RFC7490"/> target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/> apply to this document. Similarly, as the
      solution described in the this document is based on Segment Routing SR
      technology, the reader should be aware of the security considerations
      related to this technology (<xref target="RFC8402"/>) (see <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>) and its dataplane data plane
      instantiations (<xref target="RFC8660"/>, (see <xref target="RFC8754"/> target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>, <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/>, and
      <xref target="RFC8986"/>). target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>). However, this document does not introduce
      additional security concern.</t> concerns.</t>
    </section>
    <section anchor="iana" title="IANA Considerations">
      <t>No numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-11-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.bashandy-rtgwg-segment-routing-uloop" to="SR-LOOP"/>
    <displayreference target="I-D.bryant-ipfrr-tunnels" to="IPFRR-TUNNELS"/>
    <references pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for IANA</t>
    </section>

    <section anchor="contributors" title="Contributors">
      <t>In addition the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC7916" target="https://www.rfc-editor.org/info/rfc7916" quoteTitle="true" derivedAnchor="RFC7916">
          <front>
            <title>Operational Management of Loop-Free Alternates</title>
            <author fullname="S. Litkowski" initials="S." role="editor" surname="Litkowski"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Raza" initials="K." surname="Raza"/>
            <author fullname="M. Horneffer" initials="M." surname="Horneffer"/>
            <author fullname="P. Sarkar" initials="P." surname="Sarkar"/>
            <date month="July" year="2016"/>
            <abstract>
              <t indent="0">Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, 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 solutions.</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/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <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 authors listed ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</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/rfc8402" 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="Previdi"/>
            <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 paradigm. 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 domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the 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. An ordered list of segments is encoded as a stack of labels. The segment to process is on the front page, top of the following
      co-authors stack. Upon completion of a segment, the related label is popped from the stack.</t>
              <t indent="0">SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660" 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 paradigm. 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, the SR header is instantiated through a label stack. This document specifies the forwarding 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/rfc8754" 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="Dukes"/>
            <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 plane 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 Segment 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/rfc8986" 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 Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t indent="0">Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t indent="0">This document defines the SRv6 Network Programming concept 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" derivedAnchor="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 that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, 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-bryant-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. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been 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/rfc5286" 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="Atlas"/>
            <author fullname="A. Zinin" initials="A." role="editor" surname="Zinin"/>
            <date month="September" year="2008"/>
            <abstract>
              <t indent="0">This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5286"/>
          <seriesInfo name="DOI" value="10.17487/RFC5286"/>
        </reference>
        <reference anchor="RFC5714" target="https://www.rfc-editor.org/info/rfc5714" 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 development 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/rfc5715" 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 occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.</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 whether micro-looping is an issue that needs to be addressed in specific networks. It also contributed 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 undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational 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/rfc6571" 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: <list style="symbol">
          <t>Francois Clad, Cisco Systems</t>

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

    <section anchor="ack" title="Acknowledgments">
      <t>The authors document, we analyze the applicability of the 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 node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network. This document is not an Internet Standards Track specification; it is published for 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/rfc6976" quoteTitle="true" derivedAnchor="RFC6976">
          <front>
            <title>Framework for Loop-Free Convergence Using the Ordered Forwarding 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 prevents the transient loops that would like otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on 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 possible where a complete repair path is provided for all affected destinations.</t>
              <t indent="0">After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described.</t>
              <t indent="0">The technology described in this document has been subject to thank Les Ginsberg, Stewart Bryant, Alexander
      Vainsthein, Chris Bowers, Shraddha Hedge, Wes Hardaker, Gunter Van de
      Velde extensive simulation using pathological convergence behavior and John Scudder real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol 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/rfc7490" 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 their valuable comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      &RFC7916;

      &RFC8174;

      &RFC8402;

      &RFC8660;

      &RFC8754;

      &RFC8986; point-to-point link failures when none can be provided by the basic 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/rfc8333" quoteTitle="true" derivedAnchor="RFC8333">
          <front>
            <title>Micro-loop Prevention by Introducing a Local Convergence Delay</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 routing protocols that prevents local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence.</t>
              <t indent="0">Because this mechanism delays the IGP convergence, it may only be used for planned maintenance or when Fast Reroute (FRR) protects the 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 order 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 total 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/rfc8665" quoteTitle="true" derivedAnchor="RFC8665">
          <front>
            <title>OSPF Extensions for Segment Routing</title>
            <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <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 topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</t>
              <t indent="0">This document describes the OSPFv2 extensions required 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/rfc8667" quoteTitle="true" derivedAnchor="RFC8667">
          <front>
            <title>IS-IS Extensions for Segment Routing</title>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <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 definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</t>
              <t indent="0">This document describes the IS-IS extensions that need 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/rfc9256" 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 source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent 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 an 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 concepts 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/rfc9350" quoteTitle="true" derivedAnchor="RFC9350">
          <front>
            <title>IGP Flexible Algorithm</title>
            <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
            <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 over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies 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="https://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="Litkowski">
              <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 providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence 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 title="Informative References">
      <?rfc include="reference.RFC.5714" ?>

      <?rfc include="reference.RFC.5715" ?>

      <?rfc include="reference.RFC.5286" ?>

      <?rfc include="reference.RFC.6976" ?>

      <?rfc include="reference.RFC.7490" ?>

      <?rfc include="reference.RFC.8333" ?>

      <?rfc include="reference.I-D.bashandy-rtgwg-segment-routing-uloop"?>

      &FLEXALGO;

      &RFC9256;

      &RFC6571;

      &RFC8665;

      &RFC8667;
    </references>
    <section anchor="advantages-post-conv-path"
             title="Advantages numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-advantages-of-using-the-exp">Advantages of using Using the expected post-convergence path during FRR">
      <t><xref target="RFC7916"/> raised Expected Post-Convergence Path During FRR</name>
      <t indent="0" pn="section-appendix.a-1"><xref target="RFC7916" format="default" sectionFormat="of" derivedContent="RFC7916"/> raises several operational considerations
      when using LFA or remote LFA. RLFA. <xref target="RFC7916"/> Section 3 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
      protected through a PE Provider Edge (PE) router connected with low bandwidth links. In
      such a case, congestion may happen when the FRR backup path is
      activated. <xref target="RFC7916"/> target="RFC7916" format="default" sectionFormat="of" derivedContent="RFC7916"/> introduces a local policy framework
      to let the operator tuning manually the best alternate election based on
      its own requirements.</t>

      <t>From
      <t indent="0" pn="section-appendix.a-2">From a network capacity planning point of view, it is often assumed
      for simplicity that if a link L fails on a particular node X, the
      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
      considering that the link L has failed (we assume that the traffic uses
      the post-convergence path starting from the node X). In <xref
      target="figure1"/>, target="figure1" format="default" sectionFormat="of" derivedContent="Figure 3"/>, we consider a network with all
      metrics equal to 1 except the metrics on links used by PE1, PE2 PE2, and PE3 PE3,
      which are 1000. An easy network capacity planning method is to consider
      that if the link L (X-B) fails, the traffic actually flowing through L
      will be spread over the remaining links of X (X-H, X-D,
      X-A). Considering the IGP metrics, only X-H and X-D can be used in
      reality to carry the traffic flowing through the link L. As a
      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, however works;
      however, it is not fully accurate.</t>

      <t>In <xref target="figure1"/>,
      <t indent="0" pn="section-appendix.a-3">In <xref target="figure1" format="default" sectionFormat="of" derivedContent="Figure 3"/>, considering that the source of traffic
      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
      the remote PEs onto X-H or X-D; however however, in a similar timeframe, PE1 will
      also reroute a subset of its traffic (the subset destined to PE2) out of
      its nominal path path, reducing the quantity of traffic received by X. The
      capacity planning rule presented previously has the drawback of
      oversizing the network, however network; however, it allows to prevent for preventing any transient
      congestion (when for example (for example, when X reroutes traffic before PE1 does).</t>
      <figure anchor="figure1">
        <artwork> anchor="figure1" align="left" suppress-title="false" pn="figure-3">
        <artwork name="" type="" align="left" alt="" pn="section-appendix.a-4.1">
              H --- I --- J *
              |           | \  *
   PE4        |           |   PE3
      \       | (L)       | /  *
      * A --- X --- B --- G
    / *
     *        |           | \  *
   PE1        |           |   PE2
    \
     *        |           | /  *
      * C --- D --- E --- F *
</artwork>
      </figure>

      <t>Based
      <t indent="0" pn="section-appendix.a-5">Based on this assumption, in order to facilitate the operation of
      FRR,
      FRR and limit the implementation of local FRR policies, traffic can be
      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
      destined to PE3 and PE2 on the post-convergence paths. This is perfectly
      inline
      in line with the capacity planning rule that was presented before and
      also inline 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
      post-convergence paths rooted at X.</t>

      <t>It
      <t indent="0" pn="section-appendix.a-6">It should be noted, noted that some networks may have a different capacity
      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
      during FRR may introduce some congestion on X-H and X-D links. However However,
      it is important to note, note that a transient congestion may possibly
      happen,
      happen even without FRR activated, for instance instance, when X converges before
      the upstream routers. Operators are still free to use the policy
      framework defined in <xref target="RFC7916"/> target="RFC7916" format="default" sectionFormat="of" derivedContent="RFC7916"/> if the usage of the
      post-convergence paths rooted at the PLR is not suitable.</t>

      <t>Readers
      <t indent="0" pn="section-appendix.a-7">Readers should be aware that FRR protection is pre-computing a backup
      path to protect against a particular type of failure (link, node, or SRLG).
      When using the post-convergence path as an FRR backup path, the computed
      post-convergence path is the one considering the failure we are
      protecting against. This means that FRR is using an expected
      post-convergence path, and this expected post-convergence path may be
      actually different from the post-convergence path used if the failure
      that happened is different from the failure FRR was protecting against.
      As an example, if the operator has implemented a protection against a
      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
      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
      is that the path used during FRR is not optimal with respect to the
      failure that has actually occurred.</t>

      <t>Another
      <t indent="0" pn="section-appendix.a-8">Another consideration to take into account is: is as follows: while using
      the expected post-convergence path for SR traffic using node segments
      only (for instance, PE to PE traffic using the shortest path) has some
      advantages, these advantages reduce when SR policies (<xref
      target="RFC9256"/>) <xref target="RFC9256" format="default" sectionFormat="of" derivedContent="RFC9256"/> are involved. A segment-list segment list used in
      an SR policy is computed to obey a set of path constraints defined
      locally at the head-end or centrally in a controller. TI-LFA cannot be
      aware of such path constraints constraints, and there is no reason to expect the
      TI-LFA backup path protecting one segments segment in that segment list to obey
      those constraints.  When SR policies are used and the operator wants to
      have a backup path
      which that still follows the policy requirements, this
      backup path should be computed as part of the SR policy in the ingress
      node (or central
      controller) controller), and the SR policy should not rely on local
      protection.  Another option could be to use FlexAlgo (<xref target="RFC9350"/>) a Flexible Algorithm <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/> to express the set of constraints
      and use a single node segment associated with a FlexAlgo Flexible Algorithm to reach the
      destination. When using a node segment associated with a FlexAlgo, Flexible Algorithm,
      TI-LFA keeps providing an optimal backup by applying the appropriate set
      of constraints. The relationship between TI-LFA and the SR-algorithm SR algorithm is
      detailed in <xref
      target="tilfa-sr-algo"/>.</t> target="tilfa-sr-algo" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
    </section>
    <section anchor="analysis"
             title="Analysis based numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-analysis-based-on-real-netw">Analysis Based on real network topologies">
      <t>This Real 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
      assess the number of SIDs required in an explicit path when the
      mechanisms described in this document are used to protect against the
      failure scenarios within the scope of this document. The number of
      segments described in this section are applicable to instantiating
      segment routing
      SR over the MPLS forwarding plane.</t>

      <t>The
      <t indent="0" pn="section-appendix.b-2">The measurement below indicate that indicates that, for link and local SRLG
      protection, a 1 SID repair path of 1 SID or less delivers more than 99% coverage. For
      node protection protection, a 2 SIDs repair path of 2 SIDs or less yields 99% coverage.</t>

      <t>Table 1
      <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
      "bidirectional" links (not directed edges of the graph). The
      measurements are carried out as follows:</t>

      <t><list style="symbols">
          <t>For
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.b-4">
        <li pn="section-appendix.b-4.1">
          <t indent="0" pn="section-appendix.b-4.1.1">For each network, the algorithms described in this document are
          applied to protect all prefixes against link, node, and local SRLG
          failure</t>

          <t>For
          failure.</t>
        </li>
        <li pn="section-appendix.b-4.2">
          <t indent="0" pn="section-appendix.b-4.2.1">For each prefix, the number of SIDs used by the repair path is
          recorded</t>

          <t>The
          recorded.</t>
        </li>
        <li pn="section-appendix.b-4.3">
          <t indent="0" pn="section-appendix.b-4.3.1">The percentage of number of SIDs are listed in Tables 2A/B, 3A/B,
          and 4A/B</t>
        </list></t>

      <t>The measurements listed in the tables indicate that for link and
      local SRLG protection, 1 SID repair path is sufficient to protect more
      than 99% of the prefix in almost all cases. For node protection 2 SIDs
      repair paths yield 99% coverage.</t>

      <figure>
        <artwork>
+-------------+------------+------------+------------+------------+
|   Network   |    Nodes   |  Links     |Node-to-Link| SRLG info? |
|             |            |            |    Ratio   |            |
+-------------+------------+------------+------------+------------+
|    T1       |    408     |      665   |    1.63    |    Yes     |
+-------------+------------+------------+------------+------------+
|    T2       |    587     |     1083   |    1.84    |     No     |
+-------------+------------+------------+------------+------------+
|    T3       |    93      |      401   |    4.31    |    Yes     |
+-------------+------------+------------+------------+------------+
|    T4       |    247     |      393   |    1.59    |    Yes     |
+-------------+------------+------------+------------+------------+
|    T5       |    34      |      96    |    2.82    |    Yes     |
+-------------+------------+------------+------------+------------+
|    T6       |    50      |      78    |    1.56    |     No     |
+-------------+------------+------------+------------+------------+
|    T7       |    82      |      293   |    3.57    |     No     |
+-------------+------------+------------+------------+------------+
|    T8       |    35      |      41    |    1.17    |    Yes     |
+-------------+------------+------------+------------+------------+
|    T9       |    177     |     1371   |    7.74    |    Yes     |
+-------------+------------+------------+------------+------------+
                    Table 1: Data <xref target="t-2" format="counter" sectionFormat="of" derivedContent="2"/>, <xref target="t-3" format="counter" sectionFormat="of" derivedContent="3"/>, <xref target="t-4" format="counter" sectionFormat="of" derivedContent="4"/>, <xref target="t-5" format="counter" sectionFormat="of" derivedContent="5"/>, <xref target="t-6" format="counter" sectionFormat="of" derivedContent="6"/>, and <xref target="t-7" format="counter" sectionFormat="of" derivedContent="7"/>.</t>
        </li>
      </ul>
      <table anchor="t-1" align="center" pn="table-1">
        <name slugifiedName="name-data-set-definition">Data Set Definition
</artwork>
      </figure>

      <t>The Definition</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Network</th>
            <th align="left" colspan="1" rowspan="1">Nodes</th>
            <th align="left" colspan="1" rowspan="1">Links</th>
            <th align="left" colspan="1" rowspan="1">Node-to-Link Ratio</th>
            <th align="left" colspan="1" rowspan="1">SRLG Info?</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">T1</td>
            <td align="left" colspan="1" rowspan="1">408</td>
            <td align="left" colspan="1" rowspan="1">665</td>
            <td align="left" colspan="1" rowspan="1">1.63</td>
            <td align="left" colspan="1" rowspan="1">Yes</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">T2</td>
            <td align="left" colspan="1" rowspan="1">587</td>
            <td align="left" colspan="1" rowspan="1">1083</td>
            <td align="left" colspan="1" rowspan="1">1.84</td>
            <td align="left" colspan="1" rowspan="1">No</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">T3</td>
            <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 convention conventions that we use is are as follows</t>

      <t><list style="symbols">
          <t>0 follows:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.b-7">
        <li pn="section-appendix.b-7.1">
          <t indent="0" pn="section-appendix.b-7.1.1">0 SIDs: the The calculated repair path starts with a directly
          connected neighbor that is also a loop free alternate, loop-free alternate; in which case case,
          there is no need to explicitly route the traffic using additional
          SIDs. This scenario is described in <xref
          target="direct_backup"/>.</t>

          <t>1 SIDs: the target="direct_backup" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</t>
        </li>
        <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, node; in which case case, only 1 SID is
          needed to guarantee a loop-free path. This scenario is covered in
          <xref target="pq_backup"/>.</t>

          <t>2 target="pq_backup" format="default" sectionFormat="of" derivedContent="Section 5.2"/>.</t>
        </li>
        <li pn="section-appendix.b-7.3">
          <t indent="0" pn="section-appendix.b-7.3.1">2 or more SIDs: The repair path consists of 2 or more SIDs as
          described in Sections <xref target="adj_pq_backup"/> target="adj_pq_backup" format="counter" sectionFormat="of" derivedContent="5.3"/> and
          <xref
          target="remote_pq_backup"/>. target="remote_pq_backup" format="counter" sectionFormat="of" derivedContent="5.4"/>. We do not cover
          the case for 2 SIDs (<xref target="adj_pq_backup"/>) target="adj_pq_backup" format="default" sectionFormat="of" derivedContent="Section 5.3"/>) separately because there was no granularity in
          the result. Also Also, we treat the node-SID+adj-SID Node-SID + Adj-SID and
          node-SID Node-SID + node-SID
          Node-SID the same because they do not differ from the data plane
          point of view.</t>
        </list></t>

      <t>Table 2A and 2B
        </li>
      </ul>
      <t indent="0" pn="section-appendix.b-8">Tables <xref target="t-2" format="counter" sectionFormat="of" derivedContent="2"/> and <xref target="t-3" format="counter" sectionFormat="of" derivedContent="3"/> below summarize the measurements on
      the number of SIDs needed for link protection</t>

      <figure>
        <artwork>
+-------------+------------+------------+------------+------------+
|   Network   |    0 SIDs  |    1 SID   |   2 SIDs   |   3 SIDs   |
+-------------+------------+------------+------------+------------+
|    T1       |  74.3%     |   25.3%    |   0.5%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T2       |  81.1%     |   18.7%    |   0.2%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T3       |  95.9%     |    4.1%    |   0.1%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T4       |  62.5%     |   35.7%    |   1.8%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T5       |  85.7%     |   14.3%    |   0.0%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T6       |  81.2%     |   18.7%    |   0.0%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T7       |  98.9%     |   1.1%     |   0.0%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T8       |  94.1%     |   5.9%     |   0.0%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T9       |  98.9%     |   1.0%     |   0.0%     |   0.0%     |
+-------------+------------+------------+------------+------------+
        Table 2A: Link protection (repair size distribution)

+-------------+------------+------------+------------+------------+
|   Network   |    0 SIDs  |    1 SID   |   2 SIDs   |   3 SIDs   |
+-------------+------------+------------+------------+------------+
|    T1       |  74.2%     |   99.5%    |    99.9%   |   100.0%   |
+-------------+------------+------------+------------+------------+
|    T2       |  81.1%     |   99.8%    |   100.0%   |   100.0%   |
+-------------+------------+------------+------------+------------+
|    T3       |  95.9%     |   99.9%    |   100.0%   |   100.0%   |
+-------------+------------+------------+------------+------------+
|    T4       |  62.5%     |   98.2%    |   100.0%   |   100.0%   |
+-------------+------------+------------+------------+------------+
|    T5       |  85.7%     |  100.0%    |   100.0%   |   100.0%   |
+-------------+------------+------------+------------+------------+
|    T6       |  81.2%     |   99.9%    |   100.0%   |   100.0%   |
+-------------+------------+------------+------------+------------+
|    T7       |  98,8%     |  100.0%    |   100.0%   |   100.0%   |
+-------------+------------+------------+------------+------------+
|    T8       |  94,1%     |  100.0%    |   100.0%   |   100.0%   |
+-------------+------------+------------+------------+------------+
|    T9       |  98,9%     |  100.0%    |   100.0%   |   100.0%   |
+-------------+------------+------------+------------+------------+
    Table 2B: Link protection repair size cumulative distribution
Table 3A and 3B protection.</t>
      <table anchor="t-2" align="center" pn="table-2">
        <name slugifiedName="name-link-protection-repair-size">Link 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>
          </tr>
        </thead>
        <tbody>
          <tr>
            <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>
            <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 align="left" colspan="1" rowspan="1">81.1%</td>
            <td align="left" colspan="1" rowspan="1">18.7%</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">95.9%</td>
            <td align="left" colspan="1" rowspan="1">4.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">T4</td>
            <td align="left" colspan="1" rowspan="1">62.5%</td>
            <td align="left" colspan="1" rowspan="1">35.7%</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">85.7%</td>
            <td align="left" colspan="1" rowspan="1">14.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">T6</td>
            <td align="left" colspan="1" rowspan="1">81.2%</td>
            <td align="left" colspan="1" rowspan="1">18.7%</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">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>
          <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">5.9%</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>
          </tr>
        </tbody>
      </table>
      <table anchor="t-3" align="center" pn="table-3">
        <name slugifiedName="name-link-protection-repair-size-">Link 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>
          </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 align="left" colspan="1" rowspan="1">81.1%</td>
            <td align="left" colspan="1" rowspan="1">99.8%</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">T3</td>
            <td align="left" colspan="1" rowspan="1">95.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">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">85.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">T6</td>
            <td align="left" colspan="1" rowspan="1">81.2%</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">T7</td>
            <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.

+-------------+------------+------------+------------+------------+
|   Network   |    0 SIDs  |    1 SID   |   2 SIDs   |   3 SIDs   |
+-------------+------------+------------+------------+------------+
|    T1       |  74.2%     |   25.3%    |   0.5%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T2       |                No protection.</t>
      <table anchor="t-4" align="center" pn="table-4">
        <name slugifiedName="name-local-srlg-protection-repai">Local SRLG Information                |
+-------------+------------+------------+------------+------------+
|    T3       |  93.6%     |    6.3%    |   0.0%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T4       |  62.5%     |   35.6%    |   1.8%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T5       |  83.1%     |   16.8%    |   0.0%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T6       |                No 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>
          </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                |
+-------------+---------------------------------------------------+
|    T7       |                No 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                |
+-------------+------------+------------+------------+------------+
|    T8       |  85.2%     |   14.8%    |   0.0%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T9       |  98,9%     |    1.1%    |   0.0%     |   0.0%     |
+-------------+------------+------------+------------+------------+
      Table 3A: Local information</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">T7</td>
            <td colspan="4" align="left" rowspan="1">No SRLG protection repair size distribution

+-------------+------------+------------+------------+------------+
|   Network   |    0 SIDs  |    1 SID   |   2 SIDs   |   3 SIDs   |
+-------------+------------+------------+------------+------------+
|    T1       |  74.2%     |   99.5%    |  99.9%     | 100.0%     |
+-------------+------------+------------+------------+------------+
|    T2       |                No 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 Information                |
+-------------+------------+------------+------------+------------+
|    T3       |  93.6%     |   99.9%    | 100.0%     |   0.0%     |
+-------------+------------+------------+------------+------------+
|    T4       |  62.5%     |   98.2%    | 100.0%     | 100.0%     |
+-------------+------------+------------+------------+------------+
|    T5       |  83.1%     |  100.0%    | 100.0%     | 100.0%     |
+-------------+------------+------------+------------+------------+
|    T6       |                No 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>
          </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                |
+-------------+---------------------------------------------------+
|    T7       |                No 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                |
+-------------+------------+------------+------------+------------+
|    T8       |  85.2%     |   100.0%   | 100.0%     | 100.0%     |
+-------------+------------+------------+------------+------------+
|    T9       |  98.9%     |   100.0%   | 100.0%     | 100.0%     |
+-------------+------------+------------+------------+------------+
 Table 3B: Local information</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">T7</td>
            <td colspan="4" align="left" rowspan="1">No SRLG protection repair size Cumulative distribution
The 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 summarize the measurements on the number of
SIDs needed for node protection.

+---------+----------+----------+----------+----------+----------+
| Network |  0 SIDs  |   1 SID  | 2 SIDs   |  3 SIDs  |  4 SIDs  |
+---------+----------+----------+----------+----------+----------+
|    T1   |  49.8%   | 47.9%    | 2.1%     |  0.1%    |  0.0%    |
+---------+----------+----------+----------+----------+----------+
|    T2   |  36,5%   | 59.6%    | 3.6%     |  0.2%    |  0.0%    |
+---------+----------+----------+----------+----------+----------+
|    T3   |  73.3%   | 25.6%    | 1.1%     |  0.0%    |  0.0%    |
+---------+----------+----------+----------+----------+----------+
|    T4   |  36.1%   | 57.3%    | 6.3%     |  0.2%    |  0.0%    |
+---------+----------+----------+----------+----------+----------+
|    T5   |  73.2%   | 26.8%    | 0%       |  0%      |  0%      |
+---------+----------+----------+----------+----------+----------+
|    T6   |  78.3%   | 21.3%    | 0.3%     |  0%      |  0%      |
+---------+----------+----------+----------+----------+----------+
|    T7   |  66.1%   | 32.8%    | 1.1%     |  0%      |  0%      |
+---------+----------+----------+----------+----------+----------+
|    T8   |  59.7%   | 40.2%    | 0%       |  0%      |  0%      |
+---------+----------+----------+----------+----------+----------+
|    T9   |  98.9%   | 1.0%     | 0%       |  0%      |  0%      |
+---------+----------+----------+----------+----------+----------+
        Table 4A: Node protection (repair size distribution)

+---------+----------+----------+----------+----------+----------+
| Network |  0 SIDs  |   1 SID  | 2 SIDs   |  3 SIDs  |  4 SIDs  |
+---------+----------+----------+----------+----------+----------+
|    T1   |  49.7%   |  97.6%   |  99.8%   | 99.9%    |  100%    |
+---------+----------+----------+----------+----------+----------+
|    T2   |  36.5%   |  96.1%   |  99.7%   | 99.9%    |  100%    |
+---------+----------+----------+----------+----------+----------+
|    T3   |  73.3%   |  98.9%   |  99.9%   | 100.0%   |  100%    |
+---------+----------+----------+----------+----------+----------+
|    T4   |  36.1%   |  93.4%   |  99.8%   | 99.9%    |  100%    |
+---------+----------+----------+----------+----------+----------+
|    T5   |  73.2%   | 100.0%   | 100.0%   | 100.0%   |  100%    |
+---------+----------+----------+----------+----------+----------+
|    T6   |  78.4%   | 99.7%    | 100.0%   | 100.0%   |  100%    |
+---------+----------+----------+----------+----------+----------+
|    T7   |  66.1%   | 98.9%    | 100.0%   | 100.0%   |  100%    |
+---------+----------+----------+----------+----------+----------+
|    T8   |  59.7%   | 100.0%   | 100.0%   | 100.0%   |  100%    |
+---------+----------+----------+----------+----------+----------+
|    T9   |  98.9%   | 100.0%   | 100.0%   | 100.0%   |  100%    |
+---------+----------+----------+----------+----------+----------+
   Table 4B: Node protection (repair size cumulative distribution)
</artwork>
      </figure> 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 <contact fullname="Les Ginsberg"/>,
      <contact fullname="Stewart Bryant"/>, <contact fullname="Alexander       Vainsthein"/>, <contact fullname="Chris Bowers"/>, <contact fullname="Shraddha Hedge"/>, <contact fullname="Wes Hardaker"/>,
      <contact fullname="Gunter Van de Velde"/>, and <contact fullname="John       Scudder"/> for their valuable comments.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false" 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>
  </back>
</rfc>