<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-mpls-ri-rsvp-frr-22" number="9705" ipr="pre5378Trust200902" submissionType="IETF" consensus="true" obsoletes="" updates="4090" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" xml:lang="en" prepTime="2025-03-26T15:21:02" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr-22" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9705" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="RI-RSVP-FRR Bypass">Refresh-Interval Independent RSVP Fast Reroute Facility Protection</title>
    <seriesInfo name="RFC" value="9705" stream="IETF"/>
    <author initials="C." surname="Ramachandran" fullname="Chandra Ramachandran">
      <organization showOnFrontPage="true">Juniper Networks, Inc.</organization>
      <address>
        <email>csekar@juniper.net</email>
      </address>
    </author>
    <author initials="T." surname="Saad" fullname="Tarek Saad">
      <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <email>tsaad@cisco.com</email>
      </address>
    </author>
    <author initials="D." surname="Pacella" fullname="Dante Pacella">
      <organization showOnFrontPage="true">Verizon, Inc.</organization>
      <address>
        <email>dante.j.pacella@verizon.com</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>RTG</area>
    <workgroup>mpls</workgroup>
    <keyword>ri-rsvp-frr</keyword>
    <keyword>RI-RSVP-FRR</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090
      define two local repair techniques to reroute Label Switched Path (LSP)
      traffic over pre-established backup tunnels. Facility backup method
      allows one or more LSPs traversing a connected link or node to be
      protected using a bypass tunnel. The many-to-one nature of local repair
      technique is attractive from a scalability point of view. This document
      enumerates facility backup procedures in RFC 4090 that rely on refresh
      timeout, hence, making facility backup method refresh-interval
      dependent. The RSVP-TE extensions defined in this document will enhance
      the facility backup protection mechanism by making the corresponding
      procedures refresh-interval independent, and hence, compatible with the
      Refresh-Interval Independent RSVP (RI-RSVP) capability specified in RFC
      8370. Hence, this document updates RFC 4090 in order to support the
      RI-RSVP capability specified in RFC 8370.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9705" 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
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
        <t indent="0" pn="section-boilerplate.2-3">
            This document may contain material from IETF Documents or IETF
            Contributions published or made publicly available before November
            10, 2008. The person(s) controlling the copyright in some of this
            material may not have granted the IETF Trust the right to allow
            modifications of such material outside the IETF Standards Process.
            Without obtaining an adequate license from the person(s)
            controlling the copyright in such materials, this document may not
            be modified outside the IETF Standards Process, and derivative
            works of it may not be created outside the IETF Standards Process,
            except to format it for publication as an RFC or to translate it
            into languages other than English.
        </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>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-motivation">Motivation</xref></t>
              </li>
            </ul>
          </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-abbreviations-and-terminolo">Abbreviations and 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">Abbreviations</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" 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-terminology">Terminology</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-problem-description">Problem Description</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-solution-aspects">Solution Aspects</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-requirement-for-rfc-4090-ca">Requirement for RFC 4090 Capable Nodes to Advertise the RI-RSVP Capability</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-signaling-handshake-between">Signaling Handshake Between PLR and MP</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-plr-behavior">PLR Behavior</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-remote-signaling-adjacency">Remote Signaling Adjacency</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp-behavior">MP Behavior</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.4.1"><xref derivedContent="4.2.4" format="counter" sectionFormat="of" target="section-4.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-remote-state-on-mp">"Remote" State on MP</xref></t>
                  </li>
                </ul>
              </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-impact-of-failures-on-lsp-s">Impact of Failures on LSP State</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-non-mp-behavior">Non-MP Behavior</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lp-mp-behavior">LP-MP Behavior</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.3.1"><xref derivedContent="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-np-mp-behavior">NP-MP Behavior</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.4.1"><xref derivedContent="4.3.4" format="counter" sectionFormat="of" target="section-4.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-behavior-of-a-router-that-i">Behavior of a Router That Is Both the LP-MP and NP-MP</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conditional-pathtear">Conditional PathTear</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.4.2">
                  <li pn="section-toc.1-1.4.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.1.1"><xref derivedContent="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sending-the-conditional-pat">Sending the Conditional PathTear</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.2.1"><xref derivedContent="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-processing-the-conditional-">Processing the Conditional PathTear</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.3.1"><xref derivedContent="4.4.3" format="counter" sectionFormat="of" target="section-4.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conditions-object">CONDITIONS Object</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-remote-state-teardown">Remote State Teardown</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.5.2">
                  <li pn="section-toc.1-1.4.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.1.1"><xref derivedContent="4.5.1" format="counter" sectionFormat="of" target="section-4.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-plr-behavior-on-local-repai">PLR Behavior on Local Repair Failure</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.2.1"><xref derivedContent="4.5.2" format="counter" sectionFormat="of" target="section-4.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-plr-behavior-on-resv-rro-ch">PLR Behavior on Resv RRO Change</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.5.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.3.1"><xref derivedContent="4.5.3" format="counter" sectionFormat="of" target="section-4.5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lsp-preemption-during-local">LSP Preemption During Local Repair</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.5.2.3.2">
                      <li pn="section-toc.1-1.4.2.5.2.3.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.5.2.3.2.1.1"><xref derivedContent="4.5.3.1" format="counter" sectionFormat="of" target="section-4.5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-preemption-on-lp-mp-after-p">Preemption on LP-MP After PHOP Link Failure</xref></t>
                      </li>
                      <li pn="section-toc.1-1.4.2.5.2.3.2.2">
                        <t indent="0" pn="section-toc.1-1.4.2.5.2.3.2.2.1"><xref derivedContent="4.5.3.2" format="counter" sectionFormat="of" target="section-4.5.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-preemption-on-np-mp-after-p">Preemption on NP-MP After PHOP Link Failure</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.6">
                <t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent="4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-backward-compatibility-proc">Backward Compatibility Procedures</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.6.2">
                  <li pn="section-toc.1-1.4.2.6.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.6.2.1.1"><xref derivedContent="4.6.1" format="counter" sectionFormat="of" target="section-4.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-detecting-support-for-refre">Detecting Support for Refresh-Interval Independent RSVP FRR</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.6.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.6.2.2.1"><xref derivedContent="4.6.2" format="counter" sectionFormat="of" target="section-4.6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-procedures-for-backward-com">Procedures for Backward Compatibility</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.6.2.2.2">
                      <li pn="section-toc.1-1.4.2.6.2.2.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.6.2.2.2.1.1"><xref derivedContent="4.6.2.1" format="counter" sectionFormat="of" target="section-4.6.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lack-of-support-on-downstre">Lack of Support on Downstream Nodes</xref></t>
                      </li>
                      <li pn="section-toc.1-1.4.2.6.2.2.2.2">
                        <t indent="0" pn="section-toc.1-1.4.2.6.2.2.2.2.1"><xref derivedContent="4.6.2.2" format="counter" sectionFormat="of" target="section-4.6.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lack-of-support-on-upstream">Lack of Support on Upstream Nodes</xref></t>
                      </li>
                      <li pn="section-toc.1-1.4.2.6.2.2.2.3">
                        <t indent="0" pn="section-toc.1-1.4.2.6.2.2.2.3.1"><xref derivedContent="4.6.2.3" format="counter" sectionFormat="of" target="section-4.6.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-incremental-deployment">Incremental Deployment</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.7">
                <t indent="0" pn="section-toc.1-1.4.2.7.1"><xref derivedContent="4.7" format="counter" sectionFormat="of" target="section-4.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-consequences-of-advertising">Consequences of Advertising RI-RSVP Without RI-RSVP-FRR</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-security-considerations">Security Considerations</xref></t>
          </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-iana-considerations">IANA Considerations</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-conditions-object-3">CONDITIONS Object</xref></t>
              </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-references">References</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-normative-references">Normative References</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-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">RSVP-TE relies on a periodic refresh of RSVP messages to synchronize
      and maintain the states related to the Label Switched Path (LSP) along the
      reserved path. In the absence of refresh messages, the LSP-related
      states are automatically deleted. Reliance on periodic refreshes and
      refresh timeouts are problematic from the scalability point of view. The
      number of RSVP-TE LSPs that a router needs to maintain has been growing
      in service provider networks, and the implementations should be capable
      of handling increases in LSP scale.
      </t>
      <t indent="0" pn="section-1-2"><xref target="RFC2961" format="default" sectionFormat="of" derivedContent="RFC2961"/> specifies mechanisms to eliminate the
      reliance on periodic refreshes and refresh timeouts of RSVP messages and
      enables a router to increase the message refresh interval to values much
      longer than the default 30 seconds defined in <xref target="RFC2205" format="default" sectionFormat="of" derivedContent="RFC2205"/>. However, the protocol extensions defined in <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/> for supporting Fast Reroute (FRR) using bypass
      tunnels implicitly rely on short refresh timeouts to clean up stale
      states.
      </t>
      <t indent="0" pn="section-1-3">In order to eliminate the reliance on refresh timeouts, the routers
      should unambiguously determine when a particular LSP state should be
      deleted. In scenarios involving FRR using bypass tunnels <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>, additional explicit teardown messages are
      necessary. The Refresh-Interval Independent RSVP-TE FRR (RI-RSVP-FRR)
      extensions specified in this document consist of procedures to enable
      LSP state cleanup that are essential in supporting the RI-RSVP capability
      for FRR using bypass tunnels from <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>.
      </t>
      <section anchor="intro_motivation" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-motivation">Motivation</name>
        <t indent="0" pn="section-1.1-1">Base RSVP <xref target="RFC2205" format="default" sectionFormat="of" derivedContent="RFC2205"/> maintains state via the
        generation of RSVP Path and Resv refresh messages. Refresh messages are
        used to both synchronize state between RSVP neighbors and to recover
        from lost RSVP messages. The use of Refresh messages to cover many
        possible failures has resulted in a number of operational problems.
        </t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1.1-2">
          <li pn="section-1.1-2.1">One problem relates to RSVP control plane scaling due to
          periodic refreshes of Path and Resv messages.</li>
          <li pn="section-1.1-2.2">Another problem relates to the
          reliability and latency of RSVP signaling.</li>
          <li pn="section-1.1-2.3">An additional problem is the time to clean up the stale state
          after a tear message is lost. For more on these problems, see <xref target="RFC2961" sectionFormat="of" section="1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2961#section-1" derivedContent="RFC2961"/>.</li>
        </ul>
        <t indent="0" pn="section-1.1-3">The problems listed above adversely affect RSVP control plane
        scalability, and RSVP-TE <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/> inherited these
        problems from standard RSVP. Procedures specified in <xref target="RFC2961" format="default" sectionFormat="of" derivedContent="RFC2961"/> address the above-mentioned problems by eliminating
        dependency on refreshes for state synchronization and for recovering
        from lost RSVP messages, and also by eliminating dependency on refresh
        timeout for stale state cleanup. Implementing these procedures allows
        implementations to improve RSVP-TE control plane scalability. For more
        details on eliminating dependency on refresh timeouts for stale state
        cleanup, refer to <xref target="RFC8370" sectionFormat="of" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8370#section-3" derivedContent="RFC8370"/>.
        </t>
        <t indent="0" pn="section-1.1-4">However, the facility backup protection procedures specified in 
     <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/> do not fully address stale state cleanup as the 
     procedures depend on refresh timeouts for stale state cleanup. The 
     updated facility backup protection procedures specified in this document, 
     in combination with RSVP-TE Scaling Techniques <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>, 
     eliminate this dependency on refresh timeouts for stale state cleanup.
        </t>
        <t indent="0" pn="section-1.1-5">The procedures specified in this document assume reliable delivery of 
     RSVP messages, as specified in <xref target="RFC2961" format="default" sectionFormat="of" derivedContent="RFC2961"/>. Therefore, <xref target="RFC2961" format="default" sectionFormat="of" derivedContent="RFC2961"/> is a prerequisite for this 
     document.
        </t>
      </section>
    </section>
    <section anchor="terms-abbrevs" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-abbreviations-and-terminolo">Abbreviations and Terminology</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" 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>
      <t indent="0" pn="section-2-2">
	  In addition, the reader is expected to be familiar with the terminology in <xref target="RFC2205" format="default" sectionFormat="of" derivedContent="RFC2205"/>, <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>, <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>, <xref target="RFC4558" format="default" sectionFormat="of" derivedContent="RFC4558"/>, <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>, and <xref target="RFC8796" format="default" sectionFormat="of" derivedContent="RFC8796"/>.
      </t>
      <section anchor="abbrevs" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-abbreviations">Abbreviations</name>
        <dl indent="3" newline="false" spacing="normal" pn="section-2.1-1">
          <dt pn="section-2.1-1.1">PHOP:</dt>
          <dd pn="section-2.1-1.2">Previous-Hop (can refer to a router or node along the LSP)</dd>
          <dt pn="section-2.1-1.3">PPHOP:</dt>
          <dd pn="section-2.1-1.4">Previous-Previous-Hop (can refer to a router or node along the LSP)</dd>
          <dt pn="section-2.1-1.5">NHOP:</dt>
          <dd pn="section-2.1-1.6">Next-Hop (can refer to a router or node along the LSP)</dd>
          <dt pn="section-2.1-1.7">NNHOP:</dt>
          <dd pn="section-2.1-1.8">Next-Next-Hop (can refer to a router or node along the LSP)</dd>
          <dt pn="section-2.1-1.9">PLR:</dt>
          <dd pn="section-2.1-1.10">Point of Local Repair (can refer to a router as defined in <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>)</dd>
          <dt pn="section-2.1-1.11">MP:</dt>
          <dd pn="section-2.1-1.12">Merge Point (can refer to a router as defined in <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>)</dd>
          <dt pn="section-2.1-1.13">LP-MP:</dt>
          <dd pn="section-2.1-1.14">Link-Protecting Merge Point (can refer to a router or node at the tail of a Link-Protecting bypass tunnel</dd>
          <dt pn="section-2.1-1.15">NP-MP:</dt>
          <dd pn="section-2.1-1.16">Node-Protecting Merge Point (can refer to a router or node at the tail of a Node-Protecting bypass tunnel</dd>
          <dt pn="section-2.1-1.17">PSB:</dt>
          <dd pn="section-2.1-1.18">Path State Block</dd>
          <dt pn="section-2.1-1.19">RSB:</dt>
          <dd pn="section-2.1-1.20">Reservation State Block</dd>
          <dt pn="section-2.1-1.21">RRO:</dt>
          <dd pn="section-2.1-1.22">Record Route Object (as defined in <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>)</dd>
          <dt pn="section-2.1-1.23">TED:</dt>
          <dd pn="section-2.1-1.24">Traffic Engineering Database</dd>
          <dt pn="section-2.1-1.25">RI-RSVP:</dt>
          <dd pn="section-2.1-1.26">Refresh-Interval Independent RSVP (the set of procedures defined in <xref section="3" sectionFormat="of" target="RFC8370" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8370#section-3" derivedContent="RFC8370"/> to eliminate RSVP's reliance on periodic
	message refreshes)</dd>
          <dt pn="section-2.1-1.27">RI-RSVP-FRR:</dt>
          <dd pn="section-2.1-1.28">Refresh-Interval Independent RSVP-TE FRR (the set of procedures defined in this document to eliminate 
	RSVP's reliance on periodic message refreshes when supporting facility backup 
	protection <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>)</dd>
        </dl>
      </section>
      <section anchor="terms" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-terminology">Terminology</name>
        <dl indent="3" newline="false" spacing="normal" pn="section-2.2-1">
          <dt pn="section-2.2-1.1">B-SFRR-Ready:</dt>
          <dd pn="section-2.2-1.2">Bypass Summary FRR Ready Extended ASSOCIATION object as defined
	in <xref target="RFC8796" format="default" sectionFormat="of" derivedContent="RFC8796"/> and added by the PLR 
	for each protected LSP</dd>
          <dt pn="section-2.2-1.3">Conditional PathTear:</dt>
          <dd pn="section-2.2-1.4">A PathTear message containing a suggestion to a 
	receiving downstream router to retain the path state if the receiving router 
	is an NP-MP</dd>
          <dt pn="section-2.2-1.5">Remote PathTear:</dt>
          <dd pn="section-2.2-1.6">A PathTear message sent from a PLR
	to the MP to delete the LSP state on the MP if the PLR had not previously sent the 
	backup path state reliably</dd>
          <dt pn="section-2.2-1.7">LSP state</dt>
          <dd pn="section-2.2-1.8">The combination of "path state" maintained as a PSB and
        "reservation state" maintained as an RSB forms an individual LSP state on an
        RSVP-TE speaker</dd>
        </dl>
      </section>
    </section>
    <section anchor="prob_desc" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-problem-description">Problem Description</name>
      <figure anchor="example_network" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-example-topology">Example Topology</name>
        <artwork align="center" pn="section-3-1.1">
        E
      /   \
     /     \
    /       \
   /         \
  /           \
 /             \
A ----- B ----- C ----- D
        \             /
         \           /
          \         /
           \       /
            \     /
             \   /
               F
</artwork>
      </figure>
      <t indent="0" pn="section-3-2">In the topology in <xref target="example_network" format="default" sectionFormat="of" derivedContent="Figure 1"/>, consider a 
	large number of LSPs from A to D transiting B and C. Assume that refresh 
	interval has been configured to be as long as the order of minutes and 
	that refresh reduction extensions are enabled on all routers.
      </t>
      <t indent="0" pn="section-3-3">In addition, assume that node protection has been configured for the LSPs 
	and the LSPs are protected by each router in the following way:
      </t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3-4">
        <li pn="section-3-4.1">A has made node protection available using bypass LSP A -&gt; E
	-&gt; C; A is the PLR and C is the NP-MP.</li>
        <li pn="section-3-4.2">B has made node protection available using bypass LSP B -&gt; F
	-&gt; D; B is the PLR and D is the NP-MP.</li>
        <li pn="section-3-4.3">C has made link protection available using bypass LSP C -&gt; B
	-&gt; F -&gt; D; C is the PLR and D is the LP-MP.</li>
      </ul>
      <t indent="0" pn="section-3-5">
	In the above condition, assume that the B-C link fails. The following is
	the sequence of events that is expected to occur for all protected
	LSPs under normal conditions.
      </t>
      <ol type="Step %d." indent="adaptive" spacing="normal" start="1" pn="section-3-6">
        <li anchor="step1" pn="section-3-6.1" derivedCounter="Step 1.">B performs a local repair and redirects LSP traffic over the bypass
        LSP B -&gt; F -&gt; D.</li>
        <li anchor="step2" pn="section-3-6.2" derivedCounter="Step 2.">B also creates a backup state for the LSP and triggers the sending of
	a backup LSP state to D over the bypass LSP B -&gt; F -&gt; D.</li>
        <li anchor="step3" pn="section-3-6.3" derivedCounter="Step 3.">D receives the backup LSP states and merges the backups with the
	protected LSPs.</li>
        <li anchor="step4" pn="section-3-6.4" derivedCounter="Step 4.">As the link on C, over which the LSP states are refreshed, has
        failed, C will no longer receive state refreshes. Consequently, the
        protected LSP states on C will time out and C will send the teardown
        messages for all LSPs. As each router should consider itself as an MP,
        C will time out the state only after waiting for an additional
        duration equal to the refresh timeout.</li>
      </ol>
      <t indent="0" pn="section-3-7">While the above sequence of events has been described in <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>, 
	there are a few problems for which no mechanism has been specified 
	explicitly:
      </t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3-8">
        <li pn="section-3-8.1">If the protected LSP on C times out before D receives signaling
        for the backup LSP, then D would receive a PathTear from C prior to
        receiving signaling for the backup LSP, thus resulting in deleting the
        LSP state.  This would be possible at scale even with the default refresh
        time.</li>
        <li pn="section-3-8.2">If C is to keep state until its timeout upon the link failure,
        then with a long refresh interval, this may result in a large amount
        of stale state on C.  Alternatively, if C is to
        delete the state and send a PathTear to D upon the link failure, then this would result in
        deleting the state on D, thus deleting the LSP. D needs a reliable
        mechanism to determine whether or not it is an MP to overcome this
        problem.</li>
        <li pn="section-3-8.3">If head-end A attempts to tear down the LSP after <xref target="step1" format="none" sectionFormat="of" derivedContent="">Step 1</xref> but before <xref target="step2" format="none" sectionFormat="of" derivedContent="">Step 2</xref> of the above sequence, then B may receive
	the teardown message before <xref target="step2" format="none" sectionFormat="of" derivedContent="">Step
	2</xref> and delete the LSP state from its state database. If B
	deletes its state without informing D, with a long refresh interval, this
	could cause a (large) buildup of stale state on D.</li>
        <li pn="section-3-8.4">If B fails to perform a local repair in <xref target="step1" format="none" sectionFormat="of" derivedContent="">Step 1</xref>, then B will delete
        the LSP state from its state database without informing D. As B
        deletes its state without informing D, with a long refresh interval, this
        could cause a (large) buildup of stale state on D.</li>
      </ul>
      <t indent="0" pn="section-3-9">The purpose of this document is to provide solutions to the above 
	problems, which will then make it practical to scale up to a large 
	number of protected LSPs in the network.
      </t>
    </section>
    <section anchor="solution" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-solution-aspects">Solution Aspects</name>
      <t indent="0" pn="section-4-1">The solution consists of five parts:</t>
      <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4-2">
        <li pn="section-4-2.1" derivedCounter="1.">Utilize the MP determination mechanism specified in RSVP-TE Summary
        FRR <xref target="RFC8796" format="default" sectionFormat="of" derivedContent="RFC8796"/> that enables the PLR to signal the
        availability of local protection to the MP. In addition, introduce PLR
        and MP procedures to establish a Node-ID-based Hello session between the
        PLR and the MP to detect router failures and to determine capability.
        See <xref target="sig_handshake" format="default" sectionFormat="of" derivedContent="Section 4.2"/> of this document for more
        details. This part of the solution reuses some of the extensions
        defined in <xref target="RFC8796" format="default" sectionFormat="of" derivedContent="RFC8796"/> and <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>, and the subsequent
        subsections will list the extensions in these documents that are
        utilized in this document.</li>
        <li pn="section-4-2.2" derivedCounter="2.">Handle upstream link or node failures by cleaning up LSP states if
        the node has not found itself as an MP through the MP determination
        mechanism. See <xref target="failures" format="default" sectionFormat="of" derivedContent="Section 4.3"/> of this document for more
        details.</li>
        <li pn="section-4-2.3" derivedCounter="3.">Introduce extensions to enable a router to send a teardown
        message to the downstream router that enables the receiving router to
        conditionally delete its local LSP state.  See <xref target="cnd_path_tear" format="default" sectionFormat="of" derivedContent="Section 4.4"/> of this document for more details.</li>
        <li pn="section-4-2.4" derivedCounter="4.">Enhance facility backup protection by allowing a PLR to directly
        send a teardown message to the MP without requiring the PLR to either
        have a working bypass LSP or have already signaled the backup LSP
        state. See <xref target="rem_tear" format="default" sectionFormat="of" derivedContent="Section 4.5"/> of this document for more
        details.</li>
        <li pn="section-4-2.5" derivedCounter="5.">Introduce extensions to enable the above procedures to be backward
        compatible with routers along the LSP running implementations that
        do not support these procedures.  See <xref target="compatible" format="default" sectionFormat="of" derivedContent="Section 4.6"/> of
        this document for more details.</li>
      </ol>
      <section anchor="adv_capability" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-requirement-for-rfc-4090-ca">Requirement for RFC 4090 Capable Nodes to Advertise the RI-RSVP Capability</name>
        <t indent="0" pn="section-4.1-1">A node supporting facility backup protection <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/> <bcp14>MUST NOT</bcp14> set the RI-RSVP flag (I-bit) that is defined in <xref target="RFC8370" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8370#section-3.1" derivedContent="RFC8370"/> unless it supports all the extensions
        specified in the rest of this document.  Hence, this document updates
        <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/> by defining extensions and additional
        procedures over facility backup protection <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/> in
        order to advertise the RI-RSVP capability <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>. However, if a node supporting facility backup
        protection <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/> does set the RI-RSVP capability (I-bit) but does not support all the extensions specified in the rest of
        this document, then it may result in lingering stale states due to the
        long refresh intervals recommended by <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>.  This
        can also disrupt normal Fast Reroute (FRR) operations.  <xref target="cap_bit_without_support" format="default" sectionFormat="of" derivedContent="Section 4.7"/> of this document delves into this in
        detail.
        </t>
      </section>
      <section anchor="sig_handshake" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-signaling-handshake-between">Signaling Handshake Between PLR and MP</name>
        <section anchor="sig_plr_behavior" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.1">
          <name slugifiedName="name-plr-behavior">PLR Behavior</name>
          <t indent="0" pn="section-4.2.1-1">As per the facility backup procedures <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>, when 
	    an LSP becomes operational on a node and the "local protection desired" 
	    flag has been set in the SESSION_ATTRIBUTE object carried in the Path 
	    message corresponding to the LSP, then the node attempts to make local 
	    protection available for the LSP.
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.2.1-2">
            <li pn="section-4.2.1-2.1">If the "node protection desired" flag is set, then the node
            tries to become a PLR by attempting to create an NP-bypass LSP to
            the NNHOP node avoiding the NHOP node on a protected LSP. In
            case node protection could not be made available, the node
            attempts to create an LP-bypass LSP to the NHOP node avoiding only
            the link that the protected LSP takes to reach the NHOP.</li>
            <li pn="section-4.2.1-2.2">If the "node protection desired" flag is not set, then the PLR
            attempts to create an LP-bypass LSP to the NHOP node avoiding the
            link that the protected LSP takes to reach the NHOP.</li>
          </ul>
          <t indent="0" pn="section-4.2.1-3">With regard to the PLR procedures described above and specified
          in <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>, this document specifies the following
          additional procedures to support RI-RSVP <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>.</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.2.1-4">
            <li pn="section-4.2.1-4.1">While selecting the destination address of the bypass LSP, the
            PLR <bcp14>MUST</bcp14> select the router ID of the NNHOP or NHOP
            node from the Node-ID sub-object included in the RRO that is
            carried in the most recent Resv message corresponding to the
            LSP. If the MP has not included a Node-ID sub-object in the Resv
            RRO and if the PLR and the MP are in the same area, then the PLR
            may utilize the TED to determine the router ID corresponding to
            the interface address that is included by the MP in the RRO. If the
            NP-MP in a different IGP area has not included a Node-ID
            sub-object in the RRO, then the PLR <bcp14>MUST</bcp14> execute
            backward compatibility procedures as if the downstream nodes along
            the LSP do not support the extensions defined in the document (see
            <xref target="dnstr_no_support" format="default" sectionFormat="of" derivedContent="Section 4.6.2.1"/>).</li>
            <li pn="section-4.2.1-4.2">The PLR <bcp14>MUST</bcp14> also include its router ID in a
            Node-ID sub-object in the RRO that is carried in any subsequent Path
            message corresponding to the LSP. While doing so, the
            PLR <bcp14>MUST</bcp14> include the Node-ID sub-object after
            including its IPv4/IPv6 address or unnumbered interface ID
            sub-object.</li>
            <li pn="section-4.2.1-4.3">In parallel to the attempt made to create an NP-bypass or an
            LP-bypass, the PLR <bcp14>MUST</bcp14> initiate a Node-ID-based
            Hello session to the NNHOP or NHOP node respectively along the LSP
            to establish the RSVP-TE signaling adjacency. This Hello session
            is used to detect MP node failure as well as to determine the
            capability of the MP node. The
            PLR <bcp14>MUST</bcp14> conclude that the MP supports the refresh-interval independent FRR procedures defined in this
            document if the MP has set the I-bit in the
            CAPABILITY object <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/> carried in the Hello
            message corresponding to the Node-ID-based Hello session.
            If the MP has not sent Node-ID-based Hello messages or
            has not set the I-bit in the CAPABILITY object <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>, then the PLR <bcp14>MUST</bcp14> execute
            backward compatibility procedures defined in <xref target="dnstr_no_support" format="default" sectionFormat="of" derivedContent="Section 4.6.2.1"/> of this document.</li>
            <li pn="section-4.2.1-4.4">When the PLR associates a bypass to a protected LSP, it
            <bcp14>MUST</bcp14> include a B-SFRR-Ready Extended ASSOCIATION
            object <xref target="RFC8796" format="default" sectionFormat="of" derivedContent="RFC8796"/> and trigger a Path message to be
            sent for the LSP. If a B-SFRR-Ready Extended ASSOCIATION object is
            included in the Path message corresponding to the LSP, the
            encoding and object ordering rules specified in RSVP-TE Summary
            FRR <xref target="RFC8796" format="default" sectionFormat="of" derivedContent="RFC8796"/> <bcp14>MUST</bcp14> be followed. In
            addition to those rules, the PLR <bcp14>MUST</bcp14> set the
            Association Source in the object to its Node-ID address.</li>
          </ul>
        </section>
        <section anchor="sig_rem_adjacency" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.2">
          <name slugifiedName="name-remote-signaling-adjacency">Remote Signaling Adjacency</name>
          <t indent="0" pn="section-4.2.2-1">A Node-ID-based RSVP-TE Hello session is one in which a Node-ID is 
	   used in the source and the destination address fields of RSVP Hello 
	   messages <xref target="RFC4558" format="default" sectionFormat="of" derivedContent="RFC4558"/>. This document extends Node-ID-based 
	   RSVP Hello sessions to track the state of any RSVP-TE neighbor that is 
	   not directly connected by at least one interface. In order to apply 
	   Node-ID-based RSVP-TE Hello sessions between any two routers that are 
	   not immediate neighbors, the router that supports the extensions 
	   defined in the document <bcp14>MUST</bcp14> set the TTL to 255 in all outgoing 
	   Node-ID-based Hello messages exchanged between the PLR and the MP. The 
	   default hello interval for this Node-ID Hello session <bcp14>MUST</bcp14> be set 
	   to the default specified in RSVP-TE Scaling Techniques 
	   <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>.
          </t>
          <t indent="0" pn="section-4.2.2-2">In the rest of the document, the terms "signaling adjacency" 
	    and "remote signaling adjacency" refer specifically to the 
	    RSVP-TE signaling adjacency.
          </t>
        </section>
        <section anchor="sig_mp_behavior" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.3">
          <name slugifiedName="name-mp-behavior">MP Behavior</name>
          <t indent="0" pn="section-4.2.3-1">With regard to the MP procedures that are defined in 
	   <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>, this document specifies the following 
	   additional procedures to support RI-RSVP as defined in 
	   <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>.
          </t>
          <t indent="0" pn="section-4.2.3-2">Each node along an LSP supporting the extensions defined in 
	   this document <bcp14>MUST</bcp14> also include its router ID in the Node-ID 
	   sub-object of the RRO that is carried in the Resv message of the 
	   corresponding LSP. If the PLR has not included a Node-ID sub-object 
	   in the RRO that is carried in the Path message and if the PLR is in 
	   a different IGP area, then the router <bcp14>MUST NOT</bcp14> execute the MP 
	   procedures specified in this document for those LSPs. Instead, the 
	   node <bcp14>MUST</bcp14> execute backward compatibility procedures defined in 
	   <xref target="upstr_no_support" format="default" sectionFormat="of" derivedContent="Section 4.6.2.2"/> of this document as if the upstream nodes along 
	   the LSP do not support the extensions defined in this document.
          </t>
          <t indent="0" pn="section-4.2.3-3">A node receiving a Path message should determine:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.2.3-4">
            <li pn="section-4.2.3-4.1">whether the message contains a B-SFRR-Ready Extended
	   ASSOCIATION object with its own address as the bypass destination
	   address and</li>
            <li pn="section-4.2.3-4.2">whether it has an operational Node-ID signaling adjacency with
	   the Association Source.</li>
          </ul>
          <t indent="0" pn="section-4.2.3-5">The node <bcp14>MUST</bcp14> execute the 
	   backward compatibility procedures defined in 
<xref target="upstr_no_support" format="default" sectionFormat="of" derivedContent="Section 4.6.2.2"/> of this document if:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.2.3-6">
            <li pn="section-4.2.3-6.1">the PLR has not included the B-SFRR-Ready Extended 
ASSOCIATION object,</li>
            <li pn="section-4.2.3-6.2">there is no operational Node-ID signaling 
	   adjacency with the PLR identified by the Association Source address, or</li>
            <li pn="section-4.2.3-6.3">the PLR has not advertised the RI-RSVP capability in its 
	   Node-ID-based Hello messages.</li>
          </ul>
          <t indent="0" pn="section-4.2.3-7">If a matching B-SFRR-Ready Extended ASSOCIATION object is found
          in the Path message and if there is an operational remote Node-ID
          signaling adjacency with the PLR (identified by the Association
          Source) that has advertised the RI-RSVP capability (I-bit) <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>, then the node <bcp14>MUST</bcp14> consider
          itself as the MP for the PLR. The matching and ordering rules for
          Bypass Summary FRR Extended Association specified in RSVP-TE Summary
          FRR <xref target="RFC8796" format="default" sectionFormat="of" derivedContent="RFC8796"/> <bcp14>MUST</bcp14> be followed by the
          implementations supporting this document.
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.2.3-8">
            <li pn="section-4.2.3-8.1">If a matching Bypass Summary FRR Extended Association object
	    is included by the PPHOP node of an LSP and if a corresponding
	    Node-ID signaling adjacency exists with the PPHOP node, then the
	    router <bcp14>MUST</bcp14> conclude it is the NP-MP.</li>
            <li pn="section-4.2.3-8.2">If a matching Bypass Summary FRR Extended Association object
            is included by the PHOP node of an LSP and if a corresponding
            Node-ID signaling adjacency exists with the PHOP node, then the
            router <bcp14>MUST</bcp14> conclude it is the LP-MP.</li>
          </ul>
        </section>
        <section anchor="sig_rem_state" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.4">
          <name slugifiedName="name-remote-state-on-mp">"Remote" State on MP</name>
          <t indent="0" pn="section-4.2.4-1">Once a router concludes it is the MP for a PLR running
          refresh-interval independent FRR procedures as described in the
          preceding section, it <bcp14>MUST</bcp14> create a remote path state
          for the LSP.  The only difference between the "remote" path state
          and the LSP state is the RSVP_HOP object. The RSVP_HOP object in a
          "remote" path state contains the address that the PLR uses to send
          Node-ID Hello messages to the MP.
          </t>
          <t indent="0" pn="section-4.2.4-2">The MP <bcp14>MUST</bcp14> consider the "remote" path state corresponding 
	    to the LSP automatically deleted if:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.2.4-3">
            <li pn="section-4.2.4-3.1">the MP later receives a Path message for the LSP with no
	    matching B-SFRR-Ready Extended ASSOCIATION object corresponding to
	    the PLR's IP address contained in the Path RRO,</li>
            <li pn="section-4.2.4-3.2">the Node-ID signaling adjacency with the PLR goes down,</li>
            <li pn="section-4.2.4-3.3">the MP receives backup LSP signaling for the LSP from the PLR,</li>
            <li pn="section-4.2.4-3.4">the MP receives a PathTear for the LSP, or</li>
            <li pn="section-4.2.4-3.5">the MP deletes the LSP state on a local policy or an exception event.</li>
          </ul>
          <t indent="0" pn="section-4.2.4-4">The purpose of "remote" path state is to enable the PLR 
	    to explicitly tear down the path and reservation states corresponding 
	    to the LSP by sending a tear message for the "remote" path 
	    state. Such a message tearing down the "remote" path state is 
	    called "Remote" PathTear.
          </t>
          <t indent="0" pn="section-4.2.4-5">The scenarios in which a "Remote" PathTear is applied are 
	    described in <xref target="rem_tear" format="default" sectionFormat="of" derivedContent="Section 4.5"/> of this document.
          </t>
        </section>
      </section>
      <section anchor="failures" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-impact-of-failures-on-lsp-s">Impact of Failures on LSP State</name>
        <t indent="0" pn="section-4.3-1">This section describes the procedures that must be executed upon 
	  different kinds of failures by nodes along the path of the LSP. The 
	  procedures that must be executed upon detecting RSVP signaling adjacency 
	  failures do not impact the RSVP-TE graceful restart mechanisms 
	  <xref target="RFC3473" format="default" sectionFormat="of" derivedContent="RFC3473"/> <xref target="RFC5063" format="default" sectionFormat="of" derivedContent="RFC5063"/>. If a node  
	  executing these procedures acts as a helper for a neighboring router, 
	  then the signaling adjacency with the neighbor will be declared as having 
	  failed only after taking into account the grace period extended for the 
	  neighbor by this node acting as a helper.
        </t>
        <t indent="0" pn="section-4.3-2">Node failures are detected from the state of Node-ID Hello 
	  sessions established with immediate neighbors. RSVP-TE Scaling 
	  Techniques <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/> recommends that each node 
	  establish Node-ID Hello sessions with all its immediate neighbors. 
	  A non-immediate PLR or MP failure is detected from the state of remote 
	  signaling adjacency established according to 
	  <xref target="sig_rem_adjacency" format="default" sectionFormat="of" derivedContent="Section 4.2.2"/> of this document.
        </t>
        <section anchor="failures_nonmp" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.1">
          <name slugifiedName="name-non-mp-behavior">Non-MP Behavior</name>
          <t indent="0" pn="section-4.3.1-1">When a router detects the PHOP link or the PHOP node failure for an LSP 
	   and the router is not an MP for the LSP, then it <bcp14>MUST</bcp14> send a Conditional 
	   PathTear (refer to <xref target="cnd_path_tear" format="default" sectionFormat="of" derivedContent="Section 4.4"/> of this document)
	   and delete the PSB and RSB states corresponding to 
	   the LSP.
          </t>
        </section>
        <section anchor="failures_lpmp" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.2">
          <name slugifiedName="name-lp-mp-behavior">LP-MP Behavior</name>
          <t indent="0" pn="section-4.3.2-1">When the PHOP link for an LSP fails on a router that is an LP-MP for 
	   the LSP, the LP-MP <bcp14>MUST</bcp14> retain the PSB and RSB states corresponding 
	   to the LSP until the occurrence of any of the following events:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.3.2-2">
            <li pn="section-4.3.2-2.1">the Node-ID signaling adjacency with the PHOP PLR goes down,</li>
            <li pn="section-4.3.2-2.2">the MP receives a normal or "Remote" PathTear for its PSB, or</li>
            <li pn="section-4.3.2-2.3">the MP receives a ResvTear for its RSB.</li>
          </ul>
          <t indent="0" pn="section-4.3.2-3">When a router that is an LP-MP for an LSP detects PHOP node failure 
	   from the Node-ID signaling adjacency state, the LP-MP <bcp14>MUST</bcp14> send a normal 
	   PathTear and delete the PSB and RSB states corresponding to the LSP.
          </t>
        </section>
        <section anchor="failures_npmp" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.3">
          <name slugifiedName="name-np-mp-behavior">NP-MP Behavior</name>
          <t indent="0" pn="section-4.3.3-1">When a router that is an NP-MP for an LSP detects PHOP link failure
	   or PHOP node failure from the Node-ID signaling adjacency, the router 
	   <bcp14>MUST</bcp14> retain the PSB and RSB states corresponding to the LSP until the 
	   occurrence of any of the following events:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.3.3-2">
            <li pn="section-4.3.3-2.1">the remote Node-ID signaling adjacency with the PPHOP PLR goes down,</li>
            <li pn="section-4.3.3-2.2">the MP receives a normal or "Remote" PathTear for its PSB, or</li>
            <li pn="section-4.3.3-2.3">the MP receives a ResvTear for its RSB.</li>
          </ul>
          <t indent="0" pn="section-4.3.3-3">When a router that is an NP-MP for an LSP does not detect the PHOP
          link or the PHOP node failure but receives a Conditional PathTear
          from the PHOP node, then the router <bcp14>MUST</bcp14> retain the
          PSB and RSB states corresponding to the LSP until the occurrence of
          any of the following events:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.3.3-4">
            <li pn="section-4.3.3-4.1">the remote Node-ID signaling adjacency with the PPHOP PLR goes down,</li>
            <li pn="section-4.3.3-4.2">the MP receives a normal or "Remote" PathTear for its PSB, or</li>
            <li pn="section-4.3.3-4.3">the MP receives a ResvTear for its RSB.</li>
          </ul>
          <t indent="0" pn="section-4.3.3-5">Receiving a Conditional PathTear from the PHOP node will not
          impact the "remote" state from the PPHOP PLR. Note that the PHOP
          node must have sent the Conditional PathTear as it was not an MP for
          the LSP (see <xref target="failures_nonmp" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/> of this document).
          </t>
          <t indent="0" pn="section-4.3.3-6">In the example topology in <xref target="example_network" format="default" sectionFormat="of" derivedContent="Figure 1"/>, we assume 
	   C and D are the NP-MPs for the PLRs A and B, respectively. Now, when the 
	   A-B link fails, B will delete the LSP state, because B is not an MP and its PHOP link has failed (this behavior is required for unprotected LSPs; 
	   refer to <xref target="failures_nonmp" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/> of this document). In the data 
	   plane, that would require B to delete the label forwarding entry 
	   corresponding to the LSP. Thus, if B's downstream nodes C and D continue to 
	   retain state, it would not be correct for D to continue to assume itself 
	   as the NP-MP for the PLR B.
          </t>
          <t indent="0" pn="section-4.3.3-7">The mechanism that enables D to stop considering itself as the 
	   NP-MP for B and delete the corresponding "remote" path 
	   state is given below.
          </t>
          <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4.3.3-8">
            <li pn="section-4.3.3-8.1" derivedCounter="1.">When C receives a Conditional PathTear from B, it decides to
            retain the LSP state as it is the NP-MP of the PLR A.  It also checks
            whether PHOP B had previously signaled availability of node
            protection. As B had previously signaled NP availability by
            including the B-SFRR-Ready Extended ASSOCIATION object, C removes the
            B-SFRR-Ready Extended ASSOCIATION object containing the Association
            Source set to B from the Path message and triggers a Path to
            D.</li>
            <li pn="section-4.3.3-8.2" derivedCounter="2.">When D receives the Path message, it realizes that it is no
            longer the NP-MP for B and so it deletes the corresponding
            "remote" path state. D does not propagate the Path further down
            because the only change is that the B-SFRR-Ready Extended
            ASSOCIATION object corresponding to Association Source B is no
            longer present in the Path message.</li>
          </ol>
        </section>
        <section anchor="failures_lpnpmp" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.4">
          <name slugifiedName="name-behavior-of-a-router-that-i">Behavior of a Router That Is Both the LP-MP and NP-MP</name>
          <t indent="0" pn="section-4.3.4-1">A router may simultaneously be the LP-MP and the NP-MP for the
          PHOP and PPHOP nodes of an LSP, respectively. If the PHOP link
          fails on such a node, the node <bcp14>MUST</bcp14> retain the PSB
          and RSB states corresponding to the LSP until the occurrence of any
          of the following events:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.3.4-2">
            <li pn="section-4.3.4-2.1">both Node-ID signaling adjacencies with PHOP and PPHOP nodes go down,</li>
            <li pn="section-4.3.4-2.2">the MP receives a normal or "Remote" PathTear for its PSB, or</li>
            <li pn="section-4.3.4-2.3">the MP receives a ResvTear for its RSB.</li>
          </ul>
          <t indent="0" pn="section-4.3.4-3">If a router that is both an LP-MP and an NP-MP detects PHOP node 
	   failure, then the node <bcp14>MUST</bcp14> retain the PSB and RSB states corresponding 
	   to the LSP until the occurrence of any of the following events:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.3.4-4">
            <li pn="section-4.3.4-4.1">the remote Node-ID signaling adjacency with the PPHOP PLR goes down,</li>
            <li pn="section-4.3.4-4.2">the MP receives a normal or "Remote" PathTear for its PSB, or</li>
            <li pn="section-4.3.4-4.3">the MP receives a ResvTear for its RSB.</li>
          </ul>
        </section>
      </section>
      <section anchor="cnd_path_tear" numbered="true" removeInRFC="false" toc="include" pn="section-4.4">
        <name slugifiedName="name-conditional-pathtear">Conditional PathTear</name>
        <t indent="0" pn="section-4.4-1">In the example provided in <xref target="failures_npmp" format="default" sectionFormat="of" derivedContent="Section 4.3.3"/> of this
        document, B deletes the PSB and RSB states corresponding to the LSP
        once B detects its PHOP link has gone down as B is not an MP. If B
        were to send a PathTear normally, then C would delete the LSP state
        immediately. In order to avoid this, there should be some mechanism by
        which B can indicate to C that B does not require the receiving node
        to unconditionally delete the LSP state immediately. For this, B
        <bcp14>MUST</bcp14> add a new optional CONDITIONS object in the
        PathTear. The CONDITIONS object is defined in <xref target="cnd_path_tear_obj" format="default" sectionFormat="of" derivedContent="Section 4.4.3"/> of this document. If node C also
        understands the new object, then C <bcp14>MUST NOT</bcp14> delete the
        LSP state if it is an NP-MP.
        </t>
        <section anchor="cnd_path_tear_send" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.1">
          <name slugifiedName="name-sending-the-conditional-pat">Sending the Conditional PathTear</name>
          <t indent="0" pn="section-4.4.1-1">A router that is not an MP for an LSP <bcp14>MUST</bcp14> delete the PSB and RSB 
	   states corresponding to the LSP if the PHOP link or the PHOP Node-ID 
	   signaling adjacency goes down (see <xref target="failures_nonmp" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/> of this document). 
	   The router <bcp14>MUST</bcp14> send a Conditional PathTear if the following are also 
	   true:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.4.1-2">
            <li pn="section-4.4.1-2.1">the ingress has requested node protection for the LSP and</li>
            <li pn="section-4.4.1-2.2">no PathTear is received from the upstream node.</li>
          </ul>
        </section>
        <section anchor="cnd_path_tear_recv" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.2">
          <name slugifiedName="name-processing-the-conditional-">Processing the Conditional PathTear</name>
          <t indent="0" pn="section-4.4.2-1">When a router that is not an NP-MP receives a Conditional PathTear, 
	   the node <bcp14>MUST</bcp14> delete the PSB and RSB states corresponding to the LSP
	   and process the Conditional PathTear by considering it as a normal 
	   PathTear. Specifically, the node <bcp14>MUST NOT</bcp14> propagate the Conditional 
	   PathTear downstream but remove the optional object and send a normal 
	   PathTear downstream.
          </t>
          <t indent="0" pn="section-4.4.2-2">When a node that is an NP-MP receives a Conditional PathTear, it 
	   <bcp14>MUST NOT</bcp14> delete the LSP state. The node <bcp14>MUST</bcp14> check whether the 
	   PHOP node had previously included the B-SFRR-Ready Extended ASSOCIATION 
	   object in the Path. If the object had been included previously by the 
	   PHOP, then the node processing the Conditional PathTear from the PHOP 
	   <bcp14>MUST</bcp14> remove the corresponding object and trigger a Path downstream.
          </t>
          <t indent="0" pn="section-4.4.2-3">If a Conditional PathTear is received from a neighbor that has not 
	   advertised support (refer to <xref target="compatible" format="default" sectionFormat="of" derivedContent="Section 4.6"/> of this document) for the
	   new procedures defined in this document, then the node <bcp14>MUST</bcp14> 
	   consider the message as a normal PathTear. The node <bcp14>MUST</bcp14> propagate 
	   the normal PathTear downstream and delete the LSP state.
          </t>
        </section>
        <section anchor="cnd_path_tear_obj" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.3">
          <name slugifiedName="name-conditions-object">CONDITIONS Object</name>
          <t indent="0" pn="section-4.4.3-1">Any implementation that does not support a Conditional PathTear 
	   needs to ignore the new object but process the message as a normal 
	   PathTear without generating any error. For this reason, the Class-Num 
	   of the new object follows the pattern 10bbbbbb, where "b" represents a bit.
	   (The behavior for objects of this type is specified in <xref target="RFC2205" sectionFormat="of" section="3.10" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2205#section-3.10" derivedContent="RFC2205"/>.)
          </t>
          <t indent="0" pn="section-4.4.3-2">The new object is called the "CONDITIONS" object and will 
	   specify the conditions under which default processing rules of the 
	   RSVP-TE message <bcp14>MUST</bcp14> be invoked.
          </t>
          <t indent="0" pn="section-4.4.3-3">The object has the following format:</t>
          <figure anchor="fig_conditions" align="left" suppress-title="false" pn="figure-2">
            <name slugifiedName="name-conditions-object-2">CONDITIONS Object</name>
            <artwork align="left" pn="section-4.4.3-4.1">
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Length               |  Class        |     C-type    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Flags (Reserved)                           |M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure>
          <dl spacing="compact" newline="false" indent="3" pn="section-4.4.3-5">
            <dt pn="section-4.4.3-5.1">Class:</dt>
            <dd pn="section-4.4.3-5.2">135</dd>
            <dt pn="section-4.4.3-5.3">C-type:</dt>
            <dd pn="section-4.4.3-5.4">1</dd>
            <dt pn="section-4.4.3-5.5">Flags:</dt>
            <dd pn="section-4.4.3-5.6">32 bit field</dd>
            <dt pn="section-4.4.3-5.7">M:</dt>
            <dd pn="section-4.4.3-5.8">Bit 31 is the Merge-point condition (M) bit.
	      If the M bit is set to 1, then the PathTear message <bcp14>MUST</bcp14> be processed 
	      according to the receiver router role, i.e., if the receiving router 
	      is an MP or not for the LSP. If it is not set, then the PathTear 
	      message <bcp14>MUST</bcp14> be processed as a normal PathTear message for the LSP.</dd>
          </dl>
          <t indent="0" pn="section-4.4.3-6">Bits 0-30 are reserved; they <bcp14>MUST</bcp14> be set to zero on transmission and
	      <bcp14>MUST</bcp14> be ignored on receipt.</t>
        </section>
      </section>
      <section anchor="rem_tear" numbered="true" removeInRFC="false" toc="include" pn="section-4.5">
        <name slugifiedName="name-remote-state-teardown">Remote State Teardown</name>
        <t indent="0" pn="section-4.5-1">If the ingress wants to tear down the LSP because of a management 
	   event while the LSP is being locally repaired at a transit PLR, it 
	   would not be desirable to wait until the completion of backup LSP 
	   signaling to perform state cleanup. In this case, the PLR <bcp14>MUST</bcp14> send a 
	   "Remote" PathTear message instructing the MP to delete the PSB 
	   and RSB states corresponding to the LSP. The TTL in the "Remote" 
	   PathTear message <bcp14>MUST</bcp14> be set to 255. Doing this enables LSP state cleanup 
           when the LSP is being locally repaired.
        </t>
        <t indent="0" pn="section-4.5-2">Consider that node C in the example topology 
	   (<xref target="example_network" format="default" sectionFormat="of" derivedContent="Figure 1"/>) has gone down and node B locally 
	   repairs the LSP:
        </t>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4.5-3">        
	  <li pn="section-4.5-3.1" derivedCounter="1.">Ingress A receives a management event to tear down the LSP.</li>
          <li pn="section-4.5-3.2" derivedCounter="2.">A sends a normal PathTear for the LSP to B.</li>
          <li pn="section-4.5-3.3" derivedCounter="3.">Assume B has not initiated the backup signaling for the 
	  LSP during local repair. To enable LSP state cleanup, B sends a 
	  "Remote" PathTear with the destination IP address set to 
	  that of the node D used in the Node-ID signaling adjacency with D
	  and the RSVP_HOP object containing the local address used in the 
	  Node-ID signaling adjacency.</li>
          <li pn="section-4.5-3.4" derivedCounter="4.">B then deletes the PSB and RSB states corresponding to the LSP.</li>
          <li pn="section-4.5-3.5" derivedCounter="5.">On D, there would be a remote signaling adjacency with 
	  B, and so D accepts the "Remote" PathTear and deletes the
	  PSB and RSB states corresponding to the LSP.</li>
        </ol>
        <section anchor="lcl_repair_fail" numbered="true" removeInRFC="false" toc="include" pn="section-4.5.1">
          <name slugifiedName="name-plr-behavior-on-local-repai">PLR Behavior on Local Repair Failure</name>
          <t indent="0" pn="section-4.5.1-1">If local repair fails on the PLR after a failure, the PLR <bcp14>MUST</bcp14> send a 
	   "Remote" PathTear to the MP. The purpose of this is to clean 
	   up LSP state from the PLR to the egress. Upon receiving the PathTear,
	   the MP <bcp14>MUST</bcp14> delete the states corresponding to the LSP and also 
	   propagate the PathTear downstream, thereby achieving state cleanup from 
	   all downstream nodes up to the LSP egress. Note that in the case of link 
	   protection, the PathTear <bcp14>MUST</bcp14> be directed to the LP-MP's Node-ID IP 
	   address rather than the NHOP interface address.
          </t>
        </section>
        <section anchor="resv_rro_chng" numbered="true" removeInRFC="false" toc="include" pn="section-4.5.2">
          <name slugifiedName="name-plr-behavior-on-resv-rro-ch">PLR Behavior on Resv RRO Change</name>
          <t indent="0" pn="section-4.5.2-1">When a PLR router that has already made NP available for an LSP 
	   detects a change in the RRO carried in the Resv message that indicates 
	   that the router's former NP-MP is no longer present on the path of 
	   the LSP, then the router <bcp14>MUST</bcp14> send a "Remote" PathTear 
	   directly to its former NP-MP.
          </t>
          <t indent="0" pn="section-4.5.2-2">In the example topology in <xref target="example_network" format="default" sectionFormat="of" derivedContent="Figure 1"/>, assume node 
	   A has made node protection available for an LSP and C has concluded it 
	   is the NP-MP for PLR A. When the B-C link fails, then C, implementing the 
	   procedure specified in <xref target="failures_lpnpmp" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/> of this 
	   document, will retain the states corresponding to the LSP until one of the following occurs:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.5.2-3">
            <li pn="section-4.5.2-3.1">the remote Node-ID signaling adjacency with A goes down
	     or</li>
            <li pn="section-4.5.2-3.2">a PathTear or a ResvTear is received for its PSB or RSB,
	     respectively.</li>
          </ul>
          <t indent="0" pn="section-4.5.2-4">If B also has made node protection available, B will eventually
	   complete backup LSP signaling with its NP-MP D and trigger a Resv
	   to A with RRO changed.  The new RRO of the LSP carried in the Resv
	   will not contain C. When A processes the Resv message with a new
	   RRO not containing C, its former NP-MP, A, sends a "Remote"
	   PathTear to C. When C receives the "Remote" PathTear for its PSB
	   state, C will send a normal PathTear downstream to D and delete
	   both the PSB and RSB states corresponding to the LSP.  As D has
	   already received backup LSP signaling from B, D will retain the control
	   plane and forwarding states corresponding to the LSP.
          </t>
        </section>
        <section anchor="lcl_repair_preempt" numbered="true" removeInRFC="false" toc="include" pn="section-4.5.3">
          <name slugifiedName="name-lsp-preemption-during-local">LSP Preemption During Local Repair</name>
          <section anchor="lcl_repair_preempt_lpnp" numbered="true" removeInRFC="false" toc="include" pn="section-4.5.3.1">
            <name slugifiedName="name-preemption-on-lp-mp-after-p">Preemption on LP-MP After PHOP Link Failure</name>
            <t indent="0" pn="section-4.5.3.1-1">If an LSP is preempted on an LP-MP after its PHOP link has already 
	   failed but the backup LSP has not been signaled yet as part of the local 
	   repair procedure, then the node <bcp14>MUST</bcp14> send a normal PathTear and delete 
	   both the PSB and RSB states corresponding to the LSP. As the LP-MP has 
	   retained the LSP state expecting the PLR to initiate backup LSP signaling, 
	   preemption would bring down the LSP and the node would not be LP-MP anymore, requiring the node to clean up the LSP state.
            </t>
          </section>
          <section anchor="lcl_repair_preempt_npmp" numbered="true" removeInRFC="false" toc="include" pn="section-4.5.3.2">
            <name slugifiedName="name-preemption-on-np-mp-after-p">Preemption on NP-MP After PHOP Link Failure</name>
            <t indent="0" pn="section-4.5.3.2-1">If an LSP is preempted on an NP-MP after its PHOP link has already 
	   failed but the backup LSP has not been signaled yet, then the node 
	   <bcp14>MUST</bcp14> send a normal PathTear and delete the PSB and RSB states 
	   corresponding to the LSP. As the NP-MP has retained the LSP state 
	   expecting the PLR to initiate backup LSP signaling, preemption 
	   would bring down the LSP and the node would not be NP-MP anymore, 
	   requiring the node to clean up LSP state.
            </t>
            <t indent="0" pn="section-4.5.3.2-2">Consider that the B-C link goes down on the same example topology 
	   (<xref target="example_network" format="default" sectionFormat="of" derivedContent="Figure 1"/>). As C is the NP-MP for the PLR A, C 
	   will retain the LSP state.
            </t>
            <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4.5.3.2-3">
              <li pn="section-4.5.3.2-3.1" derivedCounter="1.">The LSP is preempted on C.</li>
              <li pn="section-4.5.3.2-3.2" derivedCounter="2.">C will delete the RSB state corresponding to the
              LSP. However, C cannot send a PathErr or a ResvTear to the PLR A
              because the backup LSP has not been signaled yet.</li>
              <li pn="section-4.5.3.2-3.3" derivedCounter="3.">As the only reason for C having retained state after PHOP
              node failure was that it was an NP-MP, C sends a normal PathTear
              to D and also deletes its PSB state. D would also delete the PSB
              and RSB states on receiving a PathTear from C.</li>
              <li pn="section-4.5.3.2-3.4" derivedCounter="4.">B starts backup LSP signaling to D. However, as D does not have
              the LSP state, it will reject the backup LSP Path message and send a
              PathErr to B.</li>
              <li pn="section-4.5.3.2-3.5" derivedCounter="5.">B will delete its reservation and send a ResvTear to A.</li>
            </ol>
          </section>
        </section>
      </section>
      <section anchor="compatible" numbered="true" removeInRFC="false" toc="include" pn="section-4.6">
        <name slugifiedName="name-backward-compatibility-proc">Backward Compatibility Procedures</name>
        <t indent="0" pn="section-4.6-1">"Refresh-Interval Independent RSVP FRR" and "RI-RSVP-FRR" refer to the  
	set of procedures defined in this document to eliminate the reliance on
	periodic refreshes. The extensions proposed in RSVP-TE Summary FRR 
	<xref target="RFC8796" format="default" sectionFormat="of" derivedContent="RFC8796"/> may apply to implementations that do not support 
	RI-RSVP-FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP 
	state cleanup, namely Conditional and "Remote" PathTears, require 
	support from one-hop and two-hop neighboring nodes along the LSP. 
	Thus, procedures that fall under the LSP state cleanup category <bcp14>MUST NOT</bcp14> be 
	turned on if any of the nodes involved in the node protection FRR (i.e., 
	the PLR, the MP, and the intermediate node in the case of NP) do not 
	support RI-RSVP-FRR extensions. Note that for LSPs requesting link 
	protection, only the PLR and the LP-MP <bcp14>MUST</bcp14> support the extensions.
        </t>
        <section anchor="compat_detect" numbered="true" removeInRFC="false" toc="include" pn="section-4.6.1">
          <name slugifiedName="name-detecting-support-for-refre">Detecting Support for Refresh-Interval Independent RSVP FRR</name>
          <t indent="0" pn="section-4.6.1-1">An implementation supporting RI-RSVP-FRR extensions <bcp14>MUST</bcp14> set the RI-RSVP Capable flag in the 
	 CAPABILITY object carried in Hello messages as specified in RSVP-TE 
	 Scaling Techniques <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>. If an implementation does 
	 not set the flag even if it supports RI-RSVP-FRR extensions, then its 
	 neighbors will view the node as any node that does not support the
	 extensions.
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.6.1-2">
            <li pn="section-4.6.1-2.1">As nodes supporting the RI-RSVP-FRR extensions initiate
	    Node-ID-based signaling adjacency with all immediate neighbors,
	    such a node on the path of a protected LSP can determine whether
	    its PHOP and NHOP neighbors support RI-RSVP-FRR enhancements.</li>
            <li pn="section-4.6.1-2.2">As nodes supporting the RI-RSVP-FRR extensions also initiate
            Node-ID-based signaling adjacency with the NNHOP along the path of
            the LSP requesting node protection (see <xref target="sig_plr_behavior" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/> of this document), each node along the
            LSP can determine whether its NNHOP node supports RI-RSVP-FRR
            enhancements. If the NNHOP (a) does not reply to remote Node-ID
            Hello messages or (b) does not set the RI-RSVP flag in the
            CAPABILITY object carried in its Node-ID Hello messages, then the
            node acting as the PLR can conclude that NNHOP does not support
            RI-RSVP-FRR extensions.</li>
            <li pn="section-4.6.1-2.3">If node protection is requested for an LSP and if (a) the
            PPHOP node has not included a matching B-SFRR-Ready Extended
            ASSOCIATION object in its Path messages, (b) the PPHOP node has
            not initiated remote Node-ID Hello messages, or (c) the PPHOP node
            does not set the RI-RSVP flag in the CAPABILITY object carried in
            its Node-ID Hello messages, then the node <bcp14>MUST</bcp14>
            conclude that the PLR does not support RI-RSVP-FRR
            extensions.</li>
          </ul>
        </section>
        <section anchor="compat_procedures" numbered="true" removeInRFC="false" toc="include" pn="section-4.6.2">
          <name slugifiedName="name-procedures-for-backward-com">Procedures for Backward Compatibility</name>
          <t indent="0" pn="section-4.6.2-1">Every node that supports RI-RSVP-FRR <bcp14>MUST</bcp14> support the procedures defined 
	 in this section in order to support backward compatibility for 
	 those subsets of LSPs that also traverse nodes that do not support
	 RI-RSVP-FRR.
          </t>
          <section anchor="dnstr_no_support" numbered="true" removeInRFC="false" toc="include" pn="section-4.6.2.1">
            <name slugifiedName="name-lack-of-support-on-downstre">Lack of Support on Downstream Nodes</name>
            <t indent="0" pn="section-4.6.2.1-1">The procedures on the downstream direction are as follows:</t>
            <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.6.2.1-2">
              <li pn="section-4.6.2.1-2.1">If a node finds that the NHOP node along the LSP does not
              support the RI-RSVP-FRR extensions, then the node
              <bcp14>MUST</bcp14> reduce the "refresh period" in the
              TIME_VALUES object carried in the Path messages to the default
              short refresh interval.</li>
              <li pn="section-4.6.2.1-2.2">If node protection is requested for the LSP and the NNHOP
              node along the LSP does not support the RI-RSVP-FRR
              extensions, then the node <bcp14>MUST</bcp14> reduce the
              "refresh period" in the TIME_VALUES object carried in the Path
              messages to the default short refresh interval.</li>
            </ul>
            <t indent="0" pn="section-4.6.2.1-3">If a node reduces the refresh time using the above procedures,
            it <bcp14>MUST NOT</bcp14> send any "Remote" PathTear or
            Conditional PathTear message to the downstream node.</t>
            <t indent="0" pn="section-4.6.2.1-4">Consider the example topology in <xref target="example_network" format="default" sectionFormat="of" derivedContent="Figure 1"/>.  If C does not support the RI-RSVP-FRR
            extensions, then:</t>
            <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.6.2.1-5">
              <li pn="section-4.6.2.1-5.1">A and B reduce the refresh time to the default short
                refresh interval of 30 seconds and trigger a Path message.</li>
              <li pn="section-4.6.2.1-5.2">If B is not an MP and if the PHOP link of B fails, B cannot
		send a Conditional PathTear to C but times out the PSB state
		from A normally. Note that B can only normally time out the PSB state A
		if A did not set the long refresh in the TIME_VALUES
		object carried in the Path messages sent earlier.</li>
            </ul>
          </section>
          <section anchor="upstr_no_support" numbered="true" removeInRFC="false" toc="include" pn="section-4.6.2.2">
            <name slugifiedName="name-lack-of-support-on-upstream">Lack of Support on Upstream Nodes</name>
            <t indent="0" pn="section-4.6.2.2-1">The procedures on the upstream direction are as follows:</t>
            <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.6.2.2-2">
              <li pn="section-4.6.2.2-2.1">If a node finds that the PHOP node along the LSP does
	      not support the RI-RSVP-FRR extensions, then the node
	      <bcp14>MUST</bcp14> reduce the "refresh period" in the
	      TIME_VALUES object carried in the Resv messages to the default
	      short refresh interval.</li>
              <li pn="section-4.6.2.2-2.2">If node protection is requested for the LSP and the PHOP
              node along the LSP does not support the RI-RSVP-FRR
              extensions, then the node <bcp14>MUST</bcp14> reduce the
              "refresh period" in the TIME_VALUES object carried in the Path
              messages to the default short refresh interval (thus, the NHOP
              can use compatible values when sending a Resv).</li>
              <li pn="section-4.6.2.2-2.3">If node protection is requested for the LSP and the PPHOP
              node does not support the RI-RSVP-FRR extensions, then the node
              <bcp14>MUST</bcp14> reduce the "refresh period" in the
              TIME_VALUES object carried in the Resv messages to the default
              short refresh interval.</li>
              <li pn="section-4.6.2.2-2.4">If the node reduces the refresh time using the above
              procedures, it <bcp14>MUST NOT</bcp14> execute MP procedures
              specified in <xref target="failures" format="default" sectionFormat="of" derivedContent="Section 4.3"/> of this document.</li>
            </ul>
          </section>
          <section anchor="incr_deploy" numbered="true" removeInRFC="false" toc="include" pn="section-4.6.2.3">
            <name slugifiedName="name-incremental-deployment">Incremental Deployment</name>
            <t indent="0" pn="section-4.6.2.3-1">The backward compatibility procedures described in the previous 
	  subsections imply that a router supporting the RI-RSVP-FRR 
	  extensions specified in this document can apply the procedures 
	  specified in this document either in the downstream or upstream 
	  direction of an LSP, depending on the capability of the routers 
	  downstream or upstream in the LSP.
            </t>
            <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.6.2.3-2">
              <li pn="section-4.6.2.3-2.1">RI-RSVP-FRR extensions and procedures are enabled for 
		downstream Path, PathTear, and ResvErr messages corresponding 
		to an LSP if link protection is requested for the LSP and the 
		NHOP node supports the extensions.</li>
              <li pn="section-4.6.2.3-2.2">RI-RSVP-FRR extensions and procedures are enabled for 
		downstream Path, PathTear, and ResvErr messages corresponding 
		to an LSP if node protection is requested for the LSP and both 
		NHOP and NNHOP nodes support the extensions.</li>
              <li pn="section-4.6.2.3-2.3">RI-RSVP-FRR extensions and procedures are enabled for
              upstream PathErr, Resv, and ResvTear messages corresponding to an
              LSP if link protection is requested for the LSP and the PHOP
              node supports the extensions.</li>
              <li pn="section-4.6.2.3-2.4">RI-RSVP-FRR extensions and procedures are enabled for
              upstream PathErr, Resv, and ResvTear messages corresponding to an
              LSP if node protection is requested for the LSP and both PHOP
              and PPHOP nodes support the extensions.</li>
            </ul>
            <t indent="0" pn="section-4.6.2.3-3">For example, if an implementation supporting the RI-RSVP-FRR 
	  extensions specified in this document is deployed on all routers in a
	  particular region of the network and if all the LSPs in the network 
	  request node protection, then the FRR extensions will only be 
	  applied for the LSP segments that traverse the particular region. 
	  This will aid incremental deployment of these extensions and also 
	  allow reaping the benefits of the extensions in portions of the 
	  network where it is supported.
            </t>
          </section>
        </section>
      </section>
      <section anchor="cap_bit_without_support" numbered="true" removeInRFC="false" toc="include" pn="section-4.7">
        <name slugifiedName="name-consequences-of-advertising">Consequences of Advertising RI-RSVP Without RI-RSVP-FRR</name>
        <t indent="0" pn="section-4.7-1">If a node supporting facility backup protection <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/> 
	  sets the RI-RSVP capability (I-bit) but does not support the RI-RSVP-FRR
          extensions, due to an implementation bug or configuration error, then it 
          leaves room for the stale state to linger around for an inordinate period of 
	  time or for disruption of normal FRR operations
	  (see <xref target="prob_desc" format="default" sectionFormat="of" derivedContent="Section 3"/> of this document). Consider the example 
	  topology (<xref target="example_network" format="default" sectionFormat="of" derivedContent="Figure 1"/>) provided in this document.
        </t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.7-2">
          <li pn="section-4.7-2.1">Assume node B does set the RI-RSVP capability in its Node-ID-based
          Hello messages even though it does not support RI-RSVP-FRR
          extensions. When B detects the failure of its PHOP link along an
          LSP, it will not send a Conditional PathTear to C as required by the
          RI-RSVP-FRR procedures. If B simply leaves the LSP state without
          deleting, then B may end up holding on to the stale state until the
          (long) refresh timeout.</li>
          <li pn="section-4.7-2.2">Instead of node B, assume node C does set the RI-RSVP capability in
          its Node-ID-based Hello messages even though it does not support
          RI-RSVP-FRR extensions. When B details the failure of its PHOP link
          along an LSP, it will send a Conditional PathTear to C as required by
          the RI-RSVP-FRR procedures. However, C would not recognize the condition
          encoded in the PathTear and end up tearing down the LSP.</li>
          <li pn="section-4.7-2.3">Assume node B does set the RI-RSVP capability in its Node-ID-based
          Hello messages even though it does not support RI-RSVP-FRR
          extensions. In addition, assume local repair is about to commence on node B
          for an LSP that has only requested link protection, that is, B has
          not initiated the backup LSP signaling for the LSP. If node B
          receives a normal PathTear at this time from ingress A because of a
          management event initiated on A, then B simply deletes the LSP state
          without sending a Remote PathTear to the LP-MP C, so C may end up
          holding on to the stale state until the (long) refresh timeout.</li>
        </ul>
      </section>
    </section>
    <section anchor="Security" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">The security considerations pertaining to the original RSVP protocol
         (<xref target="RFC2205" format="default" sectionFormat="of" derivedContent="RFC2205"/>, <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>, and <xref target="RFC5920" format="default" sectionFormat="of" derivedContent="RFC5920"/>) 
	 remain relevant. When using RSVP cryptographic authentication 
	 <xref target="RFC2747" format="default" sectionFormat="of" derivedContent="RFC2747"/>,  more robust algorithms such as HMAC-SHA256,
	 HMAC-SHA384, or HMAC-SHA512 <xref target="RFC2104" format="default" sectionFormat="of" derivedContent="RFC2104"/> <xref target="FIPS-180-4" format="default" sectionFormat="of" derivedContent="FIPS-180-4"/>
        <bcp14>SHOULD</bcp14> be used when computing the keyed message digest where possible.
      </t>
      <t indent="0" pn="section-5-2">This document extends the applicability of Node-ID-based Hello
      sessions between immediate neighbors. The Node-ID-based Hello session
      between the PLR and the NP-MP may require the two routers to exchange
      Hello messages with a non-immediate neighbor. Therefore, the
      implementations <bcp14>SHOULD</bcp14> provide the option to configure either a
      specific neighbor or global Node-ID authentication key to authentication
      messages received from Node-ID neighbors. The network administrator
      <bcp14>SHOULD</bcp14> utilize this option to enable RSVP-TE routers to
      authenticate Node-ID Hello messages received with a TTL greater than 1.
      Implementations <bcp14>SHOULD</bcp14> also provide the option to specify
      a limit on the number of Node-ID-based Hello sessions that can be
      established on a router supporting the extensions defined in this
      document.
      </t>
    </section>
    <section anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="IANA_Conditions" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-conditions-object-3">CONDITIONS Object</name>
        <t indent="0" pn="section-6.1-1">IANA maintains the "Class Names, Class Numbers, and Class Types" registry 
	  in the "RSVP Parameters" registry group (see
          <eref target="http://www.iana.org/assignments/rsvp-parameters/" brackets="angle"/>).
          IANA has extended these registries by adding a new Class Number 
          (in the 10bbbbbb range) and assigning a new C-Type under this Class Number, 
          as described below (see <xref target="cnd_path_tear_obj" format="default" sectionFormat="of" derivedContent="Section 4.4.3"/>). New Class Type values for Class Name "CONDITIONS" can be added via "IETF Review" <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.
        </t>
        <table anchor="table1" align="center" pn="table-1">
          <name slugifiedName="name-class-names-class-numbers-a">Class Names, Class Numbers, and Class Types</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Class Number</th>
              <th align="left" colspan="1" rowspan="1">Class Name</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">135</td>
              <td align="left" colspan="1" rowspan="1">CONDITIONS</td>
              <td align="left" colspan="1" rowspan="1">RFC 9705</td>
            </tr>
          </tbody>
        </table>
        <table anchor="table2" align="center" pn="table-2">
          <name slugifiedName="name-class-types-or-c-types-135-">Class Types or C-Types - 135 CONDITIONS</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">CONDITIONS</td>
              <td align="left" colspan="1" rowspan="1">RFC 9705</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-6.1-4">IANA has added a subregistry called "CONDITIONS Object
	  Flags" as shown below.  New registrations can be added via "IETF Review" <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
        <table anchor="table3" align="center" pn="table-3">
          <name slugifiedName="name-conditions-object-flags">CONDITIONS Object Flags</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Bit Number</th>
              <th align="left" colspan="1" rowspan="1">32-Bit Value</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0-30</td>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">Unassigned</td>
              <td align="left" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">31</td>
              <td align="left" colspan="1" rowspan="1">0x0001</td>
              <td align="left" colspan="1" rowspan="1">Merge-point</td>
              <td align="left" colspan="1" rowspan="1">RFC 9705</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.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 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="RFC2205" target="https://www.rfc-editor.org/info/rfc2205" quoteTitle="true" derivedAnchor="RFC2205">
          <front>
            <title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification</title>
            <author fullname="R. Braden" initials="R." role="editor" surname="Braden"/>
            <author fullname="L. Zhang" initials="L." surname="Zhang"/>
            <author fullname="S. Berson" initials="S." surname="Berson"/>
            <author fullname="S. Herzog" initials="S." surname="Herzog"/>
            <author fullname="S. Jamin" initials="S." surname="Jamin"/>
            <date month="September" year="1997"/>
            <abstract>
              <t indent="0">This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2205"/>
          <seriesInfo name="DOI" value="10.17487/RFC2205"/>
        </reference>
        <reference anchor="RFC2747" target="https://www.rfc-editor.org/info/rfc2747" quoteTitle="true" derivedAnchor="RFC2747">
          <front>
            <title>RSVP Cryptographic Authentication</title>
            <author fullname="F. Baker" initials="F." surname="Baker"/>
            <author fullname="B. Lindell" initials="B." surname="Lindell"/>
            <author fullname="M. Talwar" initials="M." surname="Talwar"/>
            <date month="January" year="2000"/>
            <abstract>
              <t indent="0">This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2747"/>
          <seriesInfo name="DOI" value="10.17487/RFC2747"/>
        </reference>
        <reference anchor="RFC2961" target="https://www.rfc-editor.org/info/rfc2961" quoteTitle="true" derivedAnchor="RFC2961">
          <front>
            <title>RSVP Refresh Overhead Reduction Extensions</title>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <author fullname="D. Gan" initials="D." surname="Gan"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <author fullname="P. Pan" initials="P." surname="Pan"/>
            <author fullname="F. Tommasi" initials="F." surname="Tommasi"/>
            <author fullname="S. Molendini" initials="S." surname="Molendini"/>
            <date month="April" year="2001"/>
            <abstract>
              <t indent="0">This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2961"/>
          <seriesInfo name="DOI" value="10.17487/RFC2961"/>
        </reference>
        <reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3209" quoteTitle="true" derivedAnchor="RFC3209">
          <front>
            <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
            <author fullname="D. Awduche" initials="D." surname="Awduche"/>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <author fullname="D. Gan" initials="D." surname="Gan"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="V. Srinivasan" initials="V." surname="Srinivasan"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <date month="December" year="2001"/>
            <abstract>
              <t indent="0">This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3209"/>
          <seriesInfo name="DOI" value="10.17487/RFC3209"/>
        </reference>
        <reference anchor="RFC3473" target="https://www.rfc-editor.org/info/rfc3473" quoteTitle="true" derivedAnchor="RFC3473">
          <front>
            <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions</title>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="January" year="2003"/>
            <abstract>
              <t indent="0">This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3473"/>
          <seriesInfo name="DOI" value="10.17487/RFC3473"/>
        </reference>
        <reference anchor="RFC4090" target="https://www.rfc-editor.org/info/rfc4090" quoteTitle="true" derivedAnchor="RFC4090">
          <front>
            <title>Fast Reroute Extensions to RSVP-TE for LSP Tunnels</title>
            <author fullname="P. Pan" initials="P." role="editor" surname="Pan"/>
            <author fullname="G. Swallow" initials="G." role="editor" surname="Swallow"/>
            <author fullname="A. Atlas" initials="A." role="editor" surname="Atlas"/>
            <date month="May" year="2005"/>
            <abstract>
              <t indent="0">This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.</t>
              <t indent="0">Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4090"/>
          <seriesInfo name="DOI" value="10.17487/RFC4090"/>
        </reference>
        <reference anchor="RFC4558" target="https://www.rfc-editor.org/info/rfc4558" quoteTitle="true" derivedAnchor="RFC4558">
          <front>
            <title>Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement</title>
            <author fullname="Z. Ali" initials="Z." surname="Ali"/>
            <author fullname="R. Rahman" initials="R." surname="Rahman"/>
            <author fullname="D. Prairie" initials="D." surname="Prairie"/>
            <author fullname="D. Papadimitriou" initials="D." surname="Papadimitriou"/>
            <date month="June" year="2006"/>
            <abstract>
              <t indent="0">Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4558"/>
          <seriesInfo name="DOI" value="10.17487/RFC4558"/>
        </reference>
        <reference anchor="RFC5063" target="https://www.rfc-editor.org/info/rfc5063" quoteTitle="true" derivedAnchor="RFC5063">
          <front>
            <title>Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart</title>
            <author fullname="A. Satyanarayana" initials="A." role="editor" surname="Satyanarayana"/>
            <author fullname="R. Rahman" initials="R." role="editor" surname="Rahman"/>
            <date month="October" year="2007"/>
            <abstract>
              <t indent="0">This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.</t>
              <t indent="0">Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.</t>
              <t indent="0">The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.</t>
              <t indent="0">These extensions are not used to create or restore data plane state.</t>
              <t indent="0">The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5063"/>
          <seriesInfo name="DOI" value="10.17487/RFC5063"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </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 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="RFC8370" target="https://www.rfc-editor.org/info/rfc8370" quoteTitle="true" derivedAnchor="RFC8370">
          <front>
            <title>Techniques to Improve the Scalability of RSVP-TE Deployments</title>
            <author fullname="V. Beeram" initials="V." role="editor" surname="Beeram"/>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <author fullname="D. Pacella" initials="D." surname="Pacella"/>
            <author fullname="T. Saad" initials="T." surname="Saad"/>
            <date month="May" year="2018"/>
            <abstract>
              <t indent="0">Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.</t>
              <t indent="0">This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8370"/>
          <seriesInfo name="DOI" value="10.17487/RFC8370"/>
        </reference>
        <reference anchor="RFC8796" target="https://www.rfc-editor.org/info/rfc8796" quoteTitle="true" derivedAnchor="RFC8796">
          <front>
            <title>RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels</title>
            <author fullname="M. Taillon" initials="M." surname="Taillon"/>
            <author fullname="T. Saad" initials="T." role="editor" surname="Saad"/>
            <author fullname="R. Gandhi" initials="R." surname="Gandhi"/>
            <author fullname="A. Deshmukh" initials="A." surname="Deshmukh"/>
            <author fullname="M. Jork" initials="M." surname="Jork"/>
            <author fullname="V. Beeram" initials="V." surname="Beeram"/>
            <date month="July" year="2020"/>
            <abstract>
              <t indent="0">This document updates RFC 4090 for the Resource Reservation Protocol (RSVP) Traffic Engineering (TE) procedures defined for facility backup protection. The updates include extensions that reduce the amount of signaling and processing that occurs during Fast Reroute (FRR); as a result, scalability when undergoing FRR convergence after a link or node failure is improved. These extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and the Merge Point (MP) nodes to be independent of the number of protected Label Switched Paths (LSPs) traversing between them when facility bypass FRR protection is used. The signaling extensions are fully backwards compatible with nodes that do not support them.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8796"/>
          <seriesInfo name="DOI" value="10.17487/RFC8796"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="FIPS-180-4" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf" quoteTitle="true" derivedAnchor="FIPS-180-4">
          <front>
            <title>Secure Hash Standard</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2015"/>
          </front>
          <seriesInfo name="FIPS PUB" value="180-4"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>
        <reference anchor="RFC2104" target="https://www.rfc-editor.org/info/rfc2104" quoteTitle="true" derivedAnchor="RFC2104">
          <front>
            <title>HMAC: Keyed-Hashing for Message Authentication</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
            <author fullname="M. Bellare" initials="M." surname="Bellare"/>
            <author fullname="R. Canetti" initials="R." surname="Canetti"/>
            <date month="February" year="1997"/>
            <abstract>
              <t indent="0">This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2104"/>
          <seriesInfo name="DOI" value="10.17487/RFC2104"/>
        </reference>
        <reference anchor="RFC5920" target="https://www.rfc-editor.org/info/rfc5920" quoteTitle="true" derivedAnchor="RFC5920">
          <front>
            <title>Security Framework for MPLS and GMPLS Networks</title>
            <author fullname="L. Fang" initials="L." role="editor" surname="Fang"/>
            <date month="July" year="2010"/>
            <abstract>
              <t indent="0">This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5920"/>
          <seriesInfo name="DOI" value="10.17487/RFC5920"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">We are very grateful to <contact fullname="Yakov Rekhter"/> for his
      contributions to the development of the idea and thorough review of the
      content of the document.  We are thankful to <contact fullname="Raveendra       Torvi"/> and <contact fullname="Yimin Shen"/> for their comments and
      inputs on early versions of the document. We also thank <contact fullname="Alexander Okonnikov"/> for his review and comments on the
      document.
      </t>
    </section>
    <section anchor="Contributors" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Ina Minei">
        <organization showOnFrontPage="true">Google, Inc.</organization>
        <address>
          <email>inaminei@google.com</email>
        </address>
      </contact>
      <contact fullname="Markus Jork">
        <organization showOnFrontPage="true">Juniper Networks, Inc.</organization>
        <address>
          <email>mjork@juniper.net</email>
        </address>
      </contact>
      <contact fullname="Harish Sitaraman">
        <organization showOnFrontPage="true">Individual Contributor</organization>
        <address>
          <email>harish.ietf@gmail.com</email>
        </address>
      </contact>
      <contact fullname="Vishnu Pavan Beeram">
        <organization showOnFrontPage="true">Juniper Networks, Inc.</organization>
        <address>
          <email>vbeeram@juniper.net</email>
        </address>
      </contact>
      <contact fullname="Ebben Aries">
        <organization showOnFrontPage="true">Juniper Networks, Inc.</organization>
        <address>
          <email>exa@juniper.com</email>
        </address>
      </contact>
      <contact fullname="Mike Taillon">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal/>
          <email>mtaillon@cisco.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="C." surname="Ramachandran" fullname="Chandra Ramachandran">
        <organization showOnFrontPage="true">Juniper Networks, Inc.</organization>
        <address>
          <email>csekar@juniper.net</email>
        </address>
      </author>
      <author initials="T." surname="Saad" fullname="Tarek Saad">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <email>tsaad@cisco.com</email>
        </address>
      </author>
      <author initials="D." surname="Pacella" fullname="Dante Pacella">
        <organization showOnFrontPage="true">Verizon, Inc.</organization>
        <address>
          <email>dante.j.pacella@verizon.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
