<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced.
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2104 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC2747 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2747.xml"> nbsp    "&#160;">
  <!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"> zwsp   "&#8203;">
  <!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml"> nbhy   "&#8209;">
  <!ENTITY RFC2961 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2961.xml">
<!ENTITY RFC2205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml">
<!ENTITY RFC4558 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4558.xml">
<!ENTITY RFC3473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!ENTITY RFC5063 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5063.xml">
<!ENTITY RFC8370 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8370.xml">
<!ENTITY RFC8796 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8796.xml">
<!ENTITY RFC5920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5920.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"> wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-mpls-ri-rsvp-frr-22" number="9705" ipr="pre5378Trust200902" submissionType="IETF" consensus="true" updates="4090"> obsoletes="" updates="4090" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3" xml:lang="en" >

<!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add [rfced] Please review the attributes updates="NNNN" following questions and obsoletes="NNNN"
    they will automatically changes regarding this
document's title:

a) FYI - Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide").

b) Should "RSVP" be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
   <!-- The abbreviated added to the title is used in for consistency with the page header - it is only necessary if rest of the
        full title is longer than 39 characters -->

   <title abbrev="RI-RSVP FRR Bypass">Refresh-interval
document and the abbreviated title?

Original:
   Refresh-interval Independent FRR Facility Protection
   </title>

   <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor

Current:
   Refresh-Interval Independent Fast Reroute (FRR) Facility Protection

Perhaps:
   Refresh-Interval Independent RSVP Fast Reroute (RI-RSVP-FRR) Facility Protection

-->

 <front>
   <title abbrev="RI-RSVP-FRR Bypass">Refresh-Interval Independent Fast Reroute (FRR) Facility Protection</title>
    <seriesInfo name="RFC" value="9705"/>
    <author initials="C. " initials="C." surname="Ramachandran" fullname="Chandra Ramachandran">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <email>csekar@juniper.net</email>
      </address>
    </author>
    <author initials="T. " initials="T." surname="Saad" fullname="Tarek Saad">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>tsaad@cisco.com</email>
      </address>
    </author>
    <author initials="I. " initials="I." surname="Minei" fullname="Ina Minei">
      <organization>Google, Inc.</organization>
      <address>
        <email>inaminei@google.com</email>
      </address>
    </author>
    <author initials="D. " initials="D." surname="Pacella" fullname="Dante Pacella">
      <organization>Verizon, Inc.</organization>
      <address>
        <email>dante.j.pacella@verizon.com</email>
      </address>
    </author>
    <date year="2024" /> month="December"/>

   <area>RTG</area>
    <workgroup>mpls</workgroup>

<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
        in the current day for you. If only the current year is specified, xml2rfc will fill [rfced] Please insert any keywords (beyond those that appear in
the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Routing</area>

   <workgroup>MPLS Working Group</workgroup>

   <!-- WG name at the upperleft corner of the doc,
        IETF is fine title) for individual submissions.
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>template</keyword>

   <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect use on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

  <abstract>
      <t>The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090 defines
      define two local repair techniques to reroute Label Switched Path (LSP)
      traffic over pre-established backup tunnel. tunnels. Facility backup method allows methods
      allow 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
      techniques is attractive from a scalability point of view. This document
      enumerates facility backup procedures in RFC 4090 that rely on refresh timeout and hence make
      timeout, hence, making facility backup method methods 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 independent, and hence hence, compatible with Refresh-interval 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>

  <note title="Requirements Language">

  <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in BCP 14 <xref target="RFC2119"/>
     <xref target="RFC8174"/> when, and only when, they
     appear in all capitals, as shown here.
  </t>
  </note>
  </front>

  <middle>
    <section anchor="intro" title="Introduction"> anchor="intro">
      <name>Introduction</name>
      <t>RSVP-TE relies on a periodic refresh of RSVP messages to synchronize
      and maintain the states related to the Label Switched Path (LSP) related states 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 networks, and the implementations should be capable
      of handling increase increases in LSP scale.
      </t>
      <t><xref target="RFC2961"/> specifies mechanisms to eliminate the
      reliance on periodic
     refresh refreshes and refresh timeout 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"/>. However, the protocol extensions defined in <xref
      target="RFC4090"/> for supporting Fast Reroute (FRR) using bypass
      tunnels implicitly rely on short refresh timeouts to cleanup clean up stale
      states.
      </t>
      <t>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 <xref target="RFC4090"/> FRR using bypass tunnels, tunnels <xref
      target="RFC4090"/>, additional explicit tear down teardown messages are
      necessary. Refresh-interval The Refresh-Interval Independent RSVP FRR (RI-RSVP-FRR)
      extensions specified in this document
     consists consist of procedures to enable
      LSP state cleanup that are essential in supporting the RI-RSVP capability
      for <xref target="RFC4090"/> FRR using bypass tunnels. tunnels from <xref target="RFC4090"/>.
      </t>
      <section anchor="intro_motivation" title="Motivation"> anchor="intro_motivation">
        <name>Motivation</name>

<!-- [rfced] Should the first bullet be separated into two separate bullets
because it contains two separate problems?

Original:
   The use of Refresh messages to
   cover many possible failures has resulted in a number of operational
   problems.

   -  One problem relates to RSVP control plane scaling due to periodic
      refreshes of Path and Resv messages, another relates to the
      reliability and latency of RSVP signaling.

   -  An additional problem is the time to clean up the stale state
      after a tear message is lost.  For more on these problems see
      Section 1 of RSVP Refresh Overhead Reduction Extensions [RFC2961].

Perhaps:
   The use of Refresh messages to
   cover many possible failures has resulted in a number of operational
   problems.

   *  One problem relates to RSVP control plane scaling due to periodic
      refreshes of Path and Resv messages

   *  Another problem relates to the relates to the reliability and latency of
      RSVP signaling.  reliability and latency of RSVP signaling.

   *  An additional problem is the time to clean up the stale state
      after a tear message is lost.  For more on these problems see
      Section 1 of [RFC2961].

-->

        <t>Base RSVP <xref target="RFC2205"/> maintains state via the
        generation of RSVP Path/Resv 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.

     <list style="hanging">
      <t hangText="-">One
        </t>
        <ul>
          <li>One problem relates to RSVP control plane scaling due to
          periodic refreshes of Path and Resv messages, messages and another relates to the
          reliability and latency of RSVP signaling.
      </t>
     </list>
     <list style="hanging">
      <t hangText="-">An signaling.</li>
          <li>An additional problem is the time to clean up the stale state
          after a tear message is lost. For more on these
		      problems problems, see Section 1 of RSVP Refresh Overhead Reduction
		      Extensions <xref target="RFC2961"/>.
      </t>
     </list>
     </t>
          target="RFC2961" sectionFormat="of" section="1"/>.</li>
	</ul>

        <t>The problems listed above adversely affect RSVP control plane
     scalability
        scalability, and RSVP-TE <xref target="RFC3209"/> inherited these
        problems from standard RSVP. Procedures specified in <xref
        target="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 timeout timeouts for stale state
        cleanup, refer to "Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling
     Techniques <xref target="RFC8370"/>. target="RFC8370" sectionFormat="of"
        section="3"/>.
        </t>

        <t>However, the facility backup protection procedures specified in
     <xref target="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"/>,
     eliminate this dependency on refresh timeouts for stale state cleanup.
     </t>

<!--[rfced] To clarify this document's relation to [RFC2961], may we
update this sentence as follows?

Original:
   Therefore, this document makes support for [RFC2961] a pre-requisite.

Perhaps:
   Therefore, [RFC2961] is a prerequisite for this document.
-->

        <t>The procedures specified in this document assume reliable delivery of
     RSVP messages, as specified in <xref target="RFC2961"/>. Therefore, this
     document makes support for <xref target="RFC2961"/> a pre-requisite. prerequisite.
        </t>
      </section>
    </section>

    <section anchor="terminology" title="Terminology">

     <t>The anchor="terminology">
      <name>Terminology</name>
	<t>
	  The reader is expected to be familiar with the terminology in <xref
	  target="RFC2205"/>, <xref target="RFC3209"/>, <xref
	  target="RFC4090"/>, <xref target="RFC4558"/>, <xref target="RFC8370"/>
	  target="RFC8370"/>, and <xref target="RFC8796"/>.
	</t>

     <t>Phop

<!-- [rfced] Please review the following questions and changes regarding
Section 2 ("Terminology").

a) The terminology list contains a mixture of both abbreviations and
definitions. For consistency and readability, may we separate definitions and
abbreviations into two different lists?

b) May we update some list items for a more accurate and 1:1 relationship
between an abbreviation and its expansion? Please see examples in the
"Perhaps" text below.

c) In addition, the format of some definition items may suggest that "router"
and "node" can be used interchangeably (see some examples below). Please
review and confirm if this is accurate. May we update the terms as suggested
below?

Originals:

   Phop node: Previous-hop router along the label switched path
     </t>

     <t>PPhop

   MP: Merge Point router as defined in [RFC4090]

   LP-MP node: Previous-Previous-hop Merge Point router at the tail of Link-Protecting bypass tunnel

Perhaps (a few examples):

   PHOP: Previous-Hop (can refer to a router or node along the label switched path
     </t>

     <t>Nhop node: Next-hop LSP)

   MP: Merge Point (can refer to a router as defined in [RFC4090])

   LP-MP: Link-Protecting Merge Point (can refer to a router or node at the
   tail of a Link-Protecting bypass tunnel)

d) FYI - We have added expansions for Path State Block (PSB) and Reservation
State Block (RSB) to this terminology list to avoid expanding them inside of
the definition of "LSP state". Please review and let us know if there are
additional abbreviations or terminology used in this document (such as LSP,
FRR, etc.) that you would like to add to this terminology list.

-->

      <dl>
	<dt>Phop node:</dt><dd>Previous-Hop router along the label switched path
     </t>

     <t>NNhop node: Next-Next-hop LSP</dd>
	<dt>PPhop node:</dt><dd>Previous-Previous-Hop router along the label switched path
     </t>

     <t>PLR: Point LSP</dd>
	<dt>Nhop node:</dt><dd>Next-Hop router along the LSP</dd>
	<dt>NNhop node:</dt><dd>Next-Next-Hop router along the LSP</dd>
	<dt>PLR:</dt><dd>Point of Local Repair router as defined in <xref target="RFC4090"/>
     </t>

     <t>MP: Merge target="RFC4090"/></dd>
	<dt>MP:</dt><dd>Merge Point router as defined in <xref target="RFC4090"/>
     </t>

     <t>LP-MP node: Merge target="RFC4090"/></dd>
	<dt>LP-MP node:</dt><dd>Merge Point router at the tail of Link-Protecting bypass tunnel
     </t>

     <t>NP-MP node: Merge tunnel</dd>
	<dt>NP-MP node:</dt><dd>Merge Point router at the tail of Node-Protecting bypass tunnel
     </t>

     <t>RRO: Record tunnel</dd>
        <dt>PSB:</dt><dd>Path State Block</dd>
        <dt>RSB:</dt><dd>Reservation State Block</dd>
	<dt>RRO:</dt><dd>Record Route Object as defined in <xref target="RFC3209"/>
     </t>

     <t>TED: Traffic target="RFC3209"/></dd>
	<dt>TED:</dt><dd>Traffic Engineering Database
     </t>

     <t>LSP state: The Database</dd>
	<dt>LSP state:</dt><dd>The combination of "path state" maintained as Path State Block
     (PSB) a
	PSB and "reservation state" maintained as Reservation State Block (RSB) an RSB forms an individual
	LSP state on an RSVP-TE speaker
     </t>

     <t>RI-RSVP: The speaker</dd>
	<dt>RI-RSVP:</dt><dd>The set of procedures defined in Section 3 of RSVP-TE Scaling
     Techniques <xref section="3" sectionFormat="of" target="RFC8370"/> to eliminate RSVP's reliance on periodic
	message refreshes
     </t>

     <t>B-SFRR-Ready: Bypass refreshes</dd>
	<dt>B-SFRR-Ready:</dt><dd>Bypass Summary FRR Ready Extended Association object as defined
	in Summary FRR extensions <xref target="RFC8796"/> and is added by the PLR
	for each protected LSP.
     </t>

     <t>RI-RSVP-FRR: The LSP</dd>
	<dt>RI-RSVP-FRR:</dt><dd>The set of procedures defined in this document to eliminate
	RSVP's reliance of on periodic message refreshes when supporting facility backup
	protection <xref target="RFC4090"/>
     </t>

     <t>Conditional PathTear: A target="RFC4090"/></dd>
	<dt>Conditional PathTear:</dt><dd>A PathTear message containing a suggestion to a
	receiving downstream router to retain the path state if the receiving router
	is an NP-MP
     </t>

     <t>Remote PathTear: A NP-MP</dd>
	<dt>Remote PathTear:</dt><dd>A PathTear message sent from a Point of Local Repair (PLR) PLR
	to the MP to delete the LSP state on the MP if the PLR had not previously sent the
	backup Path path state reliably reliably</dd>
      </dl>
      <section>
	<name>Requirements Language</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
    </section>

    <section anchor="prob_desc" title="Problem Description"> anchor="prob_desc">
      <name>Problem Description</name>
      <figure align="center" anchor="example_network" title="Example Topology"> anchor="example_network">
        <name>Example Topology</name>
        <artwork align="center"><![CDATA[
        E
      /   \
     /     \
    /       \
   /         \
  /           \
 /             \
A ----- B ----- C ----- D
        \             /
         \           /
          \         /
           \       /
            \     /
             \   /
               F
]]></artwork>
      </figure>

<!-- [rfced] How may we update "has been configured to be long of the order of
minutes" for clarity?

Original:
   Assume that refresh interval has been configured to be long of the order of
   minutes and refresh reduction extensions are enabled on all routers.

Perhaps:
   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>In the topology in <xref target="example_network"/>, consider a
	large number of LSPs from A to D transiting B and C. Assume that refresh
	interval has been configured to be long of the order of minutes and
	refresh reduction extensions are enabled on all routers.
      </t>

	<t>Also
      <t>In addition, assume that node protection has been configured for the LSPs
	and the LSPs are protected by each router in the following way

        <list style="hanging">
	 <t hangText="-">A way:
      </t>
      <ul>
	<li>A has made node protection available using bypass LSP A -> -&gt; E ->
	-&gt; C; A is the PLR and C is the NP-MP
	 </t>
        </list>
        <list style="hanging">
	 <t hangText="-">B NP-MP.</li>
	<li>B has made node protection available using bypass LSP B -> -&gt; F ->
	-&gt; D; B is the PLR and D is the NP-MP
	 </t>
        </list>
	<list style="hanging">
	 <t hangText="-">C NP-MP.</li>
	<li>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
	 </t>
        </list>
	</t>

	<t>In LP-MP.</li>
     </ul>

      <t>
	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.

        <list style="hanging">
 	 <t hangText="1.">B
      </t>

      <ol type="Step %d.">
        <li anchor="step1">B performs a local repair and re-directs redirects LSP traffic over the bypass
        LSP B -> -&gt; F -> D.
	 </t>
        </list>
        <list style="hanging">
 	 <t hangText="2.">B -&gt; D.</li>
	<li anchor="step2">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 -> D.
	 </t>
        </list>
	<list style="hanging">
	 <t hangText="3.">D -&gt; D.</li>
	<li anchor="step3">D receives the backup LSP states and merges the backups with the
	protected LSPs.
	 </t>
        </list>
	<list style="hanging">
 	 <t hangText="4.">As LSPs.</li>
        <li anchor="step4">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 tear down 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.
	 </t>
        </list>
	</t> timeout.</li>
      </ol>

      <t>While the above sequence of events has been described in <xref target="RFC4090"/>,
	there are a few problems for which no mechanism has been specified
	explicitly.

        <list style="hanging">
 	 <t hangText="-">If
	explicitly:
      </t>

      <ul>
        <li>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.
	 </t>
        </list>
        <list style="hanging">
	 <t hangText="-">If upon the link failure
        time.</li>

        <li>If C is to keep state until its
		         timeout, timeout upon the link failure,
        then with a long refresh interval interval, this may result in a large amount
        of stale state on C.  Alternatively, if upon the link failure C is to
        delete the state and send a PathTear to D, 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 or not to overcome this problem.
	 </t>
        </list>
	<list style="hanging">
	 <t hangText="-">If
        problem.</li>

	<li>If head-end A attempts to tear down the LSP after step 1 <xref target="step1"
	format="none">Step 1</xref> but before step 2 <xref target="step2"
	format="none">Step 2</xref> of the above sequence, then B may receive
	the tear down teardown message before step 2 <xref target="step2" format="none">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 interval, this
	could cause a (large) buildup of stale state on D.
	 </t>
        </list>
	<list style="hanging">
	 <t hangText="-">If D.</li>

        <li>If B fails to perform a local repair in step 1, <xref target="step1" format="none">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 interval, this
        could cause a (large) buildup of stale state on D.
	 </t>
        </list>
	</t> D.</li>
      </ul>

      <t>The purpose of this document is to provide solutions to the above
	problems
	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" title="Solution Aspects"> anchor="solution">
      <name>Solution Aspects</name>
      <t>The solution consists of five parts.

	<list style="hanging">
 	 <t hangText="-">Utilize parts:</t>
      <ol>
        <li>Utilize the MP determination mechanism specified in RSVP-TE Summary
        FRR <xref target="RFC8796"/> that enables the PLR to signal the
        availability of local protection to the MP. In addition, introduce PLR
        and MP procedures to establish Node-ID based hello session Node-ID-based Hello sessions between the
        PLR and the MP to detect router failures and to determine capability.
        See <xref target="sig_handshake"/> of this document for more
        details. This part of the solution
		 re-uses reuses some of the extensions
        defined in
		 RSVP-TE Summary FRR <xref target="RFC8796"/> and RSVP-TE Scaling Techniques <xref target="RFC8370"/>, and the subsequent sub-sections
        subsections will list the extensions in these
		 drafts documents that are
        utilized in this document.
	 </t>
        </list>
        <list style="hanging">
	 <t hangText="-">Handle document.</li>

        <li>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"/> of this document for more details.
	 </t>
        </list>
	<list style="hanging">
	 <t hangText="-">Introduce
        details.</li>

        <li>Introduce extensions to enable a router to send a tear
		 down teardown
        message to the downstream router that enables the receiving router to
        conditionally delete its local LSP state.  See <xref
        target="cnd_path_tear"/> of this document for more details.
	 </t>
        </list>
	<list style="hanging">
	 <t hangText="-">Enhance details.</li>

        <li>Enhance facility backup protection by allowing a PLR to directly
        send a tear down 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"/> of this document for more details.
	 </t>
        </list>
        <list style="hanging">
	 <t hangText="-">Introduce
        details.</li>

        <li>Introduce extensions to enable the above procedures to be backward
        compatible with routers along the LSP path running implementation implementations that
        do not support these procedures.  See <xref target="compatible"/> of
        this document for more details.
	 </t>
        </list>
     </t>

    <section anchor="adv_capability" title="Requirement details.</li>
      </ol>

<!-- [rfced] How may we update this section title to avoid using an RFC number
as an adjective?

Original:

     4.1.  Requirement on RFC 4090 Capable Node to advertise RI-RSVP Capability"> Capability

Perhaps (remove RFC number):

     4.1.  Requirement for Capable Nodes to Advertise the RI-RSVP Capability

Perhaps (keep RFC number):

     4.1.  Requirement for Capable Nodes from RFC 4090 to Advertise the
     RI-RSVP Capability
-->

      <section anchor="adv_capability">
        <name>Requirement on RFC 4090 Capable Node to Advertise the RI-RSVP Capability</name>
        <t>A node supporting facility backup protection <xref
        target="RFC4090"/>
	  MUST NOT <bcp14>MUST NOT</bcp14> set the RI-RSVP flag (I bit) (I-bit) that is defined in Section 3.1 of
	  RSVP-TE Scaling Techniques <xref target="RFC8370"/> target="RFC8370"
        sectionFormat="of" section="3.1"/> unless it supports all the extensions
        specified in the rest of this document.  Hence, this document updates
        <xref target="RFC4090"/> by defining extensions and additional
        procedures over facility backup protection <xref target="RFC4090"/> in
        order to advertise the RI-RSVP capability <xref
        target="RFC8370"/>. However, if a node supporting facility backup
        protection <xref target="RFC4090"/> does set the RI-RSVP capability (I bit) (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"/>.  This
        can also disrupt normal Fast Reroute (FRR) operation. operations.  <xref
        target="cap_bit_without_support"/> of this document delves on into this in
        detail.
        </t>
      </section>
      <section anchor="sig_handshake" title="Signaling anchor="sig_handshake">
        <name>Signaling Handshake between Between PLR and MP"> MP</name>
        <section anchor="sig_plr_behavior" title="PLR Behavior"> anchor="sig_plr_behavior">
          <name>PLR Behavior</name>
          <t>As per the facility backup procedures <xref target="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.

	 <list style="hanging">
	  <t hangText="-">If
          </t>
	  <ul>
            <li>If the "node protection desired" flag is set, then the node
            tries to become a PLR by attempting to create a an NP-bypass LSP to
            the NNhop node avoiding the Nhop node on a protected LSP path. 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
	  </t>
         </list>
	 <list style="hanging">
	  <t hangText="-">If Nhop.</li>
            <li>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
	  </t>
         </list>
	 </t> Nhop.</li>
	  </ul>

          <t>With regard to the PLR procedures described above and that are specified
          in <xref target="RFC4090"/>, this document specifies the following
          additional procedures to support RI-RSVP <xref target="RFC8370"/>.

	 <list style="hanging">
	  <t hangText="-">While
          target="RFC8370"/>.</t>

	  <ul>
            <li>While selecting the destination address of the bypass LSP, the
            PLR MUST <bcp14>MUST</bcp14> select the router ID of the NNhop or Nhop
            node from the Node-ID sub-object included in the RRO object 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 object. If the
            NP-MP in a different IGP area has not included a Node-ID
            sub-object in the RRO object, then the PLR MUST <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"/>).
	  </t>
         </list>
	 <list style="hanging">
	  <t hangText="-">The target="dnstr_no_support"/>).</li>

<!-- [rfced] Can the second sentence in the text below be made more concise,
as it mostly contains repeated information from the previous sentence?

Original:

   -  The PLR MUST also include its router ID in a Node-ID sub-object in
      RRO object carried in any subsequent Path message corresponding to
      the LSP.  While including its router ID in the Node-ID sub-object
      carried in the outgoing Path message, the PLR MUST include the
      Node-ID sub-object after including its IPv4/IPv6 address or
      unnumbered interface ID sub-object.
	  </t>
         </list>
	 <list style="hanging">
	  <t hangText="-">In

Perhaps:

   *  The PLR MUST also include its router ID in a Node-ID sub-object in
      the RRO object that is carried in any subsequent Path message
      corresponding to the LSP.  While doing so, the PLR
      MUST include the Node-ID sub-object after including its IPv4/IPv6
      address or unnumbered interface ID sub-object.
-->

            <li>The PLR <bcp14>MUST</bcp14> also include its router ID in a
            Node-ID sub-object in the RRO object that is carried in any subsequent Path
            message corresponding to the LSP. While including its router ID in
            the Node-ID sub-object carried in the outgoing Path message, the
            PLR <bcp14>MUST</bcp14> include the Node-ID sub-object after
            including its IPv4/IPv6 address or unnumbered interface ID
            sub-object.</li>

<!-- [rfced] May we update the text below to improve readability? In particular,
how may we clarify what the MP "sets" the I-bit to?

Original:

      If the MP has set the I-bit in the CAPABILITY object [RFC8370] carried
      in Hello message corresponding to the Node-ID based Hello session, then
      the PLR MUST conclude that the MP supports refresh- interval independent
      FRR procedures defined in this document.

Perhaps:

      The PLR MUST 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
      [RFC8370] (carried in the Hello message) to correspond with the Node-
      ID-based Hello session.
-->

<li>In parallel to the attempt made to create an NP-bypass or an
            LP-bypass, the PLR MUST <bcp14>MUST</bcp14> initiate a Node-ID based 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. If the MP has set the I-bit in the
            CAPABILITY object <xref target="RFC8370"/> carried in the Hello
            message corresponding to the Node-ID based Node-ID-based Hello session, then the
            PLR
		  MUST <bcp14>MUST</bcp14> conclude that the MP supports
            refresh-interval independent FRR procedures defined in this
            document. If the MP has not sent Node-ID based Node-ID-based Hello messages or
            has not set the I-bit in the CAPABILITY object <xref
            target="RFC8370"/>, then the PLR MUST <bcp14>MUST</bcp14> execute
            backward compatibility procedures defined in <xref
            target="dnstr_no_support"/> of this document.
	  </t>
         </list>
	 <list style="hanging">
	  <t hangText="-">When document.</li>
            <li>When the PLR associates a bypass to a protected LSP, it
		  MUST
            <bcp14>MUST</bcp14> include a B-SFRR-Ready Extended Association
            object <xref target="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"/> MUST <bcp14>MUST</bcp14> be followed. In
            addition to those rules, the PLR MUST <bcp14>MUST</bcp14> set the
            Association Source in the object to its Node-ID address.
	  </t>
         </list>
	 </t> address.</li>
	  </ul>
        </section>
        <section anchor="sig_rem_adjacency" title="Remote anchor="sig_rem_adjacency">
          <name>Remote Signaling Adjacency"> Adjacency</name>
          <t>A Node-ID based 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"/>. This document extends Node-ID based Node-ID-based
	   RSVP Hello session 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
	   Node-ID-based RSVP-TE Hello session sessions between any two routers that are
	   not immediate neighbors, the router that supports the extensions
	   defined in the document MUST <bcp14>MUST</bcp14> set the TTL to 255 in all outgoing
	   Node-ID based
	   Node-ID-based Hello messages exchanged between the PLR and the MP. The
	   default hello interval for this Node-ID hello Hello session MUST <bcp14>MUST</bcp14> be set
	   to the default specified in RSVP-TE Scaling Techniques
	   <xref target="RFC8370"/>.
          </t>
          <t>In the rest of the document document, the term &quot;signaling adjacency&quot;,
	    or &quot;remote terms "signaling adjacency"
	    and "remote signaling adjacency&quot; refers adjacency" refer specifically to the
	    RSVP-TE signaling adjacency.
          </t>
        </section>
        <section anchor="sig_mp_behavior" title="MP Behavior"> anchor="sig_mp_behavior">
          <name>MP Behavior</name>
          <t>With regard to the MP procedures that are defined in
	   <xref target="RFC4090"/> target="RFC4090"/>, this document specifies the following
	   additional procedures to support RI-RSVP as defined in
	   <xref target="RFC8370"/>.
          </t>
          <t>Each node along an LSP path supporting the extensions defined in
	   this document MUST <bcp14>MUST</bcp14> also include its router ID in the Node-ID
	   sub-object of the RRO object 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 object that is carried in the Path message and if the PLR is in
	   a different IGP area, then the router MUST NOT <bcp14>MUST NOT</bcp14> execute the MP
	   procedures specified in this document for those LSPs. Instead, the
	   node MUST <bcp14>MUST</bcp14> execute backward compatibility procedures defined in
	   <xref target="upstr_no_support"/> of this document as if the upstream nodes along
	   the LSP do not support the extensions defined in this document.
          </t>

<!-- [rfced] FYI - There are a number of instances throughout the document where
we have updated text to be formatted as a bulleted list to improve readability.
Please review these instances and let us know of any objections.
-->

          <t>A node receiving a Path message should determine whether determine:</t>
	  <ul>
	   <li>whether the message contains a B-SFRR-Ready Extended
	   Association object with its own address as the bypass destination
	   address and whether and</li>
	   <li>whether it has an operational Node-ID signaling adjacency with
	   the Association
	   source. If source.</li>
	   </ul>

<t>The node <bcp14>MUST</bcp14> execute the
	   backward compatibility procedures defined in
<xref target="upstr_no_support"/> of this document if:</t>
<ul>
<li>the PLR has not included the B-SFRR-Ready Extended
Association object or if there object,</li>
<li>there is no operational Node-ID signaling
	   adjacency with the PLR identified by the Association source address
	   or if the address, or</li>
	   <li>the PLR has not advertised the RI-RSVP capability in its
	   Node-ID based
	   Node-ID-based Hello messages, then the node MUST execute the
	   backward compatibility procedures defined in
	   <xref target="upstr_no_support"/> of this document.
        </t> messages.</li>
          </ul>
          <t>If a matching B-SFRR-Ready Extended Association object is found
          in
	   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"/>, then the node MUST <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"/> MUST <bcp14>MUST</bcp14> be followed by the
          implementations supporting this document.

	 <list style="hanging">
	  <t hangText="-">If
          </t>
	  <ul>
	    <li>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 MUST <bcp14>MUST</bcp14> conclude it is the NP-MP.
	  </t>
         </list>
	 <list style="hanging">
	  <t hangText="-">If NP-MP.</li>
            <li>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 MUST <bcp14>MUST</bcp14> conclude it is the LP-MP.
	  </t>
         </list>
	 </t> LP-MP.</li>
	  </ul>
        </section>

        <section anchor="sig_rem_state" title="&quot;Remote&quot; anchor="sig_rem_state">
          <name>"Remote" State on MP"> MP</name>
          <t>Once a router concludes it is the MP for a PLR running
          refresh-interval independent FRR procedures as described in the
          preceding section, it MUST <bcp14>MUST</bcp14> create a remote path state
          for the LSP.  The only difference between the &quot;remote&quot; "remote" path state
          and the LSP state is the RSVP_HOP object. The RSVP_HOP object in a
	    &quot;remote&quot;
          "remote" path state contains the address that the PLR uses to send
          Node-ID hello Hello messages to the MP.
          </t>
          <t>The MP MUST <bcp14>MUST</bcp14> consider the &quot;remote&quot; "remote" path state corresponding
	    to the LSP automatically deleted if:

	 <list style="hanging">
	  <t hangText="-">The
          </t>
	  <ul>
	    <li>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, or
	  </t>
         </list>
	 <list style="hanging">
	  <t hangText="-">The RRO,</li>
            <li>the Node-ID signaling adjacency with the PLR goes down, or
	  </t>
	 </list>
	 <list style="hanging">
	  <t hangText="-">The down,</li>
            <li>the MP receives backup LSP signaling for the LSP from the PLR or
	  </t>
	 </list>
	 <list style="hanging">
	  <t hangText="-">The PLR,</li>
            <li>the MP receives a PathTear for the LSP, or
	  </t>
	 </list>
	 <list style="hanging">
	  <t hangText="-">The or</li>
            <li>the MP deletes the LSP state on a local policy or an exception event
	  </t>
	 </list>
	 </t> event.</li>
          </ul>
          <t>The purpose of &quot;remote&quot; "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 &quot;remote&quot; "remote" path
	    state. Such a message tearing down &quot;remote&quot; the "remote" path state is
	    called &quot;Remote&quot; "Remote" PathTear.
          </t>
          <t>The scenarios in which a &quot;Remote&quot; "Remote" PathTear is applied are
	    described in <xref target="rem_tear"/> of this document.
          </t>
        </section>
      </section>
      <section anchor="failures" title="Impact anchor="failures">
        <name>Impact of Failures on LSP State"> State</name>
        <t>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"/>,
	  <xref target="RFC5063"/>). target="RFC3473"/> <xref target="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>Node failures are detected from the state of Node-ID hello Hello
	  sessions established with immediate neighbors. RSVP-TE Scaling
	  Techniques <xref target="RFC8370"/> recommends that each node
	  establish Node-ID hello Hello sessions with all its immediate neighbors.
	  Non-immediate
	  A non-immediate PLR or MP failure is detected from the state of remote
	  signaling adjacency established according to
	  <xref target="sig_rem_adjacency"/> of this document.
        </t>
        <section anchor="failures_nonmp" title="Non-MP Behavior"> anchor="failures_nonmp">
          <name>Non-MP Behavior</name>
          <t>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 MUST <bcp14>MUST</bcp14> send a Conditional
	   PathTear (refer to <xref target="cnd_path_tear"/> of this document)
	   and delete the PSB and RSB states corresponding to
	   the LSP.
          </t>
        </section>
        <section anchor="failures_lpmp" title="LP-MP Behavior"> anchor="failures_lpmp">
          <name>LP-MP Behavior</name>
          <t>When the Phop link for an LSP fails on a router that is an LP-MP for
	   the LSP, the LP-MP MUST <bcp14>MUST</bcp14> retain the PSB and RSB states corresponding
	   to the LSP till until the occurrence of any of the following events.

	<list style="hanging">
	 <t hangText="-">The events:
          </t>
          <ul>
            <li>the Node-ID signaling adjacency with the Phop PLR goes down, or
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">The down,</li>
            <li>the MP receives a normal or &quot;Remote&quot; "Remote" PathTear for its PSB, or
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">The or</li>
            <li>the MP receives a ResvTear for its RSB.
	 </t>
	</list>
	</t> RSB.</li>
	  </ul>
          <t>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 MUST <bcp14>MUST</bcp14> send a normal
	   PathTear and delete the PSB and RSB states corresponding to the LSP.
          </t>
        </section>

        <section anchor="failures_npmp" title="NP-MP Behavior"> anchor="failures_npmp">
          <name>NP-MP Behavior</name>
          <t>When a router that is an NP-MP for an LSP detects Phop link failure, failure
	   or Phop node failure from the Node-ID signaling adjacency, the router
	   MUST
	   <bcp14>MUST</bcp14> retain the PSB and RSB states corresponding to the LSP till until the
	   occurrence of any of the following events.

	<list style="hanging">
	 <t hangText="-">The events:
          </t>
	  <ul>
            <li>the remote Node-ID signaling adjacency with the PPhop PLR goes down, or
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">The down,</li>
            <li>the MP receives a normal or &quot;Remote&quot; "Remote" PathTear for its PSB, or
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">The or</li>
            <li>the MP receives a ResvTear for its RSB.
	 </t>
	</list>
	</t> RSB.</li>
          </ul>
          <t>When a router that is an NP-MP for an LSP did does not detect the Phop
          link or the Phop node failure, failure but receives a Conditional PathTear
          from the Phop node, then the router MUST <bcp14>MUST</bcp14> retain the
          PSB and RSB states corresponding to the LSP till until the occurrence of
          any of the following events.

	<list style="hanging">
	 <t hangText="-">The events:
          </t>
	  <ul>
            <li>the remote Node-ID signaling adjacency with the PPhop PLR goes down, or
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">The down,</li>
            <li>the MP receives a normal or &quot;Remote&quot; "Remote" PathTear for its PSB, or
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">The or</li>
            <li>the MP receives a ResvTear for its RSB.
	 </t>
	</list>
	</t> RSB.</li>
          </ul>
          <t>Receiving a Conditional PathTear from the Phop node will not
          impact the &quot;remote&quot; "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"/> of this document).
          </t>
<!-- [rfced] FYI - We have updated the text as follows to improve readability.
Please let us know of any objections or if any further updates are needed.

Original:

   Now when A-B link fails, as B is not an
   MP and its Phop link has failed, B will delete the LSP state (this
   behavior is required for unprotected LSPs - refer to Section 4.3.1 of
   this document).

Current:

   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 Section 4.3.1 of this document).

-->

          <t>In the example topology in <xref target="example_network"/>, we assume
	   C &amp; and D are the NP-MPs for the PLRs A &amp; B and B, respectively. Now Now, when the
	   A-B link fails, as B will delete the LSP state, because B is not an MP and its Phop link has failed, B will
	   delete the LSP state failed (this behavior is required for unprotected LSPs - LSPs;
	   refer to <xref target="failures_nonmp"/> of this document). In the data
	   plane, that would require B to delete the label forwarding entry
	   corresponding to the LSP. So 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>The mechanism that enables D to stop considering itself as the
	   NP-MP for B and delete the corresponding &quot;remote&quot; "remote" path
	   state is given below.

	<list style="hanging">
	 <t hangText="1.">When
          </t>
	  <ol>
            <li>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 trigger triggers a Path to D.
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="2.">When
            D.</li>
            <li>When D receives the Path message, it realizes that it is no
            longer the NP-MP for B and so it deletes the corresponding &quot;remote&quot;
            "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.
	 </t>
	</list>
	</t> message.</li>
	  </ol>
        </section>

        <section anchor="failures_lpnpmp" title="Behavior anchor="failures_lpnpmp">
          <name>Behavior of a Router that is both That Is Both the LP-MP and NP-MP"> NP-MP</name>
          <t>A router may simultaneously be the LP-MP as well as and the NP-MP for the
          Phop and the PPhop nodes respectively of an LSP. LSP, respectively. If the Phop link
          fails on such a node, the node MUST <bcp14>MUST</bcp14> retain the PSB
          and RSB states corresponding to the LSP till until the occurrence of any
          of the following events.

	<list style="hanging">
	 <t hangText="-">Both events:
          </t>
          <ul>
            <li>both Node-ID signaling adjacencies with Phop and PPhop nodes go down, or
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">The down,</li>
            <li>the MP receives a normal or &quot;Remote&quot; "Remote" PathTear for its PSB, or
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">The or</li>
            <li>the MP receives a ResvTear for its RSB.
	 </t>
	</list>
	</t> RSB.</li>
	  </ul>
          <t>If a router that is both an LP-MP and an NP-MP detects Phop node
	   failure, then the node MUST <bcp14>MUST</bcp14> retain the PSB and RSB states corresponding
	   to the LSP till until the occurrence of any of the following events.

	<list style="hanging">
	 <t hangText="-">The events:
          </t>
	  <ul>
            <li>the remote Node-ID signaling adjacency with the PPhop PLR goes down, or
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">The down,</li>
            <li>the MP receives a normal or &quot;Remote&quot; "Remote" PathTear for its PSB, or
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">The or</li>
            <li>the MP receives a ResvTear for its RSB.
	 </t>
	</list>
	</t> RSB.</li>
	  </ul>
        </section>
      </section>

      <section anchor="cnd_path_tear" title="Conditional PathTear"> anchor="cnd_path_tear">
        <name>Conditional PathTear</name>
        <t>In the example provided in <xref target="failures_npmp"/> of this
        document, B deletes the PSB and RSB states corresponding to the LSP
        once B detects its Phop link that went 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 MUST
        <bcp14>MUST</bcp14> add a new optional CONDITIONS object in the
        PathTear. The CONDITIONS object is defined in <xref
        target="cnd_path_tear_obj"/> of this document. If node C also
        understands the new object, then C MUST NOT <bcp14>MUST NOT</bcp14> delete the
        LSP state if it is an NP-MP.
        </t>

        <section anchor="cnd_path_tear_send" title="Sending anchor="cnd_path_tear_send">
          <name>Sending the Conditional PathTear"> PathTear</name>
          <t>A router that is not an MP for an LSP MUST <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"/> of this document).
	   The router MUST <bcp14>MUST</bcp14> send a Conditional PathTear if the following are also
	   true.

	<list style="hanging">
	 <t hangText="-">The
	   true:
          </t>
          <ul>
            <li>the ingress has requested node protection for the LSP, and
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="-">No LSP and</li>
            <li>no PathTear is received from the upstream node
	 </t>
	</list>
	</t> node.</li>
	  </ul>
        </section>

        <section anchor="cnd_path_tear_recv" title="Processing anchor="cnd_path_tear_recv">
          <name>Processing the Conditional PathTear"> PathTear</name>
          <t>When a router that is not an NP-MP receives a Conditional PathTear,
	   the node MUST <bcp14>MUST</bcp14> delete the PSB and RSB states corresponding to the LSP, LSP
	   and process the Conditional PathTear by considering it as a normal
	   PathTear. Specifically, the node MUST NOT <bcp14>MUST NOT</bcp14> propagate the Conditional
	   PathTear downstream but remove the optional object and send a normal
	   PathTear downstream.
          </t>
          <t>When a node that is an NP-MP receives a Conditional PathTear, it
	   MUST NOT
	   <bcp14>MUST NOT</bcp14> delete the LSP state. The node MUST <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
	   MUST
	   <bcp14>MUST</bcp14> remove the corresponding object and trigger a Path downstream.
          </t>
          <t>If a Conditional PathTear is received from a neighbor that has not
	   advertised support (refer to <xref target="compatible"/> of this document) for the
	   new procedures defined in this document, then the node MUST <bcp14>MUST</bcp14>
	   consider the message as a normal PathTear. The node MUST <bcp14>MUST</bcp14> propagate
	   the normal PathTear downstream and delete the LSP state.
          </t>
        </section>
        <section anchor="cnd_path_tear_obj" title="CONDITIONS Object"> anchor="cnd_path_tear_obj">
          <name>CONDITIONS Object</name>
          <t>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 10bbbbbb, where 'b' "b" represents a bit.
	   (The behavior for objects of this type is specified in Section 3.10 of <xref target="RFC2205"/>). target="RFC2205" sectionFormat="of" section="3.10"/>.)
          </t>
          <t>The new object is called as &quot;CONDITIONS&quot; the "CONDITIONS" object that and will
	   specify the conditions under which default processing rules of the
	   RSVP-TE message MUST <bcp14>MUST</bcp14> be invoked.
          </t>
          <t>The object has the following format: format:</t>
          <figure align="left" anchor="fig_conditions" title="CONDITIONS Object">
            <artwork>
              <![CDATA[ anchor="fig_conditions">
            <name>CONDITIONS Object</name>
            <artwork align="left"><![CDATA[
    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>
]]></artwork>
          </figure>

	<?rfc subcompact="yes" ?>
	<list style="none">
	   <t>Class: TBA1<br></br>
	      C-type: 1<br></br>

<!-- [rfced] As all other fields are defined following Figure 2, should
the Length field also have an entry?

Current:
       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 is a (Reserved)                           |M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 2: CONDITIONS Object

   Class:  135
   C-type:  1
   Flags:  32 bit field. field
   M:  Bit 31 is the Merge-point condition (M) bit: bit.  If the M bit is set
      to 1, then the PathTear message MUST be processed according to the
      receiver router role, i.e. i.e., if the receiving router is an MP or
      not for the LSP.  If it is not set, then the PathTear message MUST
      be processed as a normal PathTear message for the LSP.<br></br>
	      Bits LSP.

-->

  <dl spacing="compact" newline="false">
	      <dt>Class:</dt> <dd>135</dd>
	      <dt>C-type:</dt> <dd>1</dd>
	      <dt>Flags:</dt> <dd>32 bit field</dd>
	      <dt>M:</dt> <dd>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>Bits 0-30 are reserved, reserved; they MUST <bcp14>MUST</bcp14> be set to zero on transmission and
	      MUST
	      <bcp14>MUST</bcp14> be ignored on receipt.<br></br>
           </t>
        </list>
	</t> receipt.</t>
        </section>
      </section>

      <section anchor="rem_tear" title="Remote anchor="rem_tear">
        <name>Remote State Teardown"> Teardown</name>
        <t>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 till until the completion of backup LSP
	   signaling to perform state cleanup. In this case, the PLR MUST <bcp14>MUST</bcp14> send a
	   &quot;Remote&quot;
	   "Remote" PathTear message instructing the MP to delete the PSB
	   and RSB states corresponding to the LSP. The TTL in the &quot;Remote&quot; "Remote"
	   PathTear message MUST <bcp14>MUST</bcp14> be set to 255. Doing this enables LSP state cleanup
           when the LSP is being locally repaired.
        </t>
        <t>Consider that node C in the example topology
	   (<xref target="example_network"/>) has gone down and node B locally
	   repairs the LSP.
	<list style="hanging">
	 <t hangText="1.">Ingress LSP:
        </t>
	<ol>
	  <li>Ingress A receives a management event to tear down the LSP.
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="2.">A LSP.</li>
	  <li>A sends a normal PathTear for the LSP to B.
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="3.">Assume B.</li>
	  <li>Assume B has not initiated the backup signaling for the
	  LSP during local repair. To enable LSP state cleanup, B sends a
		 &quot;Remote&quot;
	  "Remote" PathTear with the destination IP address set to
	  that of the node D used in the Node-ID signaling adjacency with D, D
	  and the RSVP_HOP object containing the local address used in the
	  Node-ID signaling adjacency.
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="4.">B adjacency.</li>
	  <li>B then deletes the PSB and RSB states corresponding to the LSP.
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="5.">On D LSP.</li>
	  <li>On D, there would be a remote signaling adjacency with
		 B
	  B, and so D accepts the &quot;Remote&quot; "Remote" PathTear and delete deletes the
	  PSB and RSB states corresponding to the LSP.
	 </t>
	</list>
	</t> LSP.</li>
        </ol>

        <section anchor="lcl_repair_fail" title="PLR anchor="lcl_repair_fail">
          <name>PLR Behavior on Local Repair Failure"> Failure</name>
          <t>If local repair fails on the PLR after a failure, the PLR MUST <bcp14>MUST</bcp14> send a
	   &quot;Remote&quot;
	   "Remote" PathTear to the MP. The purpose of this is to clean
	   up LSP state from the PLR to the Egress. egress. Upon receiving the PathTear,
	   the MP MUST <bcp14>MUST</bcp14> delete the states corresponding to the LSP and also
	   propagate the PathTear downstream downstream, thereby achieving state cleanup from
	   all downstream nodes up to the LSP egress. Note that in the case of link
	   protection, the PathTear MUST <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" title="PLR anchor="resv_rro_chng">
          <name>PLR Behavior on Resv RRO Change"> Change</name>
          <t>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 MUST <bcp14>MUST</bcp14> send a &quot;Remote&quot; "Remote" PathTear
	   directly to its former NP-MP.
          </t>
          <t>In the example topology in <xref target="example_network"/>, 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 fails, then C, implementing the
	   procedure specified in <xref target="failures_lpnpmp"/> of this
	   document, will retain the states corresponding to the LSP until: until one of the following occurs:</t>
	   <ul>
	     <li>the remote Node-ID signaling adjacency with A goes down, or a down
	     or</li>
	     <li>a PathTear or a ResvTear is received for its PSB or RSB respectively. If RSB,
	     respectively.</li>
	   </ul>
	   <t>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 - C, its former NP-MP, A A, sends a &quot;Remote&quot; "Remote"
	   PathTear to C. When C receives the &quot;Remote&quot; "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" title="LSP anchor="lcl_repair_preempt">
          <name>LSP Preemption during During Local Repair"> Repair</name>
          <section anchor="lcl_repair_preempt_lpnp" title="Preemption anchor="lcl_repair_preempt_lpnp">
            <name>Preemption on LP-MP after After Phop Link Failure"> Failure</name>
            <t>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 MUST <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 any
	   more anymore, requiring the node to clean up the LSP state.
            </t>
          </section>

          <section anchor="lcl_repair_preempt_npmp" title="Preemption anchor="lcl_repair_preempt_npmp">
            <name>Preemption on NP-MP after After Phop Link Failure"> Failure</name>
            <t>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
	   MUST
	   <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 any more anymore,
	   requiring the node to clean up LSP state.
            </t>
	    <t>Consider that the B-C link goes down on the same example topology
	   (<xref target="example_network"/>). As C is the NP-MP for the PLR A, C
	   will retain the LSP state.
	<list style="hanging">
	 <t hangText="1.">The
            </t>

<!-- [rfced] May we provide additional context or lead-in text for the
list below?

Original:

   Consider that B-C link goes down on the same example topology
   (Figure 1).  As C is the NP-MP for the PLR A, C will retain LSP
   state.

   1.  The LSP is preempted on C.
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="2.">C

   2.  C will delete the RSB state...

Perhaps:

   Consider that the B-C link goes down on the same example topology
   (Figure 1).  As C is the NP-MP for the PLR A, C will retain LSP
   state. This means:

   1.  The LSP is preempted on C.

   2.  C will delete the RSB state...

-->

	    <ol>
              <li>The LSP is preempted on C.</li>
              <li>C will delete the RSB state corresponding to the
              LSP.
		 But However, C cannot send a PathErr or a ResvTear to the PLR A
              because the backup LSP has not been signaled yet.
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="3.">As yet.</li>
              <li>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 delete also deletes its PSB state also. state. D would also delete the PSB
              and RSB states on receiving a PathTear from C.
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="4.">B C.</li>
              <li>B starts backup LSP signaling to D. But However, as D does not have
              the LSP state, it will reject the backup LSP Path and send a
              PathErr to B.
	 </t>
	</list>
	<list style="hanging">
	 <t hangText="5.">B B.</li>
              <li>B will delete its reservation and send a ResvTear to A.
	 </t>
	</list>
	</t> A.</li>
	    </ol>
          </section>
        </section>
      </section>

      <section anchor="compatible" title="Backward anchor="compatible">
        <name>Backward Compatibility Procedures">
     <t>&quot;Refresh interval Procedures</name>
        <t>"Refresh-Interval Independent FRR&quot; or RI-RSVP-FRR refers FRR" and "RI-RSVP-FRR" refer to the
	set of procedures defined in this document to eliminate the reliance of on
	periodic refreshes. The extensions proposed in RSVP-TE Summary FRR
	<xref target="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 cleanup, namely Conditional and &quot;Remote&quot; PathTear "Remote" PathTears, require
	support from one-hop and two-hop neighboring nodes along the LSP path.
	So
	Thus, procedures that fall under the LSP state cleanup category MUST NOT <bcp14>MUST NOT</bcp14> be
	turned on if any of the nodes involved in the node protection FRR i.e. (i.e.,
	the PLR, the MP MP, and the intermediate node in the case of NP, does NP) do not
	support RI-RSVP-FRR extensions. Note that for LSPs requesting link
	protection, only the PLR and the LP-MP MUST <bcp14>MUST</bcp14> support the extensions.
        </t>
<!-- [rfced] To reflect usage in RFC 8370, may we update 'the flag
"Refresh interval Independent RSVP" or RI-RSVP flag' below as follows?

Original:

   An implementation supporting RI-RSVP-FRR extensions MUST set the flag
   "Refresh interval Independent RSVP" or RI-RSVP flag in the CAPABILITY
   object carried in Hello messages as specified in RSVP-TE Scaling
   Techniques [RFC8370].

Perhaps:

   An implementation supporting RI-RSVP-FRR extensions MUST set the RI-RSVP
   Capable flag in the CAPABILITY object carried in Hello messages as
   specified in RSVP-TE Scaling Techniques [RFC8370].
-->

<section anchor="compat_detect" title="Detecting anchor="compat_detect">
          <name>Detecting Support for Refresh interval Refresh-Interval Independent FRR"> FRR</name>
          <t>An implementation supporting RI-RSVP-FRR extensions MUST <bcp14>MUST</bcp14> set the flag
	 &quot;Refresh
	 "Refresh interval Independent RSVP&quot; RSVP" or RI-RSVP flag in the
	 CAPABILITY object carried in Hello messages as specified in RSVP-TE
	 Scaling Techniques <xref target="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.
      <list style="hanging">
       <t hangText="-">As
          </t>
          <ul>
	    <li>As nodes supporting the RI-RSVP-FRR extensions initiate
	       Node-ID based
	    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.
       </t>
      </list>
      <list style="hanging">
       <t hangText="-">As enhancements.</li>

            <li>As nodes supporting the RI-RSVP-FRR extensions also initiate
	       Node-ID based
            Node-ID-based signaling adjacency with the NNhop along the path of
            the LSP requested requesting node protection (see <xref
            target="sig_plr_behavior"/> of this document), each node along the
            LSP path 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.
       </t>
      </list>
      <list style="hanging">
       <t hangText="-">If extensions.</li>

            <li>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 or messages, (b) the PPhop node has
            not initiated remote Node-ID Hello messages 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 MUST <bcp14>MUST</bcp14>
            conclude that the PLR does not support RI-RSVP-FRR extensions.
       </t>
      </list>
      </t>
            extensions.</li>
	  </ul>
        </section>

        <section anchor="compat_procedures" title="Procedures anchor="compat_procedures">
          <name>Procedures for Backward Compatibility"> Compatibility</name>

          <t>Every node that supports RI-RSVP-FRR MUST <bcp14>MUST</bcp14> support the procedures defined
	 in this section in order to support backward compatibility for
	 those subset subsets of LSPs that also traverse nodes that do not support
	 RI-RSVP-FRR.
          </t>

          <section anchor="dnstr_no_support" title="Lack anchor="dnstr_no_support">
            <name>Lack of support Support on Downstream Node"> Nodes</name>

            <t>The procedures on the downstream direction are as follows.
       <list style="hanging">
	<t hangText="-">If follows:</t>
	    <ul>
              <li>If a node finds that the Nhop node along the LSP does not
              support the RI-RSVP-FRR extensions, then the node MUST
              <bcp14>MUST</bcp14> reduce the &quot;refresh period&quot; "refresh period" in the
              TIME_VALUES object carried in the Path messages to the default
              short refresh interval.
	</t>
       </list>
       <list style="hanging">
	<t hangText="-">If interval.</li>
              <li>If node protection is requested for the LSP and the NNhop
              node along the LSP path does not support the RI-RSVP-FRR
              extensions, then the node MUST <bcp14>MUST</bcp14> reduce the &quot;refresh period&quot;
              "refresh period" in the TIME_VALUES object carried in the Path
              messages to the default short refresh interval.
	</t>
       </list>
       </t> interval.</li>
	    </ul>

            <t>If a node reduces the refresh time using the above procedures,
            it
	  MUST NOT <bcp14>MUST NOT</bcp14> send any &quot;Remote&quot; "Remote" PathTear or
            Conditional PathTear message to the downstream node.
       </t> node.</t>

            <t>Consider the example topology in <xref
            target="example_network"/>.  If C does not support the RI-RSVP-FRR
            extensions, then:
       <list style="hanging">
	<t hangText="-">A then:</t>

            <ul>
                <li>A and B reduce the refresh time to the default short
                refresh interval of 30 seconds and trigger a Path message
	</t>
       </list>
       <list style="hanging">
	<t hangText="-">If message.</li>

		<li>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 normally only
		if A did not set the long refresh in the TIME_VALUES
		object carried in the Path messages sent earlier.
	</t>
       </list>
       </t> earlier.</li>
	    </ul>
          </section>

          <section anchor="upstr_no_support" title="Lack anchor="upstr_no_support">
            <name>Lack of support Support on Upstream Node">
       <t>The Nodes</name>

<!-- [rfced] FYI - We have updated the following text to match similar
introductory text from the previous section.

Original:

   The procedures are as follows.
       <list style="hanging">
	<t hangText="-">If

Current:

   The procedures on the upstream direction are as follows:

-->

            <t>The procedures on the upstream direction are as follows:</t>

            <ul>
	      <li>If a node finds that the Phop node along the LSP path does
	      not support the RI-RSVP-FRR extensions, then the node MUST
	      <bcp14>MUST</bcp14> reduce the &quot;refresh period&quot; "refresh period" in the
	      TIME_VALUES object carried in the Resv messages to the default
	      short refresh interval.
	</t>
       </list>
       <list style="hanging">
	<t hangText="-">If interval.</li>

              <li>If node protection is requested for the LSP and the Phop
              node along the LSP path does not support the RI-RSVP-FRR
              extensions, then the node MUST <bcp14>MUST</bcp14> reduce the &quot;refresh
		period&quot;
              "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).
	</t>
       </list>
       <list style="hanging">
	<t hangText="-">If Resv).</li>

              <li>If node protection is requested for the LSP and the PPhop
              node does not support the RI-RSVP-FRR extensions, then the node MUST
              <bcp14>MUST</bcp14> reduce the &quot;refresh period&quot; "refresh period" in the
              TIME_VALUES object carried in the Resv messages to the default
              short refresh interval.
	</t>
       </list>
       <list style="hanging">
	<t hangText="-">If interval.</li>

              <li>If the node reduces the refresh time using the above
              procedures, it MUST NOT <bcp14>MUST NOT</bcp14> execute MP procedures
              specified in <xref target="failures"/> of this document.
	</t>
       </list>
       </t> document.</li>
	      </ul>
          </section>

          <section anchor="incr_deploy" title="Incremental Deployment"> anchor="incr_deploy">
            <name>Incremental Deployment</name>

            <t>The backward compatibility procedures described in the previous
	  sub-sections
	  subsections imply that a router supporting the RI-RSVP-FRR
	  extensions specified in this document can apply the procedures
	  specified in the 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 path.
       <list style="hanging">
	<t hangText="-">RI-RSVP-FRR
            </t>

              <ul>
              <li>RI-RSVP-FRR extensions and procedures are enabled for
		downstream Path,  PathTear PathTear, and ResvErr messages corresponding
		to an LSP if link protection is requested for the LSP and the
		Nhop node supports the extensions
	</t>
       </list>
       <list style="hanging">
	<t hangText="-">RI-RSVP-FRR extensions.</li>

              <li>RI-RSVP-FRR extensions and procedures are enabled for
		downstream Path,  PathTear PathTear, and ResvErr messages corresponding
		to an LSP if node protection is requested for the LSP and both
		Nhop &amp; and NNhop nodes support the extensions
	</t>
       </list>
       <list style="hanging">
	<t hangText="-">RI-RSVP-FRR extensions.</li>

              <li>RI-RSVP-FRR extensions and procedures are enabled for
              upstream PathErr, Resv Resv, and ResvTear messages corresponding to an
              LSP if link protection is requested for the LSP and the Phop
              node supports the extensions
	</t>
       </list>
       <list style="hanging">
	<t hangText="-">RI-RSVP-FRR extensions.</li>

              <li>RI-RSVP-FRR extensions and procedures are enabled for
              upstream PathErr, Resv Resv, and ResvTear messages corresponding to an
              LSP if node protection is requested for the LSP and both Phop
              and the PPhop nodes support the extensions
	</t>
       </list>
       </t> extensions.</li>
	    </ul>

            <t>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" title="Consequence anchor="cap_bit_without_support">
        <name>Consequences of Advertising RI-RSVP without RI-RSVP-FRR"> Without RI-RSVP-FRR</name>
        <t>If a node supporting facility backup protection <xref target="RFC4090"/>
	  sets the RI-RSVP capability (I bit) (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 operation operations
	  (see <xref target="prob_desc"/> of this document). Consider the example
	  topology <xref target="example_network"/> (<xref target="example_network"/>) provided in this document.
       <list style="hanging">
	<t hangText="-">Assume
        </t>

        <ul>
          <li>Assume node B does set the RI-RSVP capability in its Node-ID
		based 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.
	</t>
       </list>
       <list style="hanging">
	<t hangText="-">Instead timeout.</li>

          <li>Instead of node B, assume node C does set the RI-RSVP capability in
          its Node-id based 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. But, However, C would not recognize the condition
          encoded in the PathTear and end up tearing down the LSP.
	</t>
       </list>
       <list style="hanging">
	<t hangText="-">Assume LSP.</li>

          <li>Assume node B does set the RI-RSVP capability in its Node-ID
		based Node-ID-based
          Hello messages even though it does not support RI-RSVP-FRR
          extensions. Also In addition, assume local repair is about to commence on node B
          for an LSP that has only requested link protection. That 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, so C may end up
          holding on to the stale state until the (long) refresh
		timeout.
	</t>
       </list>
       </t> timeout.</li>
	</ul>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations"> anchor="Security">
      <name>Security Considerations</name>
      <t>The security considerations pertaining to the original RSVP protocol
         <xref protocols
         (<xref target="RFC2205"/>, <xref target="RFC3209"/> target="RFC3209"/>, and <xref target="RFC5920"/> target="RFC5920"/>)
	 remain relevant. When using RSVP Cryptographic Authentication cryptographic authentication
	 <xref target="RFC2747"/>,  more robust algorithms such as HMAC-SHA256,
	 HMAC-SHA384, or HMAC-SHA512 <xref target="RFC2104"/><xref target="RFC2104"/> <xref target="FIPS-180-4"/>
	 SHOULD
	 <bcp14>SHOULD</bcp14> be used when computing the keyed message digest where possible.
      </t>

<!-- [rfced] For clarity, may we update the text below as follows?

Original:

   So, the implementations
   SHOULD provide the option to configure Node-ID neighbor specific or
   global authentication key to authentication messages received from
   Node-ID neighbors.

Perhaps:

   Therefore, the implementations SHOULD provide the option to configure either a
   specific neighbor or global Node-ID authentication key to authentication
   messages received from Node-ID neighbors.

-->

      <t>This document extends the applicability of Node-ID based Node-ID-based Hello session
      sessions between immediate neighbors. The Node-ID based 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. So, Therefore, the
      implementations SHOULD <bcp14>SHOULD</bcp14> provide the option to configure a
      Node-ID neighbor specific or global authentication key to authentication
      messages received from Node-ID neighbors. The network administrator SHOULD
      <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 SHOULD <bcp14>SHOULD</bcp14> also provide the option to specify
      a limit on the number of Node-ID based Node-ID-based Hello sessions that can be
      established on a router supporting the extensions defined in this
      document.
      </t>
    </section>

<section anchor="IANA" title="IANA Considerations"> anchor="IANA">
      <name>IANA Considerations</name>
      <section anchor="IANA_Conditions" title="CONDITIONS Object"> anchor="IANA_Conditions">
        <name>CONDITIONS Object</name>
        <t>IANA maintains the Class "Class Names, Class Numbers, and Class Types registries Types" registry
	  in the &quot;RSVP parameters&quot; "RSVP Parameters" registry group (see
          http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml).
          <eref target="http://www.iana.org/assignments/rsvp-parameters/"/>).
          IANA is requested to extend has extended these registries by adding a new Class Number
          (in the 10bbbbbb range) and assign assigning a new C-Type under this Class Number,
          as described below (see <xref target="cnd_path_tear_obj"/>):

       <artwork>
        <![CDATA[
        </t>

<table anchor="table1">
  <name>Class Names, Class Number Numbers, and Class Name      Reference
   TBA1          CONDITIONS      This document
        ]]>
       </artwork>

       <t>Class Types</name>
  <thead>
    <tr>
      <th>Class Number</th>
      <th>Class Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>135</td>
      <td>CONDITIONS</td>
      <td>RFC 9705</td>
    </tr>
  </tbody>
</table>

<table anchor="table2">
  <name>Class Type of C-types or C-Types - TBA1 CONDITIONS </t>

       <artwork>
        <![CDATA[
Value      Class Name       Reference
  1        CONDITIONS       This document
        ]]>
       </artwork> 135 CONDITIONS</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>CONDITIONS</td>
      <td>RFC 9705</td>
    </tr>
  </tbody>
</table>
        <t>IANA is requested to add has added a new sub-registry for &quot;CONDITIONS subregistry called "CONDITIONS Object
	  Flags&quot;
	  Flags" as shown below. Assignments of additional Class Type values
	  for Class Name &quot;CONDITIONS&quot; "CONDITIONS" are to be performed via
	  &quot;IETF Review&quot;
	  "IETF Review" <xref target="RFC8126"/>.</t>

       <artwork>
        <![CDATA[
Bit Number   32-bit Value   Name           Reference
  0-30       Unassigned
   31        0x0001         Merge-point    This document
        ]]>
       </artwork>

<table anchor="table3">
  <name>CONDITIONS Object Flags</name>
  <thead>
    <tr>
      <th>Bit Number</th>
      <th>32-Bit Value</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0-30</td>
      <td></td>
      <td>Unassigned</td>
      <td></td>
    </tr>
    <tr>
      <td>31</td>
      <td>0x0001</td>
      <td>Merge-point</td>
      <td>RFC 9705</td>
    </tr>
  </tbody>
</table>

      <t>All assignments in this sub-registry subregistry are to be performed via
	  &quot;IETF Review&quot; "IETF
      Review" <xref target="RFC8126"/>.</t>
       </t>

      </section>
    </section>

   <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

   <?rfc needLines="8" ?>

  </middle>
  <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2747.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4090.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2961.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2205.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4558.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3473.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5063.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8370.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8796.xml"/>
      </references>

      <references>
        <name>Informative References</name>

        <reference anchor="FIPS-180-4" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">
          <front>
            <title>Secure Hash Standard</title>
            <author>
              <organization>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>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5920.xml"/>

      </references>
    </references>

   <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false">
      <name>Acknowledgements</name>
      <t>We are very grateful to Yakov Rekhter <contact fullname="Yakov Rekhter"/> for his
      contributions to the development of the idea and thorough review of the
      content of the draft. document.  We are thankful to Raveendra Torvi and Yimin Shen <contact fullname="Raveendra
      Torvi"/> and <contact fullname="Yimin Shen"/> for their comments and
      inputs on early versions of the draft. document. We also thank Alexander
	 Okonnikov <contact
      fullname="Alexander Okonnikov"/> for his review and comments on the draft.
      document.
      </t>
    </section>

   <!-- Possibly a 'Contributors' section ...  -->

   <section anchor="Contributors" title="Contributors">
     <t>
     Markus Jork<br></br>
     Juniper numbered="false">
      <name>Contributors</name>

 <contact fullname="Markus Jork">
   <organization>Juniper Networks, Inc.<br></br>
     Email: mjork@juniper.net
     </t>

     <t>
     Harish Sitaraman<br></br>
     Individual Contributor<br></br>
     Email: harish.ietf@gmail.com
     </t>

     <t>
     Vishnu Inc.</organization>
   <address>
     <email>mjork@juniper.net</email>
   </address>
 </contact>

 <contact fullname="Harish Sitaraman">
   <organization>Individual Contributor</organization>
   <address>
     <email>harish.ietf@gmail.com</email>
   </address>
 </contact>

 <contact fullname="Vishnu Pavan Beeram<br></br>
     Juniper Beeram">
   <organization>Juniper Networks, Inc.<br></br>
     Email: vbeeram@juniper.net
     </t>

     <t>
     Ebben Aries<br></br>
     Juniper Inc.</organization>
   <address>
     <email>vbeeram@juniper.net</email>
   </address>
 </contact>

 <contact fullname="Ebben Aries">
   <organization>Juniper Networks, Inc.<br></br>
     Email: exa@juniper.com
     </t>

     <t>
     Mike Taillon<br></br>
     Cisco Inc.</organization>
   <address>
     <email>exa@juniper.com</email>
   </address>
 </contact>

 <contact fullname="Mike Taillon">
   <organization>Cisco Systems, Inc.<br></br>
     Email: mtaillon@cisco.com
     </t> Inc.</organization>
   <address>
     <postal/>
     <email>mtaillon@cisco.com</email>
   </address>
 </contact>
    </section>

 </middle>

 <back>

  </back>
</rfc>

<!-- References split into informative [rfced] Please review the following questions and normative -->

   <!-- There are 2 ways to insert reference entries from changes regarding the citation libraries:
    1. define an ENTITY at
terminology used in this document.

a) We note some instances where "RSVP" is not included in "Refresh-Interval
Independent FRR" (in the top, document title and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both elsewhere). For consistency,
should "RSVP" be added to these instances?  Some examples are cited textually in the same manner: by using xref elements.
    If you use listed below.

Original:
   4.6.1.  Detecting Support for Refresh interval Independent FRR
   ...
   "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the PI option, xml2rfc will, by default, try set
   of procedures defined in this document to...

Perhaps:
   4.6.1.  Detecting Support for Refresh-Interval Independent RSVP FRR
   ...
   "Refresh-Interval Independent RSVP FRR", or RI-RSVP-FRR, refers to find included files the set
   of procedures defined in this document to...

b) To parallel usage in RFC 4090, may we update the same
    directory as capitalization of the including file. You can also define terms below
throughout this document?

 Phop  > PHOP
 PPhop > PPHOP
 Nhop  > NHOP
 NNhop > NNHOP

c) To parallel usage in RFC 8796, may we update the XML_LIBRARY environment variable
    with a value containing a set capitalization of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

   <references title="Normative References">
      &RFC2119;
      &RFC2747;
      &RFC3209;
      &RFC4090;
      &RFC2961;
      &RFC2205;
      &RFC4558;
      &RFC3473;
      &RFC5063;
      &RFC8126;
      &RFC8174;
      &RFC8370;
      &RFC8796;
   </references>

   <references title="Informative References">
      <reference anchor="FIPS-180-4">
	<front>
	 <title>Secure Hash Standard</title>
	 <author>
	 <organization>National Institute terms below
throughout this document?

 Association source > Association Source
 B-SFRR-Ready Extended Association object > B-SFRR-Ready Extended ASSOCIATION object

d) Should instances of Standards "RRO object" and Technology</organization>
	 </author>
	 <date month="August" year="2015"/>
	</front>
	<seriesInfo name="FIPS" value="180-4"/>
      </reference>
      &RFC2104;
      &RFC5920;
   </references>

 </back>
</rfc> "LSP path" be updated to simply read
"RRO" and "LSP" to avoid redundancy? If expanded, "RRO object" would read as
"Record Route Object object" and "LSP path" would read as "Label Switched
Path path". Please review and let us know if any updates are needed.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

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