rfc9705xml2.original.xml   rfc9705.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!-- One method to get references from the online citation libraries. <!ENTITY nbsp "&#160;">
There has to be one entity for each item to be referenced. <!ENTITY zwsp "&#8203;">
An alternate method (rfc include) is described in the references. --> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC2104 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.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">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3209.xml">
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4090.xml">
<!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">
]> ]>
<?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 category="std" docName="draft-ietf-mpls-ri-rsvp-frr-22" ipr="pre5378Trust20
0902" submissionType="IETF" consensus="true" updates="4090">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-mpls-ri-rsvp-frr-22" number="9705" ipr="pre5378Trust200902" submissionType="I ETF" consensus="true" obsoletes="" updates="4090" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3" xml:lang="en" >
<front> <!-- [rfced] Please review the following questions and changes regarding this
<!-- The abbreviated title is used in the page header - it is only necessary document's title:
if the
full title is longer than 39 characters -->
<title abbrev="RI-RSVP FRR Bypass">Refresh-interval Independent FRR Facility a) FYI - Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Protection Style Guide").
</title>
<!-- add 'role="editor"' below for the editors if appropriate --> b) Should "RSVP" be added to the title for consistency with the rest of the
document and the abbreviated title?
<!-- Another author who claims to be an editor --> Original:
Refresh-interval Independent FRR Facility Protection
<author initials="C. " surname="Ramachandran" fullname="Chandra Ramachandran Current:
"> Refresh-Interval Independent Fast Reroute (FRR) Facility Protection
<organization>Juniper Networks, Inc.</organization>
<address>
<email>csekar@juniper.net</email>
</address>
</author>
<author initials="T. " surname="Saad" fullname="Tarek Saad"> Perhaps:
<organization>Cisco Systems, Inc.</organization> Refresh-Interval Independent RSVP Fast Reroute (RI-RSVP-FRR) Facility Protect
<address> ion
<email>tsaad@cisco.com</email>
</address>
</author>
<author initials="I. " surname="Minei" fullname="Ina Minei"> -->
<organization>Google, Inc.</organization>
<address>
<email>inaminei@google.com</email>
</address>
</author>
<author initials="D. " surname="Pacella" fullname="Dante Pacella"> <front>
<organization>Verizon, Inc.</organization> <title abbrev="RI-RSVP-FRR Bypass">Refresh-Interval Independent Fast Reroute
<address> (FRR) Facility Protection</title>
<email>dante.j.pacella@verizon.com</email> <seriesInfo name="RFC" value="9705"/>
</address> <author initials="C." surname="Ramachandran" fullname="Chandra Ramachandran"
>
<organization>Juniper Networks, Inc.</organization>
<address>
<email>csekar@juniper.net</email>
</address>
</author> </author>
<author initials="T." surname="Saad" fullname="Tarek Saad">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>tsaad@cisco.com</email>
</address>
</author>
<author initials="I." surname="Minei" fullname="Ina Minei">
<organization>Google, Inc.</organization>
<address>
<email>inaminei@google.com</email>
</address>
</author>
<author 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"/>
<date year="2024" /> <area>RTG</area>
<workgroup>mpls</workgroup>
<!-- If the month and year are both specified and are the current ones, xml2r
fc will fill
in the current day for you. If only the current year is specified, xml2r
fc will fill
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 sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient 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 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> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<!-- Keywords will be incorporated into HTML output <keyword>example</keyword>
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090
define two local repair techniques to reroute Label Switched Path (LSP)
traffic over pre-established backup tunnels. Facility backup 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
techniques is attractive from a scalability point of view. This document
enumerates facility backup procedures in RFC 4090 that rely on refresh
timeout, hence, making facility backup 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, and hence, compatible with the
Refresh-Interval Independent RSVP (RI-RSVP) capability specified in RFC
8370. Hence, this document updates RFC 4090 in order to support the
RI-RSVP capability specified in RFC 8370.
</t>
</abstract>
</front>
<t>The RSVP-TE Fast Reroute extensions specified in RFC 4090 defines two local <middle>
repair techniques to reroute Label Switched Path (LSP) traffic over <section anchor="intro">
pre-established backup tunnel. Facility backup method allows one or more <name>Introduction</name>
LSPs traversing a connected link or node to be protected using a bypass <t>RSVP-TE relies on a periodic refresh of RSVP messages to synchronize
tunnel. The many-to-one nature of local repair technique is attractive and maintain the states related to the Label Switched Path (LSP) along the
from scalability point of view. This document enumerates facility backup reserved path. In the absence of refresh messages, the LSP-related
procedures in RFC 4090 that rely on refresh timeout and hence make states are automatically deleted. Reliance on periodic refreshes and
facility backup method refresh-interval dependent. The RSVP-TE extensions refresh timeouts are problematic from the scalability point of view. The
defined in this document will enhance the facility backup protection number of RSVP-TE LSPs that a router needs to maintain has been growing
mechanism by making the corresponding procedures refresh-interval in service provider networks, and the implementations should be capable
independent and hence compatible with Refresh-interval Independent RSVP of handling increases in LSP scale.
(RI-RSVP) specified in RFC 8370. Hence, this document updates RFC 4090 in </t>
order to support RI-RSVP capability specified in RFC 8370. <t><xref target="RFC2961"/> specifies mechanisms to eliminate the
</t> reliance on periodic refreshes and refresh timeouts of RSVP messages and
enables a router to increase the message refresh interval to values much
longer than the default 30 seconds defined in <xref
target="RFC2205"/>. However, the protocol extensions defined in <xref
target="RFC4090"/> for supporting Fast Reroute (FRR) using bypass
tunnels implicitly rely on short refresh timeouts to 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 FRR using bypass tunnels <xref
target="RFC4090"/>, additional explicit teardown messages are
necessary. The Refresh-Interval Independent RSVP FRR (RI-RSVP-FRR)
extensions specified in this document consist of procedures to enable
LSP state cleanup that are essential in supporting the RI-RSVP capability
for FRR using bypass tunnels from <xref target="RFC4090"/>.
</t>
<section anchor="intro_motivation">
<name>Motivation</name>
</abstract> <!-- [rfced] Should the first bullet be separated into two separate bullets
because it contains two separate problems?
<note title="Requirements Language"> Original:
The use of Refresh messages to
cover many possible failures has resulted in a number of operational
problems.
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - One problem relates to RSVP control plane scaling due to periodic
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIO refreshes of Path and Resv messages, another relates to the
NAL" in this reliability and latency of RSVP signaling.
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> - 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].
<middle> Perhaps:
<section anchor="intro" title="Introduction"> The use of Refresh messages to
cover many possible failures has resulted in a number of operational
problems.
<t>RSVP-TE relies on periodic refresh of RSVP messages to synchronize and * One problem relates to RSVP control plane scaling due to periodic
maintain the Label Switched Path (LSP) related states along the reserved refreshes of Path and Resv messages
path. In the absence of refresh messages, the LSP-related states are
automatically deleted. Reliance on periodic refreshes and refresh timeouts
are problematic from the scalability point of view. The number of RSVP-TE
LSPs that a router needs to maintain has been growing in service provider
networks and the implementations should be capable of handling increase in
LSP scale.
</t>
<t><xref target="RFC2961"/> specifies mechanisms to eliminate the reliance * Another problem relates to the relates to the reliability and latency of
on periodic RSVP signaling. reliability and latency of RSVP signaling.
refresh and refresh timeout 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 protoc
ol extensions
defined in <xref target="RFC4090"/> for supporting Fast Reroute (FRR) using
bypass tunnels
implicitly rely on short refresh timeouts to cleanup stale states.
</t>
<t>In order to eliminate the reliance on refresh timeouts, the routers * An additional problem is the time to clean up the stale state
should unambiguously determine when a particular LSP state should be after a tear message is lost. For more on these problems see
deleted. In scenarios involving <xref target="RFC4090"/> FRR using bypass t Section 1 of [RFC2961].
unnels,
additional explicit tear down messages are necessary. Refresh-interval
Independent RSVP FRR (RI-RSVP-FRR) extensions specified in this document
consists of procedures to enable LSP state cleanup that are essential in
supporting RI-RSVP capability for <xref target="RFC4090"/> FRR using bypass
tunnels.
</t>
<section anchor="intro_motivation" title="Motivation"> -->
<t>Base RSVP <xref target="RFC2205"/> maintains state via the
generation of RSVP Path/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>Base RSVP <xref target="RFC2205"/> maintains state via the
<t hangText="-">One problem relates to RSVP control plane scaling due to generation of RSVP Path and Resv refresh messages. Refresh messages are
periodic refreshes of Path and Resv messages, another used to both synchronize state between RSVP neighbors and to recover
relates to the reliability and latency of RSVP signaling. from lost RSVP messages. The use of Refresh messages to cover many
</t> possible failures has resulted in a number of operational problems.
</list> </t>
<list style="hanging"> <ul>
<t hangText="-">An additional problem is the time to clean up the stale <li>One problem relates to RSVP control plane scaling due to
state after a tear message is lost. For more on these periodic refreshes of Path and Resv messages and another relates to th
problems see Section 1 of RSVP Refresh Overhead Reduction e
Extensions <xref target="RFC2961"/>. reliability and latency of RSVP signaling.</li>
</t> <li>An additional problem is the time to clean up the stale state
</list> after a tear message is lost. For more on these problems, see <xref
</t> target="RFC2961" sectionFormat="of" section="1"/>.</li>
</ul>
<t>The problems listed above adversely affect RSVP control plane <t>The problems listed above adversely affect RSVP control plane
scalability and RSVP-TE <xref target="RFC3209"/> inherited these problems scalability, and RSVP-TE <xref target="RFC3209"/> inherited these
from standard RSVP. Procedures specified in <xref target="RFC2961"/> problems from standard RSVP. Procedures specified in <xref
address the above-mentioned problems by eliminating dependency on target="RFC2961"/> address the above-mentioned problems by eliminating
refreshes for state synchronization and for recovering from lost RSVP dependency on refreshes for state synchronization and for recovering
messages, and by eliminating dependency on refresh timeout for stale from lost RSVP messages, and also by eliminating dependency on refresh
state cleanup. Implementing these procedures allows implementations to timeout for stale state cleanup. Implementing these procedures allows
improve RSVP-TE control plane scalability. For more details on implementations to improve RSVP-TE control plane scalability. For more
eliminating dependency on refresh timeout for stale state cleanup, refer details on eliminating dependency on refresh timeouts for stale state
to "Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling cleanup, refer to <xref target="RFC8370" sectionFormat="of"
Techniques <xref target="RFC8370"/>. section="3"/>.
</t> </t>
<t>However, the facility backup protection procedures specified in <t>However, the facility backup protection procedures specified in
<xref target="RFC4090"/> do not fully address stale state cleanup as the <xref target="RFC4090"/> do not fully address stale state cleanup as the
procedures depend on refresh timeouts for stale state cleanup. The procedures depend on refresh timeouts for stale state cleanup. The
updated facility backup protection procedures specified in this document, updated facility backup protection procedures specified in this document,
in combination with RSVP-TE Scaling Techniques <xref target="RFC8370"/>, in combination with RSVP-TE Scaling Techniques <xref target="RFC8370"/>,
eliminate this dependency on refresh timeouts for stale state cleanup. eliminate this dependency on refresh timeouts for stale state cleanup.
</t> </t>
<t>The procedures specified in this document assume reliable delivery of <!--[rfced] To clarify this document's relation to [RFC2961], may we
RSVP messages, as specified in <xref target="RFC2961"/>. Therefore, this update this sentence as follows?
document makes support for <xref target="RFC2961"/> a pre-requisite.
</t>
</section>
</section>
<section anchor="terminology" title="Terminology"> Original:
Therefore, this document makes support for [RFC2961] a pre-requisite.
<t>The reader is expected to be familiar with the terminology in Perhaps:
<xref target="RFC2205"/>, <xref target="RFC3209"/>, Therefore, [RFC2961] is a prerequisite for this document.
<xref target="RFC4090"/>, <xref target="RFC4558"/>, -->
<xref target="RFC8370"/> and <xref target="RFC8796"/>.
</t>
<t>Phop node: Previous-hop router along the label switched path <t>The procedures specified in this document assume reliable delivery of
</t> RSVP messages, as specified in <xref target="RFC2961"/>. Therefore, this
document makes support for <xref target="RFC2961"/> a prerequisite.
</t>
</section>
</section>
<t>PPhop node: Previous-Previous-hop router along the label switched path <section anchor="terminology">
</t> <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"/>, and <xref target="RFC8796"/>.
</t>
<t>Nhop node: Next-hop router along the label switched path <!-- [rfced] Please review the following questions and changes regarding
</t> Section 2 ("Terminology").
<t>NNhop node: Next-Next-hop router along the label switched path a) The terminology list contains a mixture of both abbreviations and
</t> definitions. For consistency and readability, may we separate definitions and
abbreviations into two different lists?
<t>PLR: Point of Local Repair router as defined in <xref target="RFC4090"/> b) May we update some list items for a more accurate and 1:1 relationship
</t> between an abbreviation and its expansion? Please see examples in the
"Perhaps" text below.
<t>MP: Merge Point router as defined in <xref target="RFC4090"/> c) In addition, the format of some definition items may suggest that "router"
</t> 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?
<t>LP-MP node: Merge Point router at the tail of Link-Protecting bypass tun Originals:
nel
</t>
<t>NP-MP node: Merge Point router at the tail of Node-Protecting bypass tun Phop node: Previous-hop router along the label switched path
nel
</t>
<t>RRO: Record Route Object as defined in <xref target="RFC3209"/> MP: Merge Point router as defined in [RFC4090]
</t>
<t>TED: Traffic Engineering Database LP-MP node: Merge Point router at the tail of Link-Protecting bypass tunnel
</t>
<t>LSP state: The combination of "path state" maintained as Path State Bloc Perhaps (a few examples):
k
(PSB) and "reservation state" maintained as Reservation State Block (RSB)
forms an individual LSP state on an RSVP-TE speaker
</t>
<t>RI-RSVP: The set of procedures defined in Section 3 of RSVP-TE Scaling PHOP: Previous-Hop (can refer to a router or node along the LSP)
Techniques <xref target="RFC8370"/> to eliminate RSVP's reliance on periodi
c
message refreshes
</t>
<t>B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object defin MP: Merge Point (can refer to a router as defined in [RFC4090])
ed
in Summary FRR extensions <xref target="RFC8796"/> and is added by the PLR
for each protected LSP.
</t>
<t>RI-RSVP-FRR: The set of procedures defined in this document to eliminate LP-MP: Link-Protecting Merge Point (can refer to a router or node at the
RSVP's reliance of periodic message refreshes when supporting facility back tail of a Link-Protecting bypass tunnel)
up
protection <xref target="RFC4090"/>
</t>
<t>Conditional PathTear: A PathTear message containing a suggestion to a d) FYI - We have added expansions for Path State Block (PSB) and Reservation
receiving downstream router to retain the path state if the receiving route State Block (RSB) to this terminology list to avoid expanding them inside of
r the definition of "LSP state". Please review and let us know if there are
is an NP-MP additional abbreviations or terminology used in this document (such as LSP,
</t> FRR, etc.) that you would like to add to this terminology list.
<t>Remote PathTear: A PathTear message sent from a Point of Local Repair (P -->
LR)
to the MP to delete the LSP state on the MP if PLR had not previously sent
the
backup Path state reliably
</t>
</section>
<section anchor="prob_desc" title="Problem Description"> <dl>
<dt>Phop node:</dt><dd>Previous-Hop router along the LSP</dd>
<dt>PPhop node:</dt><dd>Previous-Previous-Hop router along the 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"/></dd>
<dt>MP:</dt><dd>Merge Point router as defined in <xref target="RFC4090"/>
</dd>
<dt>LP-MP node:</dt><dd>Merge Point router at the tail of Link-Protecting
bypass tunnel</dd>
<dt>NP-MP node:</dt><dd>Merge Point router at the tail of Node-Protecting
bypass 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"
/></dd>
<dt>TED:</dt><dd>Traffic Engineering Database</dd>
<dt>LSP state:</dt><dd>The combination of "path state" maintained as a
PSB and "reservation state" maintained as an RSB forms an individual
LSP state on an RSVP-TE speaker</dd>
<dt>RI-RSVP:</dt><dd>The set of procedures defined in <xref section="3" s
ectionFormat="of" target="RFC8370"/> to eliminate RSVP's reliance on periodic
message refreshes</dd>
<dt>B-SFRR-Ready:</dt><dd>Bypass Summary FRR Ready Extended Association o
bject as defined
in <xref target="RFC8796"/> and added by the PLR
for each protected LSP</dd>
<dt>RI-RSVP-FRR:</dt><dd>The set of procedures defined in this document t
o eliminate
RSVP's reliance on periodic message refreshes when supporting facility ba
ckup
protection <xref target="RFC4090"/></dd>
<dt>Conditional PathTear:</dt><dd>A PathTear message containing a suggest
ion to a
receiving downstream router to retain the path state if the receiving rou
ter
is an NP-MP</dd>
<dt>Remote PathTear:</dt><dd>A PathTear message sent from a PLR
to the MP to delete the LSP state on the MP if the PLR had not previously
sent the
backup path state reliably</dd>
</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>
<figure align="center" anchor="example_network" title="Example Topology"> <section anchor="prob_desc">
<artwork align="center"><![CDATA[ <name>Problem Description</name>
<figure anchor="example_network">
<name>Example Topology</name>
<artwork align="center"><![CDATA[
E E
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
A ----- B ----- C ----- D A ----- B ----- C ----- D
\ / \ /
\ / \ /
\ / \ /
\ / \ /
\ / \ /
\ / \ /
F F
]]></artwork> ]]></artwork>
</figure>
</figure> <!-- [rfced] How may we update "has been configured to be long of the order of
minutes" for clarity?
<t>In the topology in <xref target="example_network"/>, consider a 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 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 interval has been configured to be long of the order of minutes and
refresh reduction extensions are enabled on all routers. refresh reduction extensions are enabled on all routers.
</t> </t>
<t>In addition, assume that node protection has been configured for the LS
<t>Also assume that node protection has been configured for the LSPs Ps
and the LSPs are protected by each router in the following way and the LSPs are protected by each router in the following way:
</t>
<list style="hanging"> <ul>
<t hangText="-">A has made node protection available using bypass LSP <li>A has made node protection available using bypass LSP A -&gt; E
A -> E -> C; A is the PLR and C is the NP-MP -&gt; C; A is the PLR and C is the NP-MP.</li>
</t> <li>B has made node protection available using bypass LSP B -&gt; F
</list> -&gt; D; B is the PLR and D is the NP-MP.</li>
<list style="hanging"> <li>C has made link protection available using bypass LSP C -&gt; B
<t hangText="-">B has made node protection available using bypass LSP -&gt; F -&gt; D; C is the PLR and D is the LP-MP.</li>
B -> F -> D; B is the PLR and D is the NP-MP </ul>
</t>
</list>
<list style="hanging">
<t hangText="-">C has made link protection available using bypass LSP
C -> B -> F -> D; C is the PLR and D is the LP-MP
</t>
</list>
</t>
<t>In the above condition, assume that B-C link fails. The following is <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 the sequence of events that is expected to occur for all protected
LSPs under normal conditions. LSPs under normal conditions.
</t>
<list style="hanging"> <ol type="Step %d.">
<t hangText="1.">B performs local repair and re-directs LSP traffic <li anchor="step1">B performs a local repair and redirects LSP traffic o
over the bypass LSP B -> F -> D. ver the bypass
</t> LSP B -&gt; F -&gt; D.</li>
</list> <li anchor="step2">B also creates a backup state for the LSP and triggers
<list style="hanging"> the sending of
<t hangText="2.">B also creates backup state for the LSP and triggers a backup LSP state to D over the bypass LSP B -&gt; F -&gt; D.</li>
sending of backup LSP state to D over the bypass LSP <li anchor="step3">D receives the backup LSP states and merges the backup
B -> F -> D. s with the
</t> protected LSPs.</li>
</list> <li anchor="step4">As the link on C, over which the LSP states are refre
<list style="hanging"> shed, has
<t hangText="3.">D receives backup LSP states and merges the backups failed, C will no longer receive state refreshes. Consequently, the
with the protected LSPs. protected LSP states on C will time out and C will send the teardown
</t> messages for all LSPs. As each router should consider itself as an MP,
</list> C will time out the state only after waiting for an additional
<list style="hanging"> duration equal to the refresh timeout.</li>
<t hangText="4.">As the link on C, over which the LSP states are </ol>
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 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 refresh timeout.
</t>
</list>
</t>
<t>While the above sequence of events has been described in <xref target= "RFC4090"/>, <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 there are a few problems for which no mechanism has been specified
explicitly. explicitly:
</t>
<list style="hanging"> <ul>
<t hangText="-">If the protected LSP on C times out before D receives <li>If the protected LSP on C times out before D receives signaling
signaling for the backup LSP, then D would receive a for the backup LSP, then D would receive a PathTear from C prior to
PathTear from C prior to receiving signaling for the receiving signaling for the backup LSP, thus resulting in deleting the
backup LSP, thus resulting in deleting the LSP state. LSP state. This would be possible at scale even with the default refres
This would be possible at scale even with default h
refresh time. time.</li>
</t>
</list>
<list style="hanging">
<t hangText="-">If upon the link failure C is to keep state until its
timeout, then with long refresh 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, this would result
in deleting the state on D, thus deleting the LSP. D
needs a reliable mechanism to determine whether it is
an MP or not to overcome this problem.
</t>
</list>
<list style="hanging">
<t hangText="-">If head-end A attempts to tear down LSP after step 1
but before step 2 of the above sequence, then B may
receive the tear down message before step 2 and
delete the LSP state from its state database. If B
deletes its state without informing D, with long
refresh interval this could cause (large) buildup of
stale state on D.
</t>
</list>
<list style="hanging">
<t hangText="-">If B fails to perform local repair in step 1, then B
will delete the LSP state from its state database
without informing D. As B deletes its state without
informing D, with long refresh interval this could
cause (large) buildup of stale state on D.
</t>
</list>
</t>
<t>The purpose of this document is to provide solutions to the above <li>If C is to keep state until its timeout upon the link failure,
problems which will then make it practical to scale up to a large then with a long refresh interval, this may result in a large amount
number of protected LSPs in the network. of stale state on C. Alternatively, if C is to
</t> delete the state and send a PathTear to D upon the link failure, then th
is would result in
deleting the state on D, thus deleting the LSP. D needs a reliable
mechanism to determine whether or not it is an MP to overcome this
problem.</li>
<li>If head-end A attempts to tear down the LSP after <xref target="step1
"
format="none">Step 1</xref> but before <xref target="step2"
format="none">Step 2</xref> of the above sequence, then B may receive
the teardown message before <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, this
could cause a (large) buildup of stale state on D.</li>
<li>If B fails to perform a local repair in <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, thi
s
could cause a (large) buildup of stale state on D.</li>
</ul>
<t>The purpose of this document is to provide solutions to the above
problems, which will then make it practical to scale up to a large
number of protected LSPs in the network.
</t>
</section> </section>
<section anchor="solution" title="Solution Aspects"> <section anchor="solution">
<t>The solution consists of five parts. <name>Solution Aspects</name>
<t>The solution consists of five 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 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 reuses some of the extensions
defined in <xref target="RFC8796"/> and <xref target="RFC8370"/>, and th
e subsequent
subsections will list the extensions in these documents that are
utilized in this document.</li>
<list style="hanging"> <li>Handle upstream link or node failures by cleaning up LSP states if
<t hangText="-">Utilize MP determination mechanism specified in the node has not found itself as an MP through the MP determination
RSVP-TE Summary FRR <xref target="RFC8796"/> that enables mechanism. See <xref target="failures"/> of this document for more
the PLR to signal the availability of local protection to details.</li>
the MP. In addition, introduce PLR and MP procedures to
establish Node-ID based hello session between the PLR and
the MP to detect router failures and to determine capability.
See <xref target="sig_handshake"/> of this document for more det
ails. This part of the solution
re-uses 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 will list the extensions in these
drafts that are utilized in this document.
</t>
</list>
<list style="hanging">
<t hangText="-">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 thi
s document for more details.
</t>
</list>
<list style="hanging">
<t hangText="-">Introduce extensions to enable a router to send a tear
down 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 det
ails.
</t>
</list>
<list style="hanging">
<t hangText="-">Enhance facility backup protection by allowing a PLR to
directly send a tear down message to the MP without requiring
the PLR to either have a working bypass LSP or have already
signaled backup LSP state. See <xref target="rem_tear"/> of this
document for more details.
</t>
</list>
<list style="hanging">
<t hangText="-">Introduce extensions to enable the above procedures
to be backward compatible with routers along the LSP path
running implementation that do not support these procedures.
See <xref target="compatible"/> of this document for more detail
s.
</t>
</list>
</t>
<section anchor="adv_capability" title="Requirement on RFC 4090 Capable Node <li>Introduce extensions to enable a router to send a teardown
to advertise RI-RSVP Capability"> message to the downstream router that enables the receiving router to
<t>A node supporting facility backup protection <xref target="RFC4090"/> conditionally delete its local LSP state. See <xref
MUST NOT set the RI-RSVP flag (I bit) that is defined in Section 3.1 of target="cnd_path_tear"/> of this document for more details.</li>
RSVP-TE Scaling Techniques <xref target="RFC8370"/> unless it
supports all the extensions specified in the rest of this document.
Hence, this document updates <xref target="RFC4090"/> by defining exten
sions and
additional procedures over facility backup protection
<xref target="RFC4090"/> in order to advertise 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) but does not support all the extensions specified
in the rest of this document, then it may result in lingering stale sta
tes
due to the long refresh intervals recommended by <xref target="RFC8370"
/>.
This can also disrupt normal Fast Reroute (FRR) operation.
<xref target="cap_bit_without_support"/> of this document delves on thi
s in detail.
</t>
</section>
<section anchor="sig_handshake" title="Signaling Handshake between PLR and M <li>Enhance facility backup protection by allowing a PLR to directly
P"> send a teardown message to the MP without requiring the PLR to either
<section anchor="sig_plr_behavior" title="PLR Behavior"> have a working bypass LSP or have already signaled the backup LSP
<t>As per the facility backup procedures <xref target="RFC4090"/>, when state. See <xref target="rem_tear"/> of this document for more
details.</li>
<li>Introduce extensions to enable the above procedures to be backward
compatible with routers along the LSP path running implementations that
do not support these procedures. See <xref target="compatible"/> of
this document for more 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
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 Capa
bility</name>
<t>A node supporting facility backup protection <xref
target="RFC4090"/> <bcp14>MUST NOT</bcp14> set the RI-RSVP flag (I-bit)
that is defined in <xref 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-b
it) 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) operations. <xref
target="cap_bit_without_support"/> of this document delves into this in
detail.
</t>
</section>
<section anchor="sig_handshake">
<name>Signaling Handshake Between PLR and MP</name>
<section anchor="sig_plr_behavior">
<name>PLR Behavior</name>
<t>As per the facility backup procedures <xref target="RFC4090"/>, whe
n
an LSP becomes operational on a node and the "local protection desire d" an LSP becomes operational on a node and the "local protection desire d"
flag has been set in the SESSION_ATTRIBUTE object carried in the Path flag has been set in the SESSION_ATTRIBUTE object carried in the Path
message corresponding to the LSP, then the node attempts to make loca l message corresponding to the LSP, then the node attempts to make loca l
protection available for the LSP. protection available for the LSP.
</t>
<ul>
<li>If the "node protection desired" flag is set, then the node
tries to become a PLR by attempting to create an NP-bypass LSP to
the NNhop node avoiding the Nhop node on a protected LSP 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.</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.</li>
</ul>
<list style="hanging"> <t>With regard to the PLR procedures described above and specified
<t hangText="-">If the "node protection desired" flag is set, then in <xref target="RFC4090"/>, this document specifies the following
the node tries to become a PLR by attempting to create a additional procedures to support RI-RSVP <xref
NP-bypass LSP to the NNhop node avoiding the Nhop node on target="RFC8370"/>.</t>
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 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 Nho
p
</t>
</list>
</t>
<t>With regard to the PLR procedures described above and that are <ul>
specified in <xref target="RFC4090"/>, this document specifies the fo <li>While selecting the destination address of the bypass LSP, the
llowing PLR <bcp14>MUST</bcp14> select the router ID of the NNhop or Nhop
additional procedures to support RI-RSVP <xref target="RFC8370"/>. 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 <bcp14>MUST</bcp14> execu
te
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"/>).</li>
<list style="hanging"> <!-- [rfced] Can the second sentence in the text below be made more concise,
<t hangText="-">While selecting the destination address of the bypass as it mostly contains repeated information from the previous sentence?
LSP, the PLR MUST select the router ID of the NNhop or Nhop
node from the Node-ID sub-object included in the RRO object car
ried
in the most recent Resv message corresponding to the LSP. If th
e
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 t
he
TED to determine the router ID corresponding to the interface
address 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 RRO
object, then the PLR MUST execute backward compatibility proced
ures
as if the downstream nodes along the LSP do not support the ext
ensions
defined in the document (see <xref target="dnstr_no_support"/>)
.
</t>
</list>
<list style="hanging">
<t hangText="-">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, th
e
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 parallel to the attempt made to create NP-bypass
or LP-bypass, the PLR MUST initiate a Node-ID based Hello
session to the NNhop or Nhop node respectively along the LSP to
establish the RSVP-TE signaling adjacency. This Hello session i
s
used to detect MP node failure as well as determine the capabil
ity
of the MP node. If the MP has set the I-bit in the CAPABILITY
object <xref target="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. If the
MP has not sent Node-ID based Hello messages or has not set
the I-bit in CAPABILITY object <xref target="RFC8370"/>,
then the PLR MUST execute backward compatibility procedures
defined in <xref target="dnstr_no_support"/> of this document.
</t>
</list>
<list style="hanging">
<t hangText="-">When the PLR associates a bypass to a protected LSP, it
MUST 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 be followed. In addition to those
rules, the PLR MUST set the Association Source in the object to
its
Node-ID address.
</t>
</list>
</t>
</section> Original:
<section anchor="sig_rem_adjacency" title="Remote Signaling Adjacency"> - The PLR MUST also include its router ID in a Node-ID sub-object in
<t>A Node-ID based RSVP-TE Hello session is one in which Node-ID is 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.
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 subseque
nt 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 <bcp14>MUST</bcp14> initiate a Node-ID-based
Hello session to the NNhop or Nhop node respectively along the LSP
to establish the RSVP-TE signaling adjacency. This Hello session
is used to detect MP node failure as well as to determine the
capability of the MP node. 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 Hello session, then the
PLR <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 Hello messages or
has not set the I-bit in the CAPABILITY object <xref
target="RFC8370"/>, then the PLR <bcp14>MUST</bcp14> execute
backward compatibility procedures defined in <xref
target="dnstr_no_support"/> of this document.</li>
<li>When the PLR associates a bypass to a protected LSP, it
<bcp14>MUST</bcp14> include a B-SFRR-Ready Extended Association
object <xref target="RFC8796"/> 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"/> <bcp14>MUST</bcp14> be followed. In
addition to those rules, the PLR <bcp14>MUST</bcp14> set the
Association Source in the object to its Node-ID address.</li>
</ul>
</section>
<section anchor="sig_rem_adjacency">
<name>Remote Signaling Adjacency</name>
<t>A Node-ID-based RSVP-TE Hello session is one in which a Node-ID is
used in the source and the destination address fields of RSVP Hello used in the source and the destination address fields of RSVP Hello
messages <xref target="RFC4558"/>. This document extends Node-ID based messages <xref target="RFC4558"/>. This document extends Node-ID-based
RSVP Hello session to track the state of any RSVP-TE neighbor that is RSVP Hello sessions to track the state of any RSVP-TE neighbor that is
not directly connected by at least one interface. In order to apply not directly connected by at least one interface. In order to apply
Node-ID based RSVP-TE Hello session between any two routers that are Node-ID-based RSVP-TE Hello sessions between any two routers that are
not immediate neighbors, the router that supports the extensions not immediate neighbors, the router that supports the extensions
defined in the document MUST set TTL to 255 in all outgoing defined in the document <bcp14>MUST</bcp14> set the TTL to 255 in all
Node-ID based Hello messages exchanged between the PLR and the MP. The outgoing
default hello interval for this Node-ID hello session MUST be set Node-ID-based Hello messages exchanged between the PLR and the MP. The
default hello interval for this Node-ID Hello session <bcp14>MUST</bcp
14> be set
to the default specified in RSVP-TE Scaling Techniques to the default specified in RSVP-TE Scaling Techniques
<xref target="RFC8370"/>. <xref target="RFC8370"/>.
</t> </t>
<t>In the rest of the document, the terms "signaling adjacency"
<t>In the rest of the document the term &quot;signaling adjacency&quot;, and "remote signaling adjacency" refer specifically to the
or &quot;remote signaling adjacency&quot; refers specifically to the
RSVP-TE signaling adjacency. RSVP-TE signaling adjacency.
</t> </t>
</section> </section>
<section anchor="sig_mp_behavior">
<section anchor="sig_mp_behavior" title="MP Behavior"> <name>MP Behavior</name>
<t>With regard to the MP procedures that are defined in <t>With regard to the MP procedures that are defined in
<xref target="RFC4090"/> this document specifies the following <xref target="RFC4090"/>, this document specifies the following
additional procedures to support RI-RSVP defined in additional procedures to support RI-RSVP as defined in
<xref target="RFC8370"/>. <xref target="RFC8370"/>.
</t> </t>
<t>Each node along an LSP path supporting the extensions defined in
<t>Each node along an LSP path supporting the extensions defined in this document <bcp14>MUST</bcp14> also include its router ID in the No
this document MUST also include its router ID in the Node-ID de-ID
sub-object of the RRO object carried in the Resv message of the sub-object of the RRO object that is carried in the Resv message of th
e
corresponding LSP. If the PLR has not included a Node-ID sub-object corresponding LSP. If the PLR has not included a Node-ID sub-object
in the RRO object carried in the Path message and if the PLR is in in the RRO object that is carried in the Path message and if the PLR i
a different IGP area, then the router MUST NOT execute the MP s in
a different IGP area, then the router <bcp14>MUST NOT</bcp14> execute
the MP
procedures specified in this document for those LSPs. Instead, the procedures specified in this document for those LSPs. Instead, the
node MUST execute backward compatibility procedures defined in node <bcp14>MUST</bcp14> execute backward compatibility procedures def ined in
<xref target="upstr_no_support"/> of this document as if the upstream nodes along <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. the LSP do not support the extensions defined in this document.
</t> </t>
<t>A node receiving a Path message should determine whether the
message contains a B-SFRR-Ready Extended Association object with
its own address as the bypass destination address and whether it
has an operational Node-ID signaling adjacency with the Association
source. If the PLR has not included the B-SFRR-Ready Extended
Association object or if there is no operational Node-ID signaling
adjacency with the PLR identified by the Association source address
or if the PLR has not advertised RI-RSVP capability in its
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>
<t>If a matching B-SFRR-Ready Extended Association object is found in <!-- [rfced] FYI - There are a number of instances throughout the document where
in the Path message and if there is an operational remote Node-ID we have updated text to be formatted as a bulleted list to improve readability.
signaling adjacency with the PLR (identified by the Association Please review these instances and let us know of any objections.
source) that has advertised RI-RSVP capability (I-bit) -->
<xref target="RFC8370"/>, then the node MUST 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 be followed by the implementations
supporting this document.
<list style="hanging"> <t>A node receiving a Path message should determine:</t>
<t hangText="-">If a matching Bypass Summary FRR Extended Association <ul>
object is included by the PPhop node of an LSP and if a <li>whether the message contains a B-SFRR-Ready Extended
corresponding Node-ID signaling adjacency exists with the Association object with its own address as the bypass destination
PPhop node, then the router MUST conclude it is the NP-MP. address and</li>
</t> <li>whether it has an operational Node-ID signaling adjacency with
</list> the Association source.</li>
<list style="hanging"> </ul>
<t hangText="-">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 conclude it is the LP-MP.
</t>
</list>
</t>
</section>
<section anchor="sig_rem_state" title="&quot;Remote&quot; State on MP"> <t>The node <bcp14>MUST</bcp14> execute the
<t>Once a router concludes it is the MP for a PLR running backward compatibility procedures defined in
refresh-interval independent FRR procedures as described in the <xref target="upstr_no_support"/> of this document if:</t>
preceding section, it MUST create a remote path state for the LSP. <ul>
The only difference between the &quot;remote&quot; path state and <li>the PLR has not included the B-SFRR-Ready Extended
the LSP state is the RSVP_HOP object. The RSVP_HOP object in a Association object,</li>
&quot;remote&quot; path state contains the address that the PLR <li>there is no operational Node-ID signaling
uses to send Node-ID hello messages to the MP. adjacency with the PLR identified by the Association source address, o
</t> r</li>
<li>the PLR has not advertised the RI-RSVP capability in its
Node-ID-based Hello messages.</li>
</ul>
<t>If a matching B-SFRR-Ready Extended Association object is found
in the Path message and if there is an operational remote Node-ID
signaling adjacency with the PLR (identified by the Association
source) that has advertised the RI-RSVP capability (I-bit) <xref
target="RFC8370"/>, then the node <bcp14>MUST</bcp14> consider
itself as the MP for the PLR. The matching and ordering rules for
Bypass Summary FRR Extended Association specified in RSVP-TE Summary
FRR <xref target="RFC8796"/> <bcp14>MUST</bcp14> be followed by the
implementations supporting this document.
</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 <bcp14>MUST</bcp14> conclude it is the 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 <bcp14>MUST</bcp14> conclude it is the LP-MP.</li>
</ul>
</section>
<t>The MP MUST consider the &quot;remote&quot; path state corresponding <section anchor="sig_rem_state">
<name>"Remote" State on 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 <bcp14>MUST</bcp14> create a remote path state
for the LSP. The only difference between the "remote" path state
and the LSP state is the RSVP_HOP object. The RSVP_HOP object in a
"remote" path state contains the address that the PLR uses to send
Node-ID Hello messages to the MP.
</t>
<t>The MP <bcp14>MUST</bcp14> consider the "remote" path state corresp
onding
to the LSP automatically deleted if: to the LSP automatically deleted if:
</t>
<list style="hanging"> <ul>
<t hangText="-">The MP later receives a Path message for the LSP with <li>the MP later receives a Path message for the LSP with no
no matching B-SFRR-Ready Extended Association object correspond matching B-SFRR-Ready Extended Association object corresponding to
ing the PLR's IP address contained in the Path RRO,</li>
to the PLR's IP address contained in the Path RRO, or <li>the Node-ID signaling adjacency with the PLR goes down,</li>
</t> <li>the MP receives backup LSP signaling for the LSP from the PLR,</
</list> li>
<list style="hanging"> <li>the MP receives a PathTear for the LSP, or</li>
<t hangText="-">The Node-ID signaling adjacency with the PLR goes down, <li>the MP deletes the LSP state on a local policy or an exception e
or vent.</li>
</t> </ul>
</list> <t>The purpose of "remote" path state is to enable the PLR
<list style="hanging">
<t hangText="-">The MP receives backup LSP signaling for the LSP from t
he PLR or
</t>
</list>
<list style="hanging">
<t hangText="-">The MP receives a PathTear for the LSP, or
</t>
</list>
<list style="hanging">
<t hangText="-">The MP deletes the LSP state on a local policy or an ex
ception event
</t>
</list>
</t>
<t>The purpose of &quot;remote&quot; path state is to enable the PLR
to explicitly tear down the path and reservation states corresponding to explicitly tear down the path and reservation states corresponding
to the LSP by sending a tear message for the &quot;remote&quot; path to the LSP by sending a tear message for the "remote" path
state. Such a message tearing down &quot;remote&quot; path state is state. Such a message tearing down the "remote" path state is
called &quot;Remote&quot; PathTear. called "Remote" PathTear.
</t> </t>
<t>The scenarios in which a "Remote" PathTear is applied are
<t>The scenarios in which a &quot;Remote&quot; PathTear is applied are
described in <xref target="rem_tear"/> of this document. described in <xref target="rem_tear"/> of this document.
</t> </t>
</section> </section>
</section> </section>
<section anchor="failures">
<section anchor="failures" title="Impact of Failures on LSP State"> <name>Impact of Failures on LSP State</name>
<t>This section describes the procedures that must be executed upon <t>This section describes the procedures that must be executed upon
different kinds of failures by nodes along the path of the LSP. The different kinds of failures by nodes along the path of the LSP. The
procedures that must be executed upon detecting RSVP signaling adjacenc y procedures that must be executed upon detecting RSVP signaling adjacenc y
failures do not impact the RSVP-TE graceful restart mechanisms failures do not impact the RSVP-TE graceful restart mechanisms
(<xref target="RFC3473"/>, <xref target="RFC5063"/>). If a node <xref target="RFC3473"/> <xref target="RFC5063"/>. If a node
executing these procedures acts as a helper for a neighboring router, executing these procedures acts as a helper for a neighboring router,
then the signaling adjacency with the neighbor will be declared as havi ng then the signaling adjacency with the neighbor will be declared as havi ng
failed only after taking into account the grace period extended for the failed only after taking into account the grace period extended for the
neighbor by this node acting as a helper. neighbor by this node acting as a helper.
</t> </t>
<t>Node failures are detected from the state of Node-ID Hello
<t>Node failures are detected from the state of Node-ID hello
sessions established with immediate neighbors. RSVP-TE Scaling sessions established with immediate neighbors. RSVP-TE Scaling
Techniques <xref target="RFC8370"/> recommends that each node Techniques <xref target="RFC8370"/> recommends that each node
establish Node-ID hello sessions with all its immediate neighbors. establish Node-ID Hello sessions with all its immediate neighbors.
Non-immediate PLR or MP failure is detected from the state of remote A non-immediate PLR or MP failure is detected from the state of remote
signaling adjacency established according to signaling adjacency established according to
<xref target="sig_rem_adjacency"/> of this document. <xref target="sig_rem_adjacency"/> of this document.
</t> </t>
<section anchor="failures_nonmp">
<section anchor="failures_nonmp" title="Non-MP Behavior"> <name>Non-MP Behavior</name>
<t>When a router detects the Phop link or the Phop node failure for an LS <t>When a router detects the Phop link or the Phop node failure for an
P LSP
and the router is not an MP for the LSP, then it MUST send a Condition and the router is not an MP for the LSP, then it <bcp14>MUST</bcp14> s
al end a Conditional
PathTear (refer to <xref target="cnd_path_tear"/> of this document) PathTear (refer to <xref target="cnd_path_tear"/> of this document)
and delete the PSB and RSB states corresponding to and delete the PSB and RSB states corresponding to
the LSP. the LSP.
</t> </t>
</section> </section>
<section anchor="failures_lpmp">
<section anchor="failures_lpmp" title="LP-MP Behavior"> <name>LP-MP Behavior</name>
<t>When the Phop link for an LSP fails on a router that is an LP-MP for <t>When the Phop link for an LSP fails on a router that is an LP-MP fo
the LSP, the LP-MP MUST retain the PSB and RSB states corresponding r
to the LSP till the occurrence of any of the following events. the LSP, the LP-MP <bcp14>MUST</bcp14> retain the PSB and RSB states c
orresponding
<list style="hanging"> to the LSP until the occurrence of any of the following events:
<t hangText="-">The Node-ID signaling adjacency with the Phop PLR goes d </t>
own, or <ul>
</t> <li>the Node-ID signaling adjacency with the Phop PLR goes down,</li
</list> >
<list style="hanging"> <li>the MP receives a normal or "Remote" PathTear for its PSB, or</l
<t hangText="-">The MP receives a normal or &quot;Remote&quot; PathTear i>
for its PSB, or <li>the MP receives a ResvTear for its RSB.</li>
</t> </ul>
</list> <t>When a router that is an LP-MP for an LSP detects Phop node failure
<list style="hanging"> from the Node-ID signaling adjacency state, the LP-MP <bcp14>MUST</bcp
<t hangText="-">The MP receives a ResvTear for its RSB. 14> send a normal
</t>
</list>
</t>
<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 send a norm
al
PathTear and delete the PSB and RSB states corresponding to the LSP. PathTear and delete the PSB and RSB states corresponding to the LSP.
</t> </t>
</section> </section>
<section anchor="failures_npmp" title="NP-MP Behavior"> <section anchor="failures_npmp">
<t>When a router that is an NP-MP for an LSP detects Phop link failure, <name>NP-MP Behavior</name>
<t>When a router that is an NP-MP for an LSP detects Phop link failure
or Phop node failure from the Node-ID signaling adjacency, the router or Phop node failure from the Node-ID signaling adjacency, the router
MUST retain the PSB and RSB states corresponding to the LSP till the <bcp14>MUST</bcp14> retain the PSB and RSB states corresponding to the
occurrence of any of the following events. LSP until the
occurrence of any of the following events:
</t>
<ul>
<li>the remote Node-ID signaling adjacency with the PPhop PLR goes d
own,</li>
<li>the MP receives a normal or "Remote" PathTear for its PSB, or</l
i>
<li>the MP receives a ResvTear for its RSB.</li>
</ul>
<t>When a router that is an NP-MP for an LSP does not detect the Phop
link or the Phop node failure but receives a Conditional PathTear
from the Phop node, then the router <bcp14>MUST</bcp14> retain the
PSB and RSB states corresponding to the LSP until the occurrence of
any of the following events:
</t>
<ul>
<li>the remote Node-ID signaling adjacency with the PPhop PLR goes d
own,</li>
<li>the MP receives a normal or "Remote" PathTear for its PSB, or</l
i>
<li>the MP receives a ResvTear for its RSB.</li>
</ul>
<t>Receiving a Conditional PathTear from the Phop node will not
impact the "remote" state from the PPhop PLR. Note that the Phop
node must have sent the Conditional PathTear as it was not an MP for
the LSP (see <xref target="failures_nonmp"/> 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.
<list style="hanging"> Original:
<t hangText="-">The remote Node-ID signaling adjacency with the PPhop PL
R goes down, or
</t>
</list>
<list style="hanging">
<t hangText="-">The MP receives a normal or &quot;Remote&quot; PathTear
for its PSB, or
</t>
</list>
<list style="hanging">
<t hangText="-">The MP receives a ResvTear for its RSB.
</t>
</list>
</t>
<t>When a router that is an NP-MP for an LSP did not detect the Phop link Now when A-B link fails, as B is not an
or the Phop node failure, but receives a Conditional PathTear from the MP and its Phop link has failed, B will delete the LSP state (this
Phop node, then the router MUST retain the PSB and RSB states correspo behavior is required for unprotected LSPs - refer to Section 4.3.1 of
nding to the this document).
LSP till the occurrence of any of the following events.
<list style="hanging"> Current:
<t hangText="-">The remote Node-ID signaling adjacency with the PPhop PL
R goes down, or
</t>
</list>
<list style="hanging">
<t hangText="-">The MP receives a normal or &quot;Remote&quot; PathTear
for its PSB, or
</t>
</list>
<list style="hanging">
<t hangText="-">The MP receives a ResvTear for its RSB.
</t>
</list>
</t>
<t>Receiving a Conditional PathTear from the Phop node will not impact Now, when the A-B link fails, B will delete the LSP state, because B is not
the &quot;remote&quot; state from the PPhop PLR. Note that the Phop an MP and its Phop link has failed (this behavior is required for
node must have sent the Conditional PathTear as it was not an MP for unprotected LSPs; refer to Section 4.3.1 of this document).
the LSP (see <xref target="failures_nonmp"/> of this document).
</t>
<t>In the example topology <xref target="example_network"/>, we assume -->
C &amp; D are the NP-MPs for the PLRs A &amp; B respectively. Now when
A-B link fails, as B is not an MP and its Phop link has failed, B will <t>In the example topology in <xref target="example_network"/>, we ass
delete the LSP state (this behavior is required for unprotected LSPs - ume
C and D are the NP-MPs for the PLRs A and B, respectively. Now, when t
he
A-B link fails, B will delete the LSP state, because B is not an MP an
d its Phop link has failed (this behavior is required for unprotected LSPs;
refer to <xref target="failures_nonmp"/> of this document). In the dat a refer to <xref target="failures_nonmp"/> of this document). In the dat a
plane, that would require B to delete the label forwarding entry plane, that would require B to delete the label forwarding entry
corresponding to the LSP. So if B's downstream nodes C and D continue to corresponding to the LSP. Thus, if B's downstream nodes C and D contin ue to
retain state, it would not be correct for D to continue to assume itse lf retain state, it would not be correct for D to continue to assume itse lf
as the NP-MP for the PLR B. as the NP-MP for the PLR B.
</t> </t>
<t>The mechanism that enables D to stop considering itself as the
<t>The mechanism that enables D to stop considering itself as the NP-MP for B and delete the corresponding "remote" path
NP-MP for B and delete the corresponding &quot;remote&quot; path
state is given below. state is given below.
</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 check
s
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 th
e
B-SFRR-Ready Extended Association object containing the Association
Source set to B from the Path message and triggers a Path to
D.</li>
<li>When D receives the Path message, it realizes that it is no
longer the NP-MP for B and so it deletes the corresponding
"remote" path state. D does not propagate the Path further down
because the only change is that the B-SFRR-Ready Extended
Association object corresponding to Association Source B is no
longer present in the Path message.</li>
</ol>
</section>
<list style="hanging"> <section anchor="failures_lpnpmp">
<t hangText="1.">When C receives a Conditional PathTear from B, it <name>Behavior of a Router That Is Both the LP-MP and NP-MP</name>
decides to retain LSP state as it is the NP-MP of the PLR A. <t>A router may simultaneously be the LP-MP and the NP-MP for the
It also checks whether Phop B had previously signaled Phop and PPhop nodes of an LSP, respectively. If the Phop link
availability of node protection. As B had previously signaled fails on such a node, the node <bcp14>MUST</bcp14> retain the PSB
NP availability by including B-SFRR-Ready Extended Association and RSB states corresponding to the LSP until the occurrence of any
object, C removes the B-SFRR-Ready Extended Association of the following events:
object containing Association Source set to B from the Path </t>
message and trigger a Path to D. <ul>
</t> <li>both Node-ID signaling adjacencies with Phop and PPhop nodes go
</list> down,</li>
<list style="hanging"> <li>the MP receives a normal or "Remote" PathTear for its PSB, or</l
<t hangText="2.">When D receives the Path message, it realizes that it i>
is no longer the NP-MP for B and so it deletes the <li>the MP receives a ResvTear for its RSB.</li>
corresponding &quot;remote&quot; path state. D does not </ul>
propagate the Path further down because the only change is that <t>If a router that is both an LP-MP and an NP-MP detects Phop node
the B-SFRR-Ready Extended Association object corresponding to failure, then the node <bcp14>MUST</bcp14> retain the PSB and RSB stat
Association Source B is no longer present in the Path message. es corresponding
</t> to the LSP until the occurrence of any of the following events:
</list> </t>
</t> <ul>
</section> <li>the remote Node-ID signaling adjacency with the PPhop PLR goes d
own,</li>
<section anchor="failures_lpnpmp" title="Behavior of a Router that is both <li>the MP receives a normal or "Remote" PathTear for its PSB, or</l
LP-MP and NP-MP"> i>
<t>A router may simultaneously be the LP-MP as well as the NP-MP for the <li>the MP receives a ResvTear for its RSB.</li>
Phop and the PPhop nodes respectively of an LSP. If the Phop link fail </ul>
s </section>
on such a node, the node MUST retain the PSB and RSB states correspond </section>
ing
to the LSP till the occurrence of any of the following events.
<list style="hanging">
<t hangText="-">Both Node-ID signaling adjacencies with Phop and PPhop n
odes go down, or
</t>
</list>
<list style="hanging">
<t hangText="-">The MP receives a normal or &quot;Remote&quot; PathTear
for its PSB, or
</t>
</list>
<list style="hanging">
<t hangText="-">The MP receives a ResvTear for its RSB.
</t>
</list>
</t>
<t>If a router that is both an LP-MP and an NP-MP detects Phop node
failure, then the node MUST retain the PSB and RSB states correspondin
g
to the LSP till the occurrence of any of the following events.
<list style="hanging">
<t hangText="-">The remote Node-ID signaling adjacency with the PPhop PL
R goes down, or
</t>
</list>
<list style="hanging">
<t hangText="-">The MP receives a normal or &quot;Remote&quot; PathTear
for its PSB, or
</t>
</list>
<list style="hanging">
<t hangText="-">The MP receives a ResvTear for its RSB.
</t>
</list>
</t>
</section>
</section>
<section anchor="cnd_path_tear" title="Conditional PathTear"> <section anchor="cnd_path_tear">
<t>In the example provided in <xref target="failures_npmp"/> of this docu <name>Conditional PathTear</name>
ment, B <t>In the example provided in <xref target="failures_npmp"/> of this
deletes the PSB and RSB states corresponding to the LSP once B detects document, B deletes the PSB and RSB states corresponding to the LSP
its Phop link went down as B is not an MP. If B were to send a once B detects its Phop link that went down as B is not an MP. If B
PathTear normally, then C would delete LSP state immediately. In were to send a PathTear normally, then C would delete the LSP state
order to avoid this, there should be some mechanism by which B can immediately. In order to avoid this, there should be some mechanism by
indicate to C that B does not require the receiving node to which B can indicate to C that B does not require the receiving node
unconditionally delete the LSP state immediately. For this, B MUST to unconditionally delete the LSP state immediately. For this, B
add a new optional CONDITIONS object in the PathTear. The CONDITIONS <bcp14>MUST</bcp14> add a new optional CONDITIONS object in the
object is defined in <xref target="cnd_path_tear_obj"/> of this documen PathTear. The CONDITIONS object is defined in <xref
t. If node C target="cnd_path_tear_obj"/> of this document. If node C also
also understands the new object, then C MUST NOT delete the LSP state understands the new object, then C <bcp14>MUST NOT</bcp14> delete the
if it is an NP-MP. LSP state if it is an NP-MP.
</t> </t>
<section anchor="cnd_path_tear_send" title="Sending Conditional PathTear"> <section anchor="cnd_path_tear_send">
<t>A router that is not an MP for an LSP MUST delete the PSB and RSB <name>Sending the Conditional PathTear</name>
<t>A router that is not an MP for an LSP <bcp14>MUST</bcp14> delete th
e PSB and RSB
states corresponding to the LSP if the Phop link or the Phop Node-ID 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). signaling adjacency goes down (see <xref target="failures_nonmp"/> of this document).
The router MUST send a Conditional PathTear if the following are also The router <bcp14>MUST</bcp14> send a Conditional PathTear if the foll
true. owing are also
true:
<list style="hanging"> </t>
<t hangText="-">The ingress has requested node protection for the LSP, a <ul>
nd <li>the ingress has requested node protection for the LSP and</li>
</t> <li>no PathTear is received from the upstream node.</li>
</list> </ul>
<list style="hanging"> </section>
<t hangText="-">No PathTear is received from the upstream node
</t>
</list>
</t>
</section>
<section anchor="cnd_path_tear_recv" title="Processing Conditional PathTear <section anchor="cnd_path_tear_recv">
"> <name>Processing the Conditional PathTear</name>
<t>When a router that is not an NP-MP receives a Conditional PathTear, <t>When a router that is not an NP-MP receives a Conditional PathTear,
the node MUST delete the PSB and RSB states corresponding to the LSP, the node <bcp14>MUST</bcp14> delete the PSB and RSB states correspondi
ng to the LSP
and process the Conditional PathTear by considering it as a normal and process the Conditional PathTear by considering it as a normal
PathTear. Specifically, the node MUST NOT propagate the Conditional PathTear. Specifically, the node <bcp14>MUST NOT</bcp14> propagate the Conditional
PathTear downstream but remove the optional object and send a normal PathTear downstream but remove the optional object and send a normal
PathTear downstream. PathTear downstream.
</t> </t>
<t>When a node that is an NP-MP receives a Conditional PathTear, it
<t>When a node that is an NP-MP receives a Conditional PathTear, it <bcp14>MUST NOT</bcp14> delete the LSP state. The node <bcp14>MUST</bc
MUST NOT delete LSP state. The node MUST check whether the p14> check whether the
Phop node had previously included the B-SFRR-Ready Extended Associatio n Phop node had previously included the B-SFRR-Ready Extended Associatio n
object in the Path. If the object had been included previously by the object in the Path. If the object had been included previously by the
Phop, then the node processing the Conditional PathTear from the Phop Phop, then the node processing the Conditional PathTear from the Phop
MUST remove the corresponding object and trigger a Path downstream. <bcp14>MUST</bcp14> remove the corresponding object and trigger a Path
</t> downstream.
</t>
<t>If a Conditional PathTear is received from a neighbor that has not <t>If a Conditional PathTear is received from a neighbor that has not
advertised support (refer to <xref target="compatible"/> of this docum ent) for the advertised support (refer to <xref target="compatible"/> of this docum ent) for the
new procedures defined in this document, then the node MUST new procedures defined in this document, then the node <bcp14>MUST</bc
consider the message as a normal PathTear. The node MUST propagate p14>
consider the message as a normal PathTear. The node <bcp14>MUST</bcp14
> propagate
the normal PathTear downstream and delete the LSP state. the normal PathTear downstream and delete the LSP state.
</t> </t>
</section> </section>
<section anchor="cnd_path_tear_obj">
<section anchor="cnd_path_tear_obj" title="CONDITIONS Object"> <name>CONDITIONS Object</name>
<t>Any implementation that does not support Conditional PathTear <t>Any implementation that does not support a Conditional PathTear
needs to ignore the new object but process the message as a normal needs to ignore the new object but process the message as a normal
PathTear without generating any error. For this reason, the Class-Num PathTear without generating any error. For this reason, the Class-Num
of the new object follows the pattern 10bbbbbb where 'b' represents a of the new object follows the pattern 10bbbbbb, where "b" represents a
bit. bit.
(The behavior for objects of this type is specified in Section 3.10 of (The behavior for objects of this type is specified in <xref target="R
<xref target="RFC2205"/>). FC2205" sectionFormat="of" section="3.10"/>.)
</t> </t>
<t>The new object is called the "CONDITIONS" object and will
<t>The new object is called as &quot;CONDITIONS&quot; object that will
specify the conditions under which default processing rules of the specify the conditions under which default processing rules of the
RSVP-TE message MUST be invoked. RSVP-TE message <bcp14>MUST</bcp14> be invoked.
</t> </t>
<t>The object has the following format:</t>
<t>The object has the following format: <figure anchor="fig_conditions">
<name>CONDITIONS Object</name>
<figure align="left" anchor="fig_conditions" title="CONDITIONS Object"> <artwork align="left"><![CDATA[
<artwork>
<![CDATA[
0 1 2 3 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 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 | | Length | Class | C-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags (Reserved) |M| | Flags (Reserved) |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> ]]></artwork>
</artwork> </figure>
</figure>
<?rfc subcompact="yes" ?> <!-- [rfced] As all other fields are defined following Figure 2, should
<list style="none"> the Length field also have an entry?
<t>Class: TBA1<br></br>
C-type: 1<br></br>
Flags is a 32 bit field. Bit 31 is the Merge-point condition (M) bi
t:
If the M bit is set to 1, then the PathTear message MUST be process
ed
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 MUST be processed as a normal PathTear message for the LSP.
<br></br>
Bits 0-30 are reserved, they MUST be set to zero on transmission an
d
MUST be ignored on receipt.<br></br>
</t>
</list>
</t>
</section>
</section> 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 (Reserved) |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<section anchor="rem_tear" title="Remote State Teardown"> Figure 2: CONDITIONS Object
<t>If the ingress wants to tear down the LSP because of a management
Class: 135
C-type: 1
Flags: 32 bit field
M: Bit 31 is the Merge-point condition (M) bit. If the M bit is set
to 1, then the PathTear message MUST 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 MUST
be processed as a normal PathTear message for the 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</bc
p14> be processed
according to the receiver router role, i.e., if the receiving route
r
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 messa
ge for the LSP.</dd>
</dl>
<t>Bits 0-30 are reserved; they <bcp14>MUST</bcp14> be set to zero on transmis
sion and
<bcp14>MUST</bcp14> be ignored on receipt.</t>
</section>
</section>
<section anchor="rem_tear">
<name>Remote State 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 event while the LSP is being locally repaired at a transit PLR, it
would not be desirable to wait till the completion of backup LSP would not be desirable to wait until the completion of backup LSP
signaling to perform state cleanup. In this case, the PLR MUST send a signaling to perform state cleanup. In this case, the PLR <bcp14>MUST<
&quot;Remote&quot; PathTear message instructing the MP to delete the P /bcp14> send a
SB "Remote" PathTear message instructing the MP to delete the PSB
and RSB states corresponding to the LSP. The TTL in the &quot;Remote&q and RSB states corresponding to the LSP. The TTL in the "Remote"
uot; PathTear message <bcp14>MUST</bcp14> be set to 255. Doing this enables
PathTear message MUST be set to 255. Doing this enables LSP state clea LSP state cleanup
nup
when the LSP is being locally repaired. when the LSP is being locally repaired.
</t> </t>
<t>Consider that node C in the example topology <t>Consider that node C in the example topology
(<xref target="example_network"/>) has gone down and node B locally (<xref target="example_network"/>) has gone down and node B locally
repairs the LSP. repairs the LSP:
<list style="hanging"> </t>
<t hangText="1.">Ingress A receives a management event to tear down the <ol>
LSP. <li>Ingress A receives a management event to tear down the LSP.</li>
</t> <li>A sends a normal PathTear for the LSP to B.</li>
</list> <li>Assume B has not initiated the backup signaling for the
<list style="hanging"> LSP during local repair. To enable LSP state cleanup, B sends a
<t hangText="2.">A sends a normal PathTear for the LSP to B. "Remote" PathTear with the destination IP address set to
</t> that of the node D used in the Node-ID signaling adjacency with D
</list> and the RSVP_HOP object containing the local address used in the
<list style="hanging"> Node-ID signaling adjacency.</li>
<t hangText="3.">Assume B has not initiated the backup signaling for the <li>B then deletes the PSB and RSB states corresponding to the LSP.</li
LSP during local repair. To enable LSP state cleanup, B sends a >
&quot;Remote&quot; PathTear with destination IP address set to <li>On D, there would be a remote signaling adjacency with
that of the node D used in the Node-ID signaling adjacency with B, and so D accepts the "Remote" PathTear and deletes the
D, PSB and RSB states corresponding to the LSP.</li>
and the RSVP_HOP object containing local address used in the </ol>
Node-ID signaling adjacency.
</t>
</list>
<list style="hanging">
<t hangText="4.">B then deletes the PSB and RSB states corresponding to
the LSP.
</t>
</list>
<list style="hanging">
<t hangText="5.">On D there would be a remote signaling adjacency with
B and so D accepts the &quot;Remote&quot; PathTear and delete th
e
PSB and RSB states corresponding to the LSP.
</t>
</list>
</t>
<section anchor="lcl_repair_fail" title="PLR Behavior on Local Repair Failu <section anchor="lcl_repair_fail">
re"> <name>PLR Behavior on Local Repair Failure</name>
<t>If local repair fails on the PLR after a failure, the PLR MUST send a <t>If local repair fails on the PLR after a failure, the PLR <bcp14>MU
&quot;Remote&quot; PathTear to the MP. The purpose of this is to clean ST</bcp14> send a
up LSP state from the PLR to the Egress. Upon receiving the PathTear, "Remote" PathTear to the MP. The purpose of this is to clean
the MP MUST delete the states corresponding to the LSP and also up LSP state from the PLR to the egress. Upon receiving the PathTear,
propagate the PathTear downstream thereby achieving state cleanup from the MP <bcp14>MUST</bcp14> delete the states corresponding to the LSP
and also
propagate the PathTear downstream, thereby achieving state cleanup fro
m
all downstream nodes up to the LSP egress. Note that in the case of li nk all downstream nodes up to the LSP egress. Note that in the case of li nk
protection, the PathTear MUST be directed to the LP-MP's Node-ID IP protection, the PathTear <bcp14>MUST</bcp14> be directed to the LP-MP' s Node-ID IP
address rather than the Nhop interface address. address rather than the Nhop interface address.
</t> </t>
</section> </section>
<section anchor="resv_rro_chng">
<section anchor="resv_rro_chng" title="PLR Behavior on Resv RRO Change"> <name>PLR Behavior on Resv RRO Change</name>
<t>When a PLR router that has already made NP available for an LSP <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 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 that the router's former NP-MP is no longer present on the path of
the LSP, then the router MUST send a &quot;Remote&quot; PathTear the LSP, then the router <bcp14>MUST</bcp14> send a "Remote" PathTear
directly to its former NP-MP. directly to its former NP-MP.
</t> </t>
<t>In the example topology <xref target="example_network"/>, assume node <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 A has made node protection available for an LSP and C has concluded it
is the NP-MP for PLR A. When the B-C link fails then C, implementing t he is the NP-MP for PLR A. When the B-C link fails, then C, implementing the
procedure specified in <xref target="failures_lpnpmp"/> of this procedure specified in <xref target="failures_lpnpmp"/> of this
document, will retain the states corresponding to the LSP until: the document, will retain the states corresponding to the LSP until one of
remote Node-ID signaling adjacency with A goes down, or a PathTear or the following occurs:</t>
a ResvTear is received for its PSB or RSB respectively. If B also has <ul>
made node protection available, B will eventually complete backup LSP <li>the remote Node-ID signaling adjacency with A goes down
signaling with its NP-MP D and trigger a Resv to A with RRO changed. or</li>
The new RRO of the LSP carried in the Resv will not contain C. When A <li>a PathTear or a ResvTear is received for its PSB or RSB,
processes the Resv message with a new RRO not containing C - its forme respectively.</li>
r </ul>
NP-MP, A sends a &quot;Remote&quot; PathTear to C. When C receives <t>If B also has made node protection available, B will eventually
the &quot;Remote&quot; PathTear for its PSB state, C will send a norma complete backup LSP signaling with its NP-MP D and trigger a Resv
l to A with RRO changed. The new RRO of the LSP carried in the Resv
PathTear downstream to D and delete both the PSB and RSB states will not contain C. When A processes the Resv message with a new
corresponding to the LSP. As D has already received backup LSP RRO not containing C, its former NP-MP, A, sends a "Remote"
signaling from B, D will retain control plane and forwarding states PathTear to C. When C receives the "Remote" PathTear for its PSB
corresponding to the LSP. state, C will send a normal PathTear downstream to D and delete
</t> both the PSB and RSB states corresponding to the LSP. As D has
</section> already received backup LSP signaling from B, D will retain the contro
l
<section anchor="lcl_repair_preempt" title="LSP Preemption during Local Rep plane and forwarding states corresponding to the LSP.
air"> </t>
<section anchor="lcl_repair_preempt_lpnp" title="Preemption on LP-MP after </section>
Phop Link Failure"> <section anchor="lcl_repair_preempt">
<t>If an LSP is preempted on an LP-MP after its Phop link has already <name>LSP Preemption During Local Repair</name>
failed but the backup LSP has not been signaled yet as part of local <section anchor="lcl_repair_preempt_lpnp">
repair procedure, then the node MUST send a normal PathTear and delete <name>Preemption on LP-MP After Phop Link Failure</name>
<t>If an LSP is preempted on an LP-MP after its Phop link has alread
y
failed but the backup LSP has not been signaled yet as part of the loc
al
repair procedure, then the node <bcp14>MUST</bcp14> send a normal Path
Tear and delete
both the PSB and RSB states corresponding to the LSP. As the LP-MP has 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 signal ing, retained the LSP state expecting the PLR to initiate backup LSP signal ing,
preemption would bring down the LSP and the node would not be LP-MP an preemption would bring down the LSP and the node would not be LP-MP an
y ymore, requiring the node to clean up the LSP state.
more requiring the node to clean up the LSP state. </t>
</t> </section>
</section>
<section anchor="lcl_repair_preempt_npmp" title="Preemption on NP-MP after <section anchor="lcl_repair_preempt_npmp">
Phop Link Failure"> <name>Preemption on NP-MP After Phop Link Failure</name>
<t>If an LSP is preempted on an NP-MP after its Phop link has already <t>If an LSP is preempted on an NP-MP after its Phop link has alread
y
failed but the backup LSP has not been signaled yet, then the node failed but the backup LSP has not been signaled yet, then the node
MUST send a normal PathTear and delete the PSB and RSB states <bcp14>MUST</bcp14> send a normal PathTear and delete the PSB and RSB
corresponding to the LSP. As the NP-MP has retained LSP state states
corresponding to the LSP. As the NP-MP has retained the LSP state
expecting the PLR to initiate backup LSP signaling, preemption expecting the PLR to initiate backup LSP signaling, preemption
would bring down the LSP and the node would not be NP-MP any more would bring down the LSP and the node would not be NP-MP anymore,
requiring the node to clean up LSP state. requiring the node to clean up LSP state.
</t> </t>
<t>Consider that B-C link goes down on the same example topology <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 (<xref target="example_network"/>). As C is the NP-MP for the PLR A, C
will retain LSP state. will retain the LSP state.
<list style="hanging"> </t>
<t hangText="1.">The LSP is preempted on C.
</t> <!-- [rfced] May we provide additional context or lead-in text for the
</list> list below?
<list style="hanging">
<t hangText="2.">C will delete the RSB state corresponding to the LSP. Original:
But C cannot send a PathErr or a ResvTear to the PLR A because
the backup LSP has not been signaled yet. Consider that B-C link goes down on the same example topology
</t> (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP
</list> state.
<list style="hanging">
<t hangText="3.">As the only reason for C having retained state after 1. The LSP is preempted on C.
Phop node failure was that it was an NP-MP, C sends a normal
PathTear to D and delete its PSB state also. D would also delete 2. C will delete the RSB state...
the
PSB and RSB states on receiving a PathTear from C. Perhaps:
</t>
</list> Consider that the B-C link goes down on the same example topology
<list style="hanging"> (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP
<t hangText="4.">B starts backup LSP signaling to D. But as D does state. This means:
not have the LSP state, it will reject the backup LSP Path and
send a PathErr to B. 1. The LSP is preempted on C.
</t>
</list> 2. C will delete the RSB state...
<list style="hanging">
<t hangText="5.">B will delete its reservation and send a ResvTear to A. -->
</t>
</list> <ol>
</t> <li>The LSP is preempted on C.</li>
<li>C will delete the RSB state corresponding to the
LSP. However, C cannot send a PathErr or a ResvTear to the PLR A
because the backup LSP has not been signaled yet.</li>
<li>As the only reason for C having retained state after Phop
node failure was that it was an NP-MP, C sends a normal PathTear
to D and also deletes its PSB state. D would also delete the PSB
and RSB states on receiving a PathTear from C.</li>
<li>B starts backup LSP signaling to D. However, as D does not hav
e
the LSP state, it will reject the backup LSP Path and send a
PathErr to B.</li>
<li>B will delete its reservation and send a ResvTear to A.</li>
</ol>
</section>
</section>
</section> </section>
</section>
</section>
<section anchor="compatible" title="Backward Compatibility Procedures"> <section anchor="compatible">
<t>&quot;Refresh interval Independent FRR&quot; or RI-RSVP-FRR refers to th <name>Backward Compatibility Procedures</name>
e <t>"Refresh-Interval Independent FRR" and "RI-RSVP-FRR" refer to the
set of procedures defined in this document to eliminate the reliance of set of procedures defined in this document to eliminate the reliance on
periodic refreshes. The extensions proposed in RSVP-TE Summary FRR periodic refreshes. The extensions proposed in RSVP-TE Summary FRR
<xref target="RFC8796"/> may apply to implementations that do not support <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 RI-RSVP-FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP
state cleanup namely Conditional and &quot;Remote&quot; PathTear require state cleanup, namely Conditional and "Remote" PathTears, require
support from one-hop and two-hop neighboring nodes along the LSP path. support from one-hop and two-hop neighboring nodes along the LSP path.
So procedures that fall under LSP state cleanup category MUST NOT be Thus, procedures that fall under the LSP state cleanup category <bcp14>MU
turned on if any of the nodes involved in the node protection FRR i.e. ST NOT</bcp14> be
the PLR, the MP and the intermediate node in the case of NP, does not turned on if any of the nodes involved in the node protection FRR (i.e.,
the PLR, the MP, and the intermediate node in the case of NP) do not
support RI-RSVP-FRR extensions. Note that for LSPs requesting link support RI-RSVP-FRR extensions. Note that for LSPs requesting link
protection, only the PLR and the LP-MP MUST support the extensions. protection, only the PLR and the LP-MP <bcp14>MUST</bcp14> support the ex
</t> tensions.
<section anchor="compat_detect" title="Detecting Support for Refresh interv </t>
al Independent FRR"> <!-- [rfced] To reflect usage in RFC 8370, may we update 'the flag
<t>An implementation supporting RI-RSVP-FRR extensions MUST set the flag "Refresh interval Independent RSVP" or RI-RSVP flag' below as follows?
&quot;Refresh interval Independent RSVP&quot; or RI-RSVP flag in the
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">
<name>Detecting Support for Refresh-Interval Independent FRR</name>
<t>An implementation supporting RI-RSVP-FRR extensions <bcp14>MUST</bc
p14> set the flag
"Refresh interval Independent RSVP" or RI-RSVP flag in the
CAPABILITY object carried in Hello messages as specified in RSVP-TE CAPABILITY object carried in Hello messages as specified in RSVP-TE
Scaling Techniques <xref target="RFC8370"/>. If an implementation does Scaling Techniques <xref target="RFC8370"/>. If an implementation does
not set the flag even if it supports RI-RSVP-FRR extensions, then its 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 neighbors will view the node as any node that does not support the
extensions. extensions.
<list style="hanging"> </t>
<t hangText="-">As nodes supporting the RI-RSVP-FRR extensions initiate <ul>
Node-ID based signaling adjacency with all immediate neighbors, <li>As nodes supporting the RI-RSVP-FRR extensions initiate
such a node on the path of a protected LSP can determine whether Node-ID-based signaling adjacency with all immediate neighbors,
its Phop and Nhop neighbors support RI-RSVP-FRR enhancements. such a node on the path of a protected LSP can determine whether
</t> its Phop and Nhop neighbors support RI-RSVP-FRR enhancements.</li>
</list>
<list style="hanging">
<t hangText="-">As nodes supporting the RI-RSVP-FRR extensions also initi
ate
Node-ID based signaling adjacency with the NNhop along the path of
the LSP requested node protection (see <xref target="sig_plr_behav
ior"/> 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 f
lag
in the CAPABILITY object carried in its Node-ID Hello messages, th
en
the node acting as the PLR can conclude that NNhop does not suppor
t
RI-RSVP-FRR extensions.
</t>
</list>
<list style="hanging">
<t hangText="-">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 (b) the PPhop node has
not initiated remote Node-ID Hello messages or (c) the PPhop node
does not set the RI-RSVP flag in the CAPABILITY object carried
in its Node-ID Hello messages, then the node MUST conclude
that the PLR does not support RI-RSVP-FRR extensions.
</t>
</list>
</t>
</section>
<section anchor="compat_procedures" title="Procedures for Backward Compatib <li>As nodes supporting the RI-RSVP-FRR extensions also initiate
ility"> Node-ID-based signaling adjacency with the NNhop along the path of
<t>Every node that supports RI-RSVP-FRR MUST support the procedures define the LSP requesting node protection (see <xref
d 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.</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, (b) the PPhop node has
not initiated remote Node-ID Hello messages, or (c) the PPhop node
does not set the RI-RSVP flag in the CAPABILITY object carried in
its Node-ID Hello messages, then the node <bcp14>MUST</bcp14>
conclude that the PLR does not support RI-RSVP-FRR
extensions.</li>
</ul>
</section>
<section anchor="compat_procedures">
<name>Procedures for Backward Compatibility</name>
<t>Every node that supports RI-RSVP-FRR <bcp14>MUST</bcp14> support th
e procedures defined
in this section in order to support backward compatibility for in this section in order to support backward compatibility for
those subset of LSPs that also traverse nodes that do not support those subsets of LSPs that also traverse nodes that do not support
RI-RSVP-FRR. RI-RSVP-FRR.
</t> </t>
<section anchor="dnstr_no_support" title="Lack of support on Downstream No
de">
<t>The procedures on the downstream direction are as follows.
<list style="hanging">
<t hangText="-">If a node finds that the Nhop node along the LSP does not
support the RI-RSVP-FRR extensions, then the node MUST reduce
the &quot;refresh period&quot; in the TIME_VALUES object carried
in the Path messages to the default short refresh interval.
</t>
</list>
<list style="hanging">
<t hangText="-">If node protection is requested for the LSP and the NNhop
node along the LSP path does not support the RI-RSVP-FRR extensio
ns,
then the node MUST reduce the &quot;refresh period&quot; in the
TIME_VALUES object carried in the Path messages to the default sh
ort
refresh interval.
</t>
</list>
</t>
<t>If a node reduces the refresh time using the above procedures, it
MUST NOT send any &quot;Remote&quot; PathTear or Conditional PathTear
message to the downstream 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 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 B is not an MP and if Phop link of B fails, B
cannot send Conditional PathTear to C but times out the PSB
state from A normally. Note that B can time out the PSB state
A normally only if A did not set long refresh in the TIME_VALUES
object carried in the Path messages sent earlier.
</t>
</list>
</t>
</section>
<section anchor="upstr_no_support" title="Lack of support on Upstream Node <section anchor="dnstr_no_support">
"> <name>Lack of Support on Downstream Nodes</name>
<t>The procedures are as follows.
<list style="hanging">
<t hangText="-">If a node finds that the Phop node along the LSP path doe
s
not support the RI-RSVP-FRR extensions, then the node MUST reduce
the &quot;refresh period&quot; in the TIME_VALUES object carried
in
the Resv messages to the default short refresh interval.
</t>
</list>
<list style="hanging">
<t hangText="-">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 reduce the &quot;refresh
period&quot; 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 node protection is requested for the LSP and the
PPhop node does not support the RI-RSVP-FRR extensions, then
the node MUST reduce the &quot;refresh period&quot; in the
TIME_VALUES object carried in the Resv messages to the default
short refresh interval.
</t>
</list>
<list style="hanging">
<t hangText="-">If the node reduces the refresh time using the above
procedures, it MUST NOT execute MP procedures specified in
<xref target="failures"/> of this document.
</t>
</list>
</t>
</section>
<section anchor="incr_deploy" title="Incremental Deployment"> <t>The procedures on the downstream direction are as follows:</t>
<t>The backward compatibility procedures described in the previous <ul>
sub-sections imply that a router supporting the RI-RSVP-FRR <li>If a node finds that the Nhop node along the LSP does not
support the RI-RSVP-FRR extensions, then the node
<bcp14>MUST</bcp14> reduce the "refresh period" in the
TIME_VALUES object carried in the Path messages to the default
short refresh interval.</li>
<li>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 <bcp14>MUST</bcp14> reduce the
"refresh period" in the TIME_VALUES object carried in the Path
messages to the default short refresh interval.</li>
</ul>
<t>If a node reduces the refresh time using the above procedures,
it <bcp14>MUST NOT</bcp14> send any "Remote" PathTear or
Conditional PathTear message to the downstream node.</t>
<t>Consider the example topology in <xref
target="example_network"/>. If C does not support the RI-RSVP-FRR
extensions, 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.</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 s
tate A
if A did not set the long refresh in the TIME_VALUES
object carried in the Path messages sent earlier.</li>
</ul>
</section>
<section anchor="upstr_no_support">
<name>Lack of Support on Upstream 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.
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
<bcp14>MUST</bcp14> reduce the "refresh period" in the
TIME_VALUES object carried in the Resv messages to the default
short refresh interval.</li>
<li>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 <bcp14>MUST</bcp14> reduce the
"refresh period" in the TIME_VALUES object carried in the Path
messages to the default short refresh interval (thus, the Nhop
can use compatible values when sending a Resv).</li>
<li>If node protection is requested for the LSP and the PPhop
node does not support the RI-RSVP-FRR extensions, then the node
<bcp14>MUST</bcp14> reduce the "refresh period" in the
TIME_VALUES object carried in the Resv messages to the default
short refresh interval.</li>
<li>If the node reduces the refresh time using the above
procedures, it <bcp14>MUST NOT</bcp14> execute MP procedures
specified in <xref target="failures"/> of this document.</li>
</ul>
</section>
<section anchor="incr_deploy">
<name>Incremental Deployment</name>
<t>The backward compatibility procedures described in the previous
subsections imply that a router supporting the RI-RSVP-FRR
extensions specified in this document can apply the procedures extensions specified in this document can apply the procedures
specified in the document either in the downstream or upstream specified in this document either in the downstream or upstream
direction of an LSP, depending on the capability of the routers direction of an LSP, depending on the capability of the routers
downstream or upstream in the LSP path. downstream or upstream in the LSP path.
<list style="hanging"> </t>
<t hangText="-">RI-RSVP-FRR extensions and procedures are enabled for
downstream Path, PathTear and ResvErr messages corresponding <ul>
<li>RI-RSVP-FRR extensions and procedures are enabled for
downstream Path, PathTear, and ResvErr messages corresponding
to an LSP if link protection is requested for the LSP and the to an LSP if link protection is requested for the LSP and the
Nhop node supports the extensions Nhop node supports the extensions.</li>
</t>
</list> <li>RI-RSVP-FRR extensions and procedures are enabled for
<list style="hanging"> downstream Path, PathTear, and ResvErr messages corresponding
<t hangText="-">RI-RSVP-FRR extensions and procedures are enabled for
downstream Path, PathTear and ResvErr messages corresponding
to an LSP if node protection is requested for the LSP and both to an LSP if node protection is requested for the LSP and both
Nhop &amp; NNhop nodes support the extensions Nhop and NNhop nodes support the extensions.</li>
</t>
</list> <li>RI-RSVP-FRR extensions and procedures are enabled for
<list style="hanging"> upstream PathErr, Resv, and ResvTear messages corresponding to an
<t hangText="-">RI-RSVP-FRR extensions and procedures are enabled for LSP if link protection is requested for the LSP and the Phop
upstream PathErr, Resv and ResvTear messages corresponding to node supports the extensions.</li>
an LSP if link protection is requested for the LSP and the
Phop node supports the extensions <li>RI-RSVP-FRR extensions and procedures are enabled for
</t> upstream PathErr, Resv, and ResvTear messages corresponding to an
</list> LSP if node protection is requested for the LSP and both Phop
<list style="hanging"> and PPhop nodes support the extensions.</li>
<t hangText="-">RI-RSVP-FRR extensions and procedures are enabled for </ul>
upstream PathErr, Resv and ResvTear messages corresponding to
an LSP if node protection is requested for the LSP and both <t>For example, if an implementation supporting the RI-RSVP-FRR
Phop and the PPhop support the extensions extensions specified in this document is deployed on all routers in a
</t>
</list>
</t>
<t>For example, if an implementation supporting the RI-RSVP-FRR
extensions specified in this document is deployed on all routers in
particular region of the network and if all the LSPs in the network particular region of the network and if all the LSPs in the network
request node protection, then the FRR extensions will only be request node protection, then the FRR extensions will only be
applied for the LSP segments that traverse the particular region. applied for the LSP segments that traverse the particular region.
This will aid incremental deployment of these extensions and also This will aid incremental deployment of these extensions and also
allow reaping the benefits of the extensions in portions of the allow reaping the benefits of the extensions in portions of the
network where it is supported. network where it is supported.
</t> </t>
</section>
</section>
</section> </section>
</section> <section anchor="cap_bit_without_support">
</section> <name>Consequences of Advertising RI-RSVP Without RI-RSVP-FRR</name>
<t>If a node supporting facility backup protection <xref target="RFC4090
<section anchor="cap_bit_without_support" title="Consequence of Advertisin "/>
g RI-RSVP without RI-RSVP-FRR"> sets the RI-RSVP capability (I-bit) but does not support the RI-RSVP-FR
<t>If a node supporting facility backup protection <xref target="RFC4090" R
/>
sets the RI-RSVP capability (I bit) but does not support the RI-RSVP-FR
R
extensions, due to an implementation bug or configuration error, then it extensions, due to an implementation bug or configuration error, then it
leaves room for stale state to linger around for an inordinate period leaves room for the stale state to linger around for an inordinate per
of iod of
time or disruption of normal FRR operation time or for disruption of normal FRR operations
(see <xref target="prob_desc"/> of this document). Consider the example (see <xref target="prob_desc"/> of this document). Consider the example
topology <xref target="example_network"/> provided in this document. topology (<xref target="example_network"/>) provided in this document.
<list style="hanging"> </t>
<t hangText="-">Assume node B does set RI-RSVP capability in its Node-ID
based Hello messages even though it does not support RI-RSVP-FRR
extensions. When B detects the failure of its Phop link along an
LSP, it will not send 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 of node B, assume node C does set RI-RSVP
capability in its Node-id based Hello messages even though it
does not support RI-RSVP-FRR extensions. When B details the
failure of its Phop link along an LSP, it will send Conditional
PathTear to C as required by the RI-RSVP-FRR procedures. But,
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 node B does set RI-RSVP capability in its Node-ID
based Hello messages even though it does not support RI-RSVP-FRR
extensions. Also assume local repair is about to commence on node
B for an LSP that has only requested link protection. That is,
B has not initiated the backup LSP signaling for the LSP. If node
B
receives a normal PathTear at this time from ingress A because of
a
management event initiated on A, then B simply deletes the LSP
state without sending a Remote PathTear to the LP-MP C. So, C
may end up holding on to the stale state until the (long) refresh
timeout.
</t>
</list>
</t>
</section>
</section> <ul>
<li>Assume node B does set the RI-RSVP capability in its Node-ID-based
Hello messages even though it does not support RI-RSVP-FRR
extensions. When B detects the failure of its Phop link along an
LSP, it will not send a Conditional PathTear to C as required by the
RI-RSVP-FRR procedures. If B simply leaves the LSP state without
deleting, then B may end up holding on to the stale state until the
(long) refresh timeout.</li>
<section anchor="Security" title="Security Considerations"> <li>Instead of node B, assume node C does set the RI-RSVP capability i
<t>The security considerations pertaining to the original RSVP protocol n
<xref target="RFC2205"/>, <xref target="RFC3209"/> and <xref target="RF its Node-ID-based Hello messages even though it does not support
C5920"/> RI-RSVP-FRR extensions. When B details the failure of its Phop link
remain relevant. When using RSVP Cryptographic Authentication along an LSP, it will send a Conditional PathTear to C as required by
the RI-RSVP-FRR procedures. However, C would not recognize the conditi
on
encoded in the PathTear and end up tearing down the LSP.</li>
<li>Assume node B does set the RI-RSVP capability in its Node-ID-based
Hello messages even though it does not support RI-RSVP-FRR
extensions. In addition, assume local repair is about to commence on n
ode B
for an LSP that has only requested link protection, that is, B has
not initiated the backup LSP signaling for the LSP. If node B
receives a normal PathTear at this time from ingress A because of a
management event initiated on A, then B simply deletes the LSP state
without sending a Remote PathTear to the LP-MP C, so C may end up
holding on to the stale state until the (long) refresh timeout.</li>
</ul>
</section>
</section>
<section anchor="Security">
<name>Security Considerations</name>
<t>The security considerations pertaining to the original RSVP protocols
(<xref target="RFC2205"/>, <xref target="RFC3209"/>, and <xref target="
RFC5920"/>)
remain relevant. When using RSVP cryptographic authentication
<xref target="RFC2747"/>, more robust algorithms such as HMAC-SHA256, <xref target="RFC2747"/>, more robust algorithms such as HMAC-SHA256,
HMAC-SHA384, or HMAC-SHA512 <xref target="RFC2104"/><xref target="FIPS-1 HMAC-SHA384, or HMAC-SHA512 <xref target="RFC2104"/> <xref target="FIPS-
80-4"/> 180-4"/>
SHOULD be used when computing the keyed message digest where possible. <bcp14>SHOULD</bcp14> be used when computing the keyed message digest wh
ere possible.
</t> </t>
<t>This document extends the applicability of Node-ID based Hello session <!-- [rfced] For clarity, may we update the text below as follows?
between immediate neighbors. The Node-ID based Hello session between the P
LR Original:
and the NP-MP may require the two routers to exchange Hello messages with
non-immediate neighbor. So, the implementations SHOULD provide the So, the implementations
option to configure Node-ID neighbor specific or global authentication SHOULD provide the option to configure Node-ID neighbor specific or
key to authentication messages received from Node-ID neighbors. The global authentication key to authentication messages received from
network administrator SHOULD utilize this option to enable RSVP-TE routers Node-ID neighbors.
to authenticate Node-ID Hello messages received with TTL greater than 1.
Implementations SHOULD also provide the option to specify a limit on the Perhaps:
number of Node-ID based Hello sessions that can be established on a
router supporting the extensions defined in this document. 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 Hello
sessions between immediate neighbors. The Node-ID-based Hello session
between the PLR and the NP-MP may require the two routers to exchange
Hello messages with a non-immediate neighbor. Therefore, the
implementations <bcp14>SHOULD</bcp14> provide the option to configure a
Node-ID neighbor specific or global authentication key to authentication
messages received from Node-ID neighbors. The network administrator
<bcp14>SHOULD</bcp14> utilize this option to enable RSVP-TE routers to
authenticate Node-ID Hello messages received with a TTL greater than 1.
Implementations <bcp14>SHOULD</bcp14> also provide the option to specify
a limit on the number of Node-ID-based Hello sessions that can be
established on a router supporting the extensions defined in this
document.
</t> </t>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA">
<section anchor="IANA_Conditions" title="CONDITIONS Object"> <name>IANA Considerations</name>
<t>IANA maintains the Class Names, Class Numbers, and Class Types registr <section anchor="IANA_Conditions">
ies <name>CONDITIONS Object</name>
in the &quot;RSVP parameters&quot; registry group (see <t>IANA maintains the "Class Names, Class Numbers, and Class Types" regi
http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). stry
IANA is requested to extend these registries by adding a new Class Num in the "RSVP Parameters" registry group (see
ber <eref target="http://www.iana.org/assignments/rsvp-parameters/"/>).
(in the 10bbbbbb range) and assign a new C-Type under this Class Numbe IANA has extended these registries by adding a new Class Number
r, (in the 10bbbbbb range) and assigning a new C-Type under this Class Nu
mber,
as described below (see <xref target="cnd_path_tear_obj"/>): as described below (see <xref target="cnd_path_tear_obj"/>):
</t>
<artwork> <table anchor="table1">
<![CDATA[ <name>Class Names, Class Numbers, and Class Types</name>
Class Number Class Name Reference <thead>
TBA1 CONDITIONS This document <tr>
]]> <th>Class Number</th>
</artwork> <th>Class Name</th>
<th>Reference</th>
<t>Class Type of C-types - TBA1 CONDITIONS </t> </tr>
</thead>
<tbody>
<tr>
<td>135</td>
<td>CONDITIONS</td>
<td>RFC 9705</td>
</tr>
</tbody>
</table>
<artwork> <table anchor="table2">
<![CDATA[ <name>Class Type or C-Types - 135 CONDITIONS</name>
Value Class Name Reference <thead>
1 CONDITIONS This document <tr>
]]> <th>Value</th>
</artwork> <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 has added a subregistry called "CONDITIONS Object
Flags" as shown below. Assignments of additional Class Type values
for Class Name "CONDITIONS" are to be performed via
"IETF Review" <xref target="RFC8126"/>.</t>
<t>IANA is requested to add a new sub-registry for &quot;CONDITIONS Objec <table anchor="table3">
t <name>CONDITIONS Object Flags</name>
Flags&quot; as shown below. Assignments of additional Class Type values <thead>
for Class Name &quot;CONDITIONS&quot; are to be performed via <tr>
&quot;IETF Review&quot; <xref target="RFC8126"/>.</t> <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>
<artwork> <t>All assignments in this subregistry are to be performed via "IETF
<![CDATA[ Review" <xref target="RFC8126"/>.</t>
Bit Number 32-bit Value Name Reference
0-30 Unassigned
31 0x0001 Merge-point This document
]]>
</artwork>
<t>All assignments in this sub-registry are to be performed via </section>
&quot;IETF Review&quot; <xref target="RFC8126"/>.</t>
</t>
</section> </section>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the </middle>
text output. --> <back>
<?rfc needLines="8" ?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<section anchor="Acknowledgements" title="Acknowledgements"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<t>We are very grateful to Yakov Rekhter for his contributions to the 119.xml"/>
development of the idea and thorough review of content of the draft. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
We are thankful to Raveendra Torvi and Yimin Shen for their comments 747.xml"/>
and inputs on early versions of the draft. We also thank Alexander <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
Okonnikov for his review and comments on the draft. 209.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
090.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
961.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
205.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
558.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
473.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
063.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
370.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
796.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</orga
nization>
</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.2
104.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
920.xml"/>
</references>
</references>
<section anchor="Acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>We are very grateful to <contact fullname="Yakov Rekhter"/> for his
contributions to the development of the idea and thorough review of the
content of the document. We are thankful to <contact fullname="Raveendra
Torvi"/> and <contact fullname="Yimin Shen"/> for their comments and
inputs on early versions of the document. We also thank <contact
fullname="Alexander Okonnikov"/> for his review and comments on the
document.
</t> </t>
</section> </section>
<!-- Possibly a 'Contributors' section ... --> <section anchor="Contributors" numbered="false">
<name>Contributors</name>
<section anchor="Contributors" title="Contributors"> <contact fullname="Markus Jork">
<t> <organization>Juniper Networks, Inc.</organization>
Markus Jork<br></br> <address>
Juniper Networks, Inc.<br></br> <email>mjork@juniper.net</email>
Email: mjork@juniper.net </address>
</t> </contact>
<t> <contact fullname="Harish Sitaraman">
Harish Sitaraman<br></br> <organization>Individual Contributor</organization>
Individual Contributor<br></br> <address>
Email: harish.ietf@gmail.com <email>harish.ietf@gmail.com</email>
</t> </address>
</contact>
<t> <contact fullname="Vishnu Pavan Beeram">
Vishnu Pavan Beeram<br></br> <organization>Juniper Networks, Inc.</organization>
Juniper Networks, Inc.<br></br> <address>
Email: vbeeram@juniper.net <email>vbeeram@juniper.net</email>
</t> </address>
</contact>
<t> <contact fullname="Ebben Aries">
Ebben Aries<br></br> <organization>Juniper Networks, Inc.</organization>
Juniper Networks, Inc.<br></br> <address>
Email: exa@juniper.com <email>exa@juniper.com</email>
</t> </address>
</contact>
<t> <contact fullname="Mike Taillon">
Mike Taillon<br></br> <organization>Cisco Systems, Inc.</organization>
Cisco Systems, Inc.<br></br> <address>
Email: mtaillon@cisco.com <postal/>
</t> <email>mtaillon@cisco.com</email>
</address>
</contact>
</section>
</section> </back>
</rfc>
</middle> <!-- [rfced] Please review the following questions and changes regarding the
terminology used in this document.
<back> a) We note some instances where "RSVP" is not included in "Refresh-Interval
<!-- References split into informative and normative --> Independent FRR" (in the document title and elsewhere). For consistency,
should "RSVP" be added to these instances? Some examples are listed below.
<!-- There are 2 ways to insert reference entries from the citation libraries Original:
: 4.6.1. Detecting Support for Refresh interval Independent FRR
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( ...
as shown) "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml of procedures defined in this document to...
"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
ml")
Both are cited textually in the same manner: by using xref elements. Perhaps:
If you use the PI option, xml2rfc will, by default, try to find included fil 4.6.1. Detecting Support for Refresh-Interval Independent RSVP FRR
es in the same ...
directory as the including file. You can also define the XML_LIBRARY environ "Refresh-Interval Independent RSVP FRR", or RI-RSVP-FRR, refers to the set
ment variable of procedures defined in this document to...
with a value containing a set 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"> b) To parallel usage in RFC 4090, may we update the capitalization of the terms
&RFC2119; below
&RFC2747; throughout this document?
&RFC3209;
&RFC4090;
&RFC2961;
&RFC2205;
&RFC4558;
&RFC3473;
&RFC5063;
&RFC8126;
&RFC8174;
&RFC8370;
&RFC8796;
</references>
<references title="Informative References"> Phop > PHOP
<reference anchor="FIPS-180-4"> PPhop > PPHOP
<front> Nhop > NHOP
<title>Secure Hash Standard</title> NNhop > NNHOP
<author>
<organization>National Institute of Standards and Technology</organizati
on>
</author>
<date month="August" year="2015"/>
</front>
<seriesInfo name="FIPS" value="180-4"/>
</reference>
&RFC2104;
&RFC5920;
</references>
</back> c) To parallel usage in RFC 8796, may we update the capitalization of the terms
</rfc> below
throughout this document?
Association source > Association Source
B-SFRR-Ready Extended Association object > B-SFRR-Ready Extended ASSOCIATION ob
ject
d) Should instances of "RRO object" and "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. -->
 End of changes. 187 change blocks. 
1429 lines changed or deleted 1510 lines changed or added

This html diff was produced by rfcdiff 1.48.