draft-ietf-mpls-ri-rsvp-frr-08.txt   draft-ietf-mpls-ri-rsvp-frr-09.txt 
MPLS Working Group C. Ramachandran MPLS Working Group C. Ramachandran
Internet-Draft T. Saad Internet-Draft T. Saad
Updates: 4090 (if approved) Juniper Networks, Inc. Updates: 4090 (if approved) Juniper Networks, Inc.
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: May 21, 2021 Google, Inc. Expires: May 26, 2021 Google, Inc.
D. Pacella D. Pacella
Verizon, Inc. Verizon, Inc.
November 17, 2020 November 22, 2020
Refresh-interval Independent FRR Facility Protection Refresh-interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-08 draft-ietf-mpls-ri-rsvp-frr-09
Abstract Abstract
RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two
local repair techniques to reroute Label Switched Path (LSP) traffic local repair techniques to reroute Label Switched Path (LSP) traffic
over pre-established backup tunnel. Facility backup method allows over pre-established backup tunnel. Facility backup method allows
one or more LSPs traversing a connected link or node to be protected 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 using a bypass tunnel. The many-to-one nature of local repair
technique is attractive from scalability point of view. This technique is attractive from scalability point of view. This
document enumerates facility backup procedures in RFC 4090 that rely document enumerates facility backup procedures in RFC 4090 that rely
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 21, 2021. This Internet-Draft will expire on May 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5
4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7 4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP
Capability . . . . . . . . . . . . . . . . . . . . . . . 8 Capability . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Signaling Handshake between PLR and MP . . . . . . . . . 8 4.2. Signaling Handshake between PLR and MP . . . . . . . . . 9
4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 8 4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10 4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10
4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10
4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 11 4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 11
4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12 4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12
4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12 4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12
4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 12 4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13
4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13
4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 14 4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 14
4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15 4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15
4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15 4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15
4.4.2. Processing Conditional PathTear . . . . . . . . . . . 15 4.4.2. Processing Conditional PathTear . . . . . . . . . . . 15
4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16 4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16
4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 16 4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 17
4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 17 4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 17
4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 17 4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 17
4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18 4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18
4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 18 4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 18
4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 18 4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 18
4.6. Backward Compatibility Procedures . . . . . . . . . . . . 19 4.6. Backward Compatibility Procedures . . . . . . . . . . . . 19
4.6.1. Detecting Support for Refresh interval Independent 4.6.1. Detecting Support for Refresh interval Independent
FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19 FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.2. Procedures for Backward Compatibility . . . . . . . . 20 4.6.2. Procedures for Backward Compatibility . . . . . . . . 20
4.6.2.1. Lack of support on Downstream Node . . . . . . . 20 4.6.2.1. Lack of support on Downstream Node . . . . . . . 20
4.6.2.2. Lack of support on Upstream Node . . . . . . . . 20 4.6.2.2. Lack of support on Upstream Node . . . . . . . . 21
4.6.2.3. Incremental Deployment . . . . . . . . . . . . . 21 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 4.6.2.4. Incremental Deployment . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 23
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. CONDITIONS Flags . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
RSVP-TE relies on periodic refresh of RSVP messages to synchronize RSVP-TE relies on periodic refresh of RSVP messages to synchronize
and maintain the Label Switched Path (LSP) related states along the and maintain the Label Switched Path (LSP) related states along the
reserved path. In the absence of refresh messages, the LSP-related reserved path. In the absence of refresh messages, the LSP-related
states are automatically deleted. Reliance on periodic refreshes and states are automatically deleted. Reliance on periodic refreshes and
refresh timeouts are problematic from the scalability point of view. refresh timeouts are problematic from the scalability point of view.
The number of RSVP-TE LSPs that a router needs to maintain has been The number of RSVP-TE LSPs that a router needs to maintain has been
growing in service provider networks and the implementations should growing in service provider networks and the implementations should
skipping to change at page 4, line 47 skipping to change at page 4, line 47
combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this
dependency on refresh timeouts for stale state cleanup. dependency on refresh timeouts for stale state cleanup.
The procedures specified in this document assume reliable delivery of The procedures specified in this document assume reliable delivery of
RSVP messages, as specified in [RFC2961]. Therefore this document RSVP messages, as specified in [RFC2961]. Therefore this document
makes support for [RFC2961] a pre-requisite. makes support for [RFC2961] a pre-requisite.
2. Terminology 2. Terminology
The reader is expected to be familiar with the terminology in The reader is expected to be familiar with the terminology in
[RFC2205], [RFC3209], [RFC4090] and [RFC4558]. [RFC2205], [RFC3209], [RFC4090], [RFC4558], [RFC8370] and [RFC8796].
Phop node: Previous-hop router along the label switched path Phop node: Previous-hop router along the label switched path
PPhop node: Previous-Previous-hop router along the label switched PPhop node: Previous-Previous-hop router along the label switched
path path
Nhop node: Next-hop router along the label switched path Nhop node: Next-hop router along the label switched path
NNhop node: Next-Next-hop router along the label switched path NNhop node: Next-Next-hop router along the label switched path
PLR: Point of Local Repair router as defined in [RFC4090] PLR: Point of Local Repair router as defined in [RFC4090]
skipping to change at page 5, line 24 skipping to change at page 5, line 24
NP-MP node: Merge Point router at the tail of Node-Protecting bypass NP-MP node: Merge Point router at the tail of Node-Protecting bypass
tunnel tunnel
TED: Traffic Engineering Database TED: Traffic Engineering Database
LSP state: The combination of "path state" maintained as Path State LSP state: The combination of "path state" maintained as Path State
Block (PSB) and "reservation state" maintained as Reservation State Block (PSB) and "reservation state" maintained as Reservation State
Block (RSB) forms an individual LSP state on an RSVP-TE speaker Block (RSB) forms an individual LSP state on an RSVP-TE speaker
RI-RSVP: The set of procedures defined in Section 3 of RSVP-TE
Scaling Techniques [RFC8370] to eliminate RSVP's reliance on periodic
message refreshes
B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object
defined in Summary FRR extensions [RFC8796] and is added by the PLR defined in Summary FRR extensions [RFC8796] and is added by the PLR
for each protected LSP. for each protected LSP.
RI-RSVP-FRR: The set of procedures defined in this document to
elimiate RSVP's reliance of periodic message refreshes when
supporting facility backup protection [RFC4090]
Conditional PathTear: A PathTear message containing a suggestion to a Conditional PathTear: A PathTear message containing a suggestion to a
receiving downstream router to retain the path state if the receiving receiving downstream router to retain the path state if the receiving
router is an NP-MP router is an NP-MP
Remote PathTear: A PathTear message sent from a Point of Local Repair Remote PathTear: A PathTear message sent from a Point of Local Repair
(PLR) to the MP to delete LSP state on the MP if PLR had not reliably (PLR) to the MP to delete the LSP state on the MP if PLR had not
sent the backup Path state before previously sent the backup Path state reliably
3. Problem Description 3. Problem Description
E E
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
A ----- B ----- C ----- D A ----- B ----- C ----- D
skipping to change at page 8, line 21 skipping to change at page 8, line 21
- Handle upstream link or node failures by cleaning up LSP states if - Handle upstream link or node failures by cleaning up LSP states if
the node has not found itself as an MP through the MP the node has not found itself as an MP through the MP
determination mechanism. See section 4.3 for more details. determination mechanism. See section 4.3 for more details.
- Introduce extensions to enable a router to send a tear down - Introduce extensions to enable a router to send a tear down
message to the downstream router that enables the receiving router message to the downstream router that enables the receiving router
to conditionally delete its local LSP state. See section 4.4 for to conditionally delete its local LSP state. See section 4.4 for
more details. more details.
- Enhance facility protection by allowing a PLR to directly send a - Enhance facility backup protection by allowing a PLR to directly
tear down message to the MP without requiring the PLR to either send a tear down message to the MP without requiring the PLR to
have a working bypass LSP or have already signaled backup LSP either have a working bypass LSP or have already signaled backup
state. See section 4.5 for more details. LSP state. See section 4.5 for more details.
- Introduce extensions to enable the above procedures to be backward - Introduce extensions to enable the above procedures to be backward
compatible with routers along the LSP path running implementation compatible with routers along the LSP path running implementation
that do not support these procedures. See section 4.6 for more that do not support these procedures. See section 4.6 for more
details. details.
4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP
Capability Capability
A node supporting [RFC4090] facility protection FRR MAY set the RI- A node supporting facility backup protection [RFC4090] MAY set the
RSVP capability (I bit) defined in Section 3 of RSVP-TE Scaling RI-RSVP capability (I bit) defined in Section 3.1 of RSVP-TE Scaling
Techniques [RFC8370] only if it supports all the extensions specified Techniques [RFC8370] only if it supports all the extensions specified
in the rest of this document. A node supporting [RFC4090] facility in the rest of this document. A node supporting facility backup
bypass FRR but not supporting the extensions specified in this protection [RFC4090] but not supporting the extensions specified in
document MUST reset the RI-RSVP capability (I bit) in the outgoing this document MUST NOT set the RI-RSVP capability (I bit) in the
Node-ID based Hello messages. Hence, this document updates [RFC4090] outgoing Node-ID based Hello messages. Hence, this document updates
by defining extensions and additional procedures over facility RFC 4090 by defining extensions and additional procedures over
protection FRR defined in [RFC4090] in order to advertise RI-RSVP facility backup protection [RFC4090] in order to advertise RI-RSVP
capability [RFC8370]. capability [RFC8370]. However, if a node supporting facility backup
protection [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 leaves room for stale state to linger around for an
inordinate period of time given the long refresh intervals
recommended by RFC 8370 or disruption of normal FRR operation.
Procedures for backward compatibility Section 4.6.2.3 delves on this
in detail.
4.2. Signaling Handshake between PLR and MP 4.2. Signaling Handshake between PLR and MP
4.2.1. PLR Behavior 4.2.1. PLR Behavior
As per the procedures specified in [RFC4090], when a protected LSP As per the facility backup procedures [RFC4090], when an LSP becomes
comes up and if the "local protection desired" flag is set in the operational on a node and the "local protection desired" flag has
SESSION_ATTRIBUTE object, each node along the LSP path attempts to been set in the SESSION_ATTRIBUTE object carried in the Path message
make local protection available for the LSP. corresponding to the LSP, then the node attempts to make local
protection available for the LSP.
- If the "node protection desired" flag is set, then the node tries - If the "node protection desired" flag is set, then the node tries
to become a PLR by attempting to create a NP-bypass LSP to the to become a PLR by attempting to create a NP-bypass LSP to the
NNhop node avoiding the Nhop node on protected LSP path. In case NNhop node avoiding the Nhop node on protected LSP path. In case
node protection could not be made available, the node attempts to node protection could not be made available, the node attempts to
create an LP-bypass LSP to the Nhop node avoiding only the link create an LP-bypass LSP to the Nhop node avoiding only the link
that the protected LSP takes to reach Nhop that the protected LSP takes to reach the Nhop
- If the "node protection desired" flag is not set, then the PLR - 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 attempts to create an LP-bypass LSP to the Nhop node avoiding the
link that the protected LSP takes to reach the Nhop link that the protected LSP takes to reach the Nhop
With regard to the PLR procedures described above and that are With regard to the PLR procedures described above and that are
specified in [RFC4090], this document specifies the following specified in RFC 4090, this document specifies the following
additional procedures to support RI-RSVP defined in [RFC8370]. additional procedures to support RI-RSVP [RFC8370].
- While selecting the destination address of the bypass LSP, the PLR - While selecting the destination address of the bypass LSP, the PLR
SHOULD select the router ID of the NNhop or Nhop node from the MUST select the router ID of the NNhop or Nhop node from the Node-
Node-ID sub-object included in the RRO object carried in the Resv ID sub-object included in the RRO object carried in the most
message. If the MP has not included a Node-ID sub-object in the recent Resv message corresponding to the LSP. If the MP has not
Resv RRO and if the PLR and the MP are in the same area, then the included a Node-ID sub-object in the Resv RRO and if the PLR and
PLR may utilize the TED to determine the router ID corresponding the MP are in the same area, then the PLR may utilize the TED to
to the interface address included by the MP in the RRO object. If determine the router ID corresponding to the interface address
the NP-MP in a different IGP area has not included a Node-ID sub- included by the MP in the RRO object. If the NP-MP in a different
object in RRO object, then the PLR MUST execute backward IGP area has not included a Node-ID sub-object in RRO object, then
compatibility procedures as if the downstream nodes along the LSP the PLR MUST execute backward compatibility procedures as if the
do not support the extensions defined in the document (see downstream nodes along the LSP do not support the extensions
Section 4.6.2.1). defined in the document (see Section 4.6.2.1).
- The PLR MUST also include its router ID in a Node-ID sub-object in - The PLR MUST also include its router ID in a Node-ID sub-object in
RRO object carried in a Path message. While including its router RRO object carried in any subsequent Path message corresponding to
ID in the Node-ID sub-object carried in the outgoing Path message, the LSP. While including its router ID in the Node-ID sub-object
the PLR MUST include the Node-ID sub-object after including its carried in the outgoing Path message, the PLR MUST include the
IPv4/IPv6 address or unnumbered interface ID sub-object. Node-ID sub-object after including its IPv4/IPv6 address or
unnumbered interface ID sub-object.
- In parallel to the attempt made to create NP-bypass or LP-bypass, - 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 the PLR MUST initiate a Node-ID based Hello session to the NNhop
or Nhop node respectively to establish the RSVP-TE signaling or Nhop node respectively along the LSP to establish the RSVP-TE
adjacency. This Hello session is used to detect MP node failure signaling adjacency. This Hello session is used to detect MP node
as well as determine the capability of the MP node. If the MP has failure as well as determine the capability of the MP node. If
set the I-bit in the CAPABILITY object [RFC8370] carried in Hello the MP has set the I-bit in the CAPABILITY object [RFC8370]
message corresponding to the Node-ID based Hello session, then the carried in Hello message corresponding to the Node-ID based Hello
PLR SHOULD conclude that the MP supports refresh-interval session, then the PLR MUST conclude that the MP supports refresh-
independent FRR procedures defined in this document. If the MP interval independent FRR procedures defined in this document. If
has not sent Node-ID based Hello messages or has not set the I-bit the MP has not sent Node-ID based Hello messages or has not set
in CAPABILITY object [RFC8370], then the PLR MUST execute backward the I-bit in CAPABILITY object [RFC8370], then the PLR MUST
compatibility procedures defined in Section 4.6.2.1 of this execute backward compatibility procedures defined in
document. Section 4.6.2.1 of this document.
- If the bypass LSP comes up and the PLR has made local protection - When the PLR associates a bypass to a protected LSP, it MUST
available for one or more LSPs, then RSVP-TE Summary FRR [RFC8796] include a B-SFRR-Ready Extended Association object [RFC8796] and
applies: the PLR MUST include B-SFRR-Ready Extended Association trigger a Path message to be sent for the LSP. If a B-SFRR-Ready
object and trigger a Path message to be sent for those LSPs. If a Extended Association object is included in the Path message
B-SFRR-Ready Extended Association object is included in the Path corresponding to the LSP, the encoding and object ordering rules
message, then the encoding and object ordering rules specified in specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. In
RSVP-TE Summary FRR [RFC8796] MUST be followed. addition to those rules, the PLR MUST set the Association Source
in the object to its Node-ID address.
4.2.2. Remote Signaling Adjacency 4.2.2. Remote Signaling Adjacency
A Node-ID based RSVP-TE Hello session is one in which Node-ID is used A Node-ID based RSVP-TE Hello session is one in which Node-ID is used
in the source and the destination address fields of RSVP Hello in the source and the destination address fields of RSVP Hello
messages [RFC4558]. This document extends Node-ID based RSVP Hello messages [RFC4558]. This document extends Node-ID based RSVP Hello
session to track the state of any RSVP-TE neighbor that is not session to track the state of any RSVP-TE neighbor that is not
directly connected by at least one interface. In order to apply 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 session 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 Node-ID defined in the document MUST set TTL to 255 in all outgoing Node-ID
based Hello messages exchanged between the PLR and the MP. The based Hello messages exchanged between the PLR and the MP. The
default hello interval for this Node-ID hello session SHOULD be set default hello interval for this Node-ID hello session MUST be set to
to the default specified in RSVP-TE Scaling Techniques [RFC8370]. the default specified in RSVP-TE Scaling Techniques [RFC8370].
In the rest of the document the term "signaling adjacency", or In the rest of the document the term "signaling adjacency", or
"remote signaling adjacency" refers specifically to the RSVP-TE "remote signaling adjacency" refers specifically to the RSVP-TE
signaling adjacency. signaling adjacency.
4.2.3. MP Behavior 4.2.3. MP Behavior
With regard to the MP procedures that are defined in [RFC4090] this With regard to the MP procedures that are defined in [RFC4090] this
document specifies the following additional procedures to support RI- document specifies the following additional procedures to support RI-
RSVP defined in [RFC8370]. RSVP defined in [RFC8370].
Each node along an LSP path supporting the extensions defined in this Each node along an LSP path supporting the extensions defined in this
document MUST also include its router ID in the Node-ID sub-object of document MUST also include its router ID in the Node-ID sub-object of
the RRO object carried in the Resv message of the LSPs. If the PLR the RRO object carried in the Resv message of the corresponding LSP.
has not included a Node-ID sub-object in the RRO object carried in If the PLR has not included a Node-ID sub-object in the RRO object
the Path message and if the PLR is in a different IGP area, then the carried in the Path message and if the PLR is in a different IGP
router MUST NOT execute the MP procedures specified in this document area, then the router MUST NOT execute the MP procedures specified in
for those LSPs. Instead, the node MUST execute backward this document for those LSPs. Instead, the node MUST execute
compatibility procedures defined in Section 4.6.2.2 as if the backward compatibility procedures defined in Section 4.6.2.2 as if
upstream nodes along the LSP do not support the extensions defined in the upstream nodes along the LSP do not support the extensions
this document. defined in this document.
A node receiving Path messages should determine whether they contain A node receiving a Path message should determine whether the message
a B-SFRR-Ready Extended Association object with the Node-ID address contains a B-SFRR-Ready Extended Association object with its own
of the PLR as the source and its own Node-ID as the destination. In address as the bypass destination address and whether it has an
addition the node should determine whether it has an operational operational Node-ID signaling adjacency with the Association source.
remote Node-ID signaling adjacency with the PLR. If either the PLR If the PLR has not included the B-SFRR-Ready Extended Association
has not included the B-SFRR-Ready Extended Association object or if object or if there is no operational Node-ID signaling adjacency with
there is no operational Node-ID signaling adjacency with the PLR or the PLR identified by the Association source address or if the PLR
if the PLR has not advertised RI-RSVP capability in its Node-ID based has not advertised RI-RSVP capability in its Node-ID based Hello
Hello messages, then the node MUST execute backward compatibility messages, then the node MUST execute the backward compatibility
procedures defined in Section 4.6.2.2. procedures defined in Section 4.6.2.2.
If a matching B-SFRR-Ready Extended Association object is found in If a matching B-SFRR-Ready Extended Association object is found in in
the Path message and if there is an operational remote signaling the Path message and if there is an operational remote Node-ID
adjacency with the PLR that has advertised RI-RSVP capability (I-bit) signaling adjacency with the PLR (identified by the Association
[RFC8370] in its Node-ID based Hello messages, then the node SHOULD source) that has advertised RI-RSVP capability (I-bit) [RFC8370],
consider itself as the MP for the corresponding PLR. The matching then the node MUST consider itself as the MP for the PLR. The
and ordering rules for Bypass Summary FRR Extended Association matching and ordering rules for Bypass Summary FRR Extended
specified in RSVP-TE Summary FRR [RFC8796] MUST be followed by the Association specified in RSVP-TE Summary FRR [RFC8796] MUST be
implementations supporting this document. followed by the implementations supporting this document.
- If a matching Bypass Summary FRR Extended Association object is - If a matching Bypass Summary FRR Extended Association object is
included by the PPhop node of an LSP and if a corresponding Node- included by the PPhop node of an LSP and if a corresponding Node-
ID signaling adjacency exists with the PPhop node, then the router ID signaling adjacency exists with the PPhop node, then the router
SHOULD conclude it is the NP-MP. MUST conclude it is the NP-MP.
- If a matching Bypass Summary FRR Extended Association object is - If a matching Bypass Summary FRR Extended Association object is
included by the Phop node of an LSP and if a corresponding Node-ID included by the Phop node of an LSP and if a corresponding Node-ID
signaling adjacency exists with the Phop node, then the router signaling adjacency exists with the Phop node, then the router
SHOULD conclude it is the LP-MP. MUST conclude it is the LP-MP.
4.2.4. "Remote" State on MP 4.2.4. "Remote" State on MP
Once a router concludes it is the MP for a PLR running refresh- Once a router concludes it is the MP for a PLR running refresh-
interval independent FRR procedures, it SHOULD create a remote path interval independent FRR procedures as described in the preceding
state for the LSP. The only difference between the "remote" path section, it MUST create a remote path state for the LSP. The only
state and the LSP state is the RSVP_HOP object. The RSVP_HOP object difference between the "remote" path state and the LSP state is the
in a "remote" path state contains the address that the PLR uses to RSVP_HOP object. The RSVP_HOP object in a "remote" path state
send Node-ID hello messages to the MP. contains the address that the PLR uses to send Node-ID hello messages
to the MP.
The MP SHOULD consider the "remote" path state automatically deleted The MP MUST consider the "remote" path state corresponding to the LSP
if: automatically deleted if:
- The MP later receives a Path with no matching B-SFRR-Ready - The MP later receives a Path message for the LSP with no matching
Extended Association object corresponding to the PLR's IP address B-SFRR-Ready Extended Association object corresponding to the
contained in the Path RRO, or PLR's IP address contained in the Path RRO, or
- The Node-ID signaling adjacency with the PLR goes down, or - The Node-ID signaling adjacency with the PLR goes down, or
- The MP receives backup LSP signaling from the PLR or - The MP receives backup LSP signaling for the LSP from the PLR or
- The MP receives a PathTear, or
- The MP deletes the LSP state on local policy or exception event - The MP receives a PathTear for the LSP, or
Unlike the normal path state that is either locally generated on the - The MP deletes the LSP state on a local policy or an exception
ingress or created by a Path message from the Phop node, the "remote" event
path state is not signaled explicitly from the PLR. The purpose of
"remote" path state is to enable the PLR to explicitly tear down the The purpose of "remote" path state is to enable the PLR to explicitly
path and reservation states corresponding to the LSP by sending a tear down the path and reservation states corresponding to the LSP by
tear message for the "remote" path state. Such a message tearing sending a tear message for the "remote" path state. Such a message
down "remote" path state is called "Remote" PathTear. tearing down "remote" path state is called "Remote" PathTear.
The scenarios in which a "Remote" PathTear is applied are described The scenarios in which a "Remote" PathTear is applied are described
in Section 4.5. in Section 4.5.
4.3. Impact of Failures on LSP State 4.3. Impact of Failures on LSP State
This section describes the procedures for routers on the LSP path for This section describes the procedures that must be executed upon
different kinds of failures. The procedures described on detecting different kinds of failures by nodes along the path of the LSP. The
RSVP control plane adjacency failures do not impact the RSVP-TE procedures that must be executed upon detecting RSVP signaling
graceful restart mechanisms ([RFC3473], [RFC5063]). If the router adjacency failures do not impact the RSVP-TE graceful restart
executing these procedures act as helper for neighboring router, then mechanisms ([RFC3473], [RFC5063]). If a node executing these
the control plane adjacency will be declared as having failed after procedures acts as a helper for a neighboring router, then the
taking into account the grace period extended for neighbor by the signaling adjacency with the neighbor will be declared as having
helper. failed only after taking into account the grace period extended for
the neighbor by this node acting as a helper.
Node failures are detected from the state of Node-ID hello sessions Node failures are detected from the state of Node-ID hello sessions
established with immediate neighbors. RSVP-TE Scaling Techniques established with immediate neighbors. RSVP-TE Scaling Techniques
[RFC8370] recommends each router to establish Node-ID hello sessions [RFC8370] recommends that each node establish Node-ID hello sessions
with all its immediate neighbors. PLR or MP node failure is detected with all its immediate neighbors. Non-immediate PLR or MP failure is
from the state of remote signaling adjacency established according to detected from the state of remote signaling adjacency established
Section 4.2.2 of this document. according to Section 4.2.2 of this document.
4.3.1. Non-MP Behavior 4.3.1. Non-MP Behavior
When a router detects Phop link or Phop node failure and the router When a router detects the Phop link or the Phop node failure for an
is not an MP for the LSP, then it SHOULD send a Conditional PathTear LSP and the router is not an MP for the LSP, then it MUST send a
(refer to Section 4.4 "Conditional PathTear" below) and delete the Conditional PathTear (refer to Section 4.4 "Conditional PathTear"
PSB and RSB states corresponding to the LSP. below) and delete the PSB and RSB states corresponding to the LSP.
4.3.2. LP-MP Behavior 4.3.2. LP-MP Behavior
When the Phop link for an LSP fails on a router that is an LP-MP for When the Phop link for an LSP fails on a router that is an LP-MP for
the LSP, the LP-MP MUST retain the PSB and RSB states corresponding the LSP, the LP-MP MUST retain the PSB and RSB states corresponding
to the LSP till the occurrence of any of the following events. to the LSP till the occurrence of any of the following events.
- The Node-ID signaling adjacency with the Phop PLR goes down, or - The Node-ID signaling adjacency with the Phop PLR goes down, or
- The MP receives a normal or "Remote" PathTear for its PSB, or - The MP receives a normal or "Remote" PathTear for its PSB, or
- The MP receives a ResvTear for its RSB. - The MP receives a ResvTear for its RSB.
When a router that is an LP-MP for an LSP detects Phop node failure 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 SHOULD send a from the Node-ID signaling adjacency state, the LP-MP MUST send a
normal PathTear and delete the PSB and RSB states corresponding to normal PathTear and delete the PSB and RSB states corresponding to
the LSP. the LSP.
4.3.3. NP-MP Behavior 4.3.3. NP-MP Behavior
When a router that is an NP-MP for an LSP detects Phop link failure, 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 MUST retain the PSB and RSB states corresponding to the LSP till the
occurrence of any of the following events. occurrence of any of the following events.
- The remote Node-ID signaling adjacency with the PPhop PLR goes - The remote Node-ID signaling adjacency with the PPhop PLR goes
down, or down, or
- The MP receives a normal or "Remote" PathTear for its PSB, or - The MP receives a normal or "Remote" PathTear for its PSB, or
- The MP receives a ResvTear for its RSB. - The MP receives a ResvTear for its RSB.
When a router that is an NP-MP does not detect Phop link or node When a router that is an NP-MP for an LSP did not detect the Phop
failure, but receives a Conditional PathTear from the Phop node, then link or the Phop node failure, but receives a Conditional PathTear
the router MUST retain the PSB and RSB states corresponding to the from the Phop node, then the router MUST retain the PSB and RSB
LSP till the occurrence of any of the following events. states corresponding to the LSP till the occurrence of any of the
following events.
- The remote Node-ID signaling adjacency with the PPhop PLR goes - The remote Node-ID signaling adjacency with the PPhop PLR goes
down, or down, or
- The MP receives a normal or "Remote" PathTear for its PSB, or - The MP receives a normal or "Remote" PathTear for its PSB, or
- The MP receives a ResvTear for its RSB. - The MP receives a ResvTear for its RSB.
Receiving a Conditional PathTear from the Phop node will not impact Receiving a Conditional PathTear from the Phop node will not impact
the "remote" state from the PPhop PLR. Note that Phop node would the "remote" state from the PPhop PLR. Note that the Phop node must
send a Conditional PathTear if it was not an MP. have sent the Conditional PathTear as it was not an MP for the LSP
Section 4.3.1.
In the example topology in Figure 1, we assume C & D are the NP-MPs In the example topology Figure 1, we assume C & D are the NP-MPs for
for the PLRs A & B respectively. Now when A-B link fails, as B is the PLRs A & B respectively. Now when A-B link fails, as B is not an
not an MP and its Phop link has failed, B will delete LSP state (this MP and its Phop link has failed, B will delete the LSP state (this
behavior is required for unprotected LSPs - Section 4.3.1). In the behavior is required for unprotected LSPs - Section 4.3.1). In the
data plane, that would require B to delete the label forwarding entry data plane, that would require B to delete the label forwarding entry
corresponding to the LSP. So if B's downstream nodes C and D corresponding to the LSP. So if B's downstream nodes C and D
continue to retain state, it would not be correct for D to continue continue to retain state, it would not be correct for D to continue
to assume itself as the NP-MP for the PLR B. to assume itself as the NP-MP for the PLR B.
The mechanism that enables D to stop considering itself as the NP-MP The mechanism that enables D to stop considering itself as the NP-MP
for B and delete the corresponding "remote" path state is given for B and delete the corresponding "remote" path state is given
below. below.
1. When C receives a Conditional PathTear from B, it decides to 1. When C receives a Conditional PathTear from B, it decides to
retain LSP state as it is the NP-MP of the PLR A. C also SHOULD retain LSP state as it is the NP-MP of the PLR A. C also MUST
check whether Phop B had previously signaled availability of node check whether Phop B had previously signaled availability of node
protection. As B had previously signaled NP availability by protection. As B had previously signaled NP availability by
including B-SFRR-Ready Extended Association object, C SHOULD including B-SFRR-Ready Extended Association object, C MUST remove
remove the B-SFRR-Ready Extended Association object containing the B-SFRR-Ready Extended Association object containing
Association Source set to B from the Path message and trigger a Association Source set to B from the Path message and trigger a
Path to D. Path to D.
2. When D receives a triggered Path, it realizes that it is no longer 2. When D receives the Path message, it realizes that it is no longer
the NP-MP for B and so it deletes the corresponding "remote" path the NP-MP for B and so it deletes the corresponding "remote" path
state. D does not propagate the Path further down because the state. D does not propagate the Path further down because the
only change is that the B-SFRR-Ready Extended Association object only change is that the B-SFRR-Ready Extended Association object
corresponding to Association Source B is no longer present in the corresponding to Association Source B is no longer present in the
Path message. Path message.
4.3.4. Behavior of a Router that is both LP-MP and NP-MP 4.3.4. Behavior of a Router that is both LP-MP and NP-MP
A router may be simultaneously the LP-MP as well as the NP-MP for the A router may simultaneously be the LP-MP as well as the NP-MP for the
Phop and the PPhop nodes respectively of an LSP. If Phop link fails Phop and the PPhop nodes respectively of an LSP. If the Phop link
on such node, the node MUST retain the PSB and RSB states fails on such a node, the node MUST retain the PSB and RSB states
corresponding to the LSP till the occurrence of any of the following corresponding to the LSP till the occurrence of any of the following
events. events.
- Both Node-ID signaling adjacencies with Phop and PPhop nodes go - Both Node-ID signaling adjacencies with Phop and PPhop nodes go
down, or down, or
- The MP receives a normal or "Remote" PathTear for its PSB, or - The MP receives a normal or "Remote" PathTear for its PSB, or
- The MP receives a ResvTear for its RSB. - The MP receives a ResvTear for its RSB.
If a router that is both LP-MP and NP-MP detects Phop node failure, If a router that is both an LP-MP and an NP-MP detects Phop node
then the node MUST retain the PSB and RSB states corresponding to the failure, then the node MUST retain the PSB and RSB states
LSP till the occurrence of any of the following events. corresponding to the LSP till the occurrence of any of the following
events.
- The remote Node-ID signaling adjacency with the PPhop PLR goes - The remote Node-ID signaling adjacency with the PPhop PLR goes
down, or down, or
- The MP receives a normal or "Remote" PathTear for its PSB, or - The MP receives a normal or "Remote" PathTear for its PSB, or
- The MP receives a ResvTear for its RSB. - The MP receives a ResvTear for its RSB.
4.4. Conditional PathTear 4.4. Conditional PathTear
In the example provided in the Section 4.3.3, B deletes the PSB and In the example provided in the Section 4.3.3, B deletes the PSB and
RSB states corresponding to the LSP once B detects its link to Phop RSB states corresponding to the LSP once B detects its Phop link went
went down as B is not an MP. If B were to send a PathTear normally, down as B is not an MP. If B were to send a PathTear normally, then
then C would delete LSP state immediately. In order to avoid this, C would delete LSP state immediately. In order to avoid this, there
there should be some mechanism by which B can indicate to C that B should be some mechanism by which B can indicate to C that B does not
does not require the receiving node to unconditionally delete the LSP require the receiving node to unconditionally delete the LSP state
state immediately. For this, B SHOULD add a new optional CONDITIONS immediately. For this, B MUST add a new optional CONDITIONS object
object in the PathTear. The CONDITIONS object is defined in in the PathTear. The CONDITIONS object is defined in Section 4.4.3.
Section 4.4.3. If node C also understands the new object, then C If node C also understands the new object, then C MUST NOT delete the
SHOULD delete LSP state only if it is not an NP-MP - in other words C LSP state if it is an NP-MP.
SHOULD delete LSP state if there is no "remote" PLR path state on C.
4.4.1. Sending Conditional PathTear 4.4.1. Sending Conditional PathTear
A router that is not an MP for an LSP SHOULD delete the PSB and RSB A router that is not an MP for an LSP MUST delete the 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 (Section 4.3.1). The router SHOULD signaling adjacency goes down (Section 4.3.1). The router MUST send
send a Conditional PathTear if the following are also true. a Conditional PathTear if the following are also true.
- The ingress has requested node protection for the LSP, and - The ingress has requested node protection for the LSP, and
- No PathTear is received from the upstream node - No PathTear is received from the upstream node
4.4.2. Processing Conditional PathTear 4.4.2. Processing Conditional PathTear
When a router that is not an NP-MP receives a Conditional PathTear, When a router that is not an NP-MP receives a Conditional PathTear,
the node SHOULD delete the PSB and RSB states corresponding to the the node MUST delete the PSB and RSB states corresponding to the LSP,
LSP, and process the Conditional PathTear by considering it as a and process the Conditional PathTear by considering it as a normal
normal PathTear. Specifically, the node MUST NOT propagate the PathTear. Specifically, the node MUST NOT propagate the Conditional
Conditional PathTear downstream but remove the optional object and PathTear downstream but remove the optional object and send a normal
send a normal PathTear downstream. PathTear downstream.
When a node that is an NP-MP receives a Conditional PathTear, it MUST When a node that is an NP-MP receives a Conditional PathTear, it MUST
NOT delete LSP state. The node SHOULD check whether the Phop node NOT delete LSP state. The node MUST check whether the Phop node had
had previously included the B-SFRR-Ready Extended Association object previously included the B-SFRR-Ready Extended Association object in
in the Path. If the object had been included previously by the Phop, the Path. If the object had been included previously by the Phop,
then the node processing the Conditional PathTear from the Phop then the node processing the Conditional PathTear from the Phop MUST
SHOULD remove the corresponding object and trigger a Path downstream. remove the corresponding object and trigger a Path downstream.
If a Conditional PathTear is received from a neighbor that has not If a Conditional PathTear is received from a neighbor that has not
advertised support (refer to Section 4.6) for the new procedures advertised support (refer to Section 4.6) for the new procedures
defined in this document, then the node SHOULD consider the message defined in this document, then the node MUST consider the message as
as a normal PathTear. The node SHOULD propagate the normal PathTear a normal PathTear. The node MUST propagate the normal PathTear
downstream and delete the LSP state. downstream and delete the LSP state.
4.4.3. CONDITIONS Object 4.4.3. CONDITIONS Object
As any implementation that does not support Conditional PathTear As any implementation that does not support Conditional PathTear MUST
SHOULD ignore the new object but process the message as a normal ignore the new object but process the message as a normal PathTear
PathTear without generating any error, the Class-Num of the new without generating any error, the Class-Num of the new object MUST be
object MUST be 10bbbbbb where 'b' represents a bit (from Section 3.10 10bbbbbb where 'b' represents a bit (from Section 3.10 of [RFC2205]).
of [RFC2205]).
The new object is called as "CONDITIONS" object that will specify the The new object is called as "CONDITIONS" object that will specify the
conditions under which default processing rules of the RSVP-TE conditions under which default processing rules of the RSVP-TE
message MUST be invoked. message MUST be invoked.
The object has the following format: The object has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class | C-type | | Length | Class | C-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 34 skipping to change at page 16, line 42
Figure 2: CONDITIONS Object Figure 2: CONDITIONS Object
Length: This contains the size of the object in bytes and should Length: This contains the size of the object in bytes and should
be set to eight. be set to eight.
Class: To be assigned Class: To be assigned
C-type: 1 C-type: 1
M bit: If the M bit is set to 1, then the PathTear message SHOULD Merge-point condition (M) bit: If the M bit is set to 1, then the
be processed according to the receiver router role, i.e. if it is PathTear message MUST be processed according to the receiver
an MP or not. router role, i.e. if the receiving router is an MP or not for the
If M-bit is set to 0, then the PathTear message SHOULD be LSP.
processed as a normal PathTear message. If the M-bit is set to 0, then the PathTear message MUST be
processed processed as a normal PathTear message for the LSP.
4.5. Remote State Teardown 4.5. Remote State Teardown
If the ingress wants to tear down the LSP because of a management 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 till the completion of backup LSP
signaling to perform state cleanup. To enable LSP state cleanup when signaling to perform state cleanup. To enable LSP state cleanup when
the LSP is being locally repaired, the PLR SHOULD send a "Remote" the LSP is being locally repaired, the PLR MUST send a "Remote"
PathTear message instructing the MP to delete the PSB and RSB states PathTear message instructing the MP to delete the PSB and RSB states
corresponding to the LSP. The TTL in the "Remote" PathTear message corresponding to the LSP. The TTL in the "Remote" PathTear message
SHOULD be set to 255. MUST be set to 255.
Let us consider that node C, in example topology (Figure 1), has gone Let us consider that node C in the example topology (Figure 1) has
down and B locally repairs the LSP. gone down and node B locally repairs the LSP.
1. Ingress A receives a management event to tear down the LSP. 1. Ingress A receives a management event to tear down the LSP.
2. A sends a normal PathTear to B. 2. A sends a normal PathTear for the LSP to B.
3. Assume B has not initiated backup signaling for the LSR. To 3. Assume B has not initiated the backup signaling for the LSP during
enable LSP state cleanup, B SHOULD send a "Remote" PathTear with local repair. To enable LSP state cleanup, B MUST send a "Remote"
destination IP address set to that of D used in the Node-ID PathTear with destination IP address set to that of the node D
signaling adjacency with D, and RSVP_HOP object containing local used in the Node-ID signaling adjacency with D, and the RSVP_HOP
address used in the Node-ID signaling adjacency. object containing local address used in the Node-ID signaling
adjacency.
4. B then deletes the PSB and RSB states corresponding to the LSP. 4. B then deletes the PSB and RSB states corresponding to the LSP.
5. On D there would be a remote signaling adjacency with B and so D 5. On D there would be a remote signaling adjacency with B and so D
SHOULD accept the "Remote" PathTear and delete the PSB and RSB MUST accept the "Remote" PathTear and delete the PSB and RSB
states corresponding to the LSP. states corresponding to the LSP.
4.5.1. PLR Behavior on Local Repair Failure 4.5.1. PLR Behavior on Local Repair Failure
If local repair fails on the PLR after a failure, then this should be If local repair fails on the PLR after a failure, then this MUST be
considered as a case for cleaning up LSP state from the PLR to the considered as a case for cleaning up LSP state from the PLR to the
Egress. The PLR would achieve this using "Remote" PathTear to clean Egress. The PLR achieves state cleanup by sending "Remote" PathTear
up the state from the MP. If the MP has retained the LSP state, then to the MP. The MP MUST delete the states corresponding to the LSP
it would propagate the PathTear downstream thereby achieving state also also propagate the PathTear downstream thereby achieving state
cleanup. Note that in the case of link protection, the PathTear cleanup from all downstream nodes up to the LSP egress. Note that in
would be directed to the LP-MP node's IP address rather than the Nhop the case of link protection, the PathTear MUST be directed to the LP-
interface address. MP's Node-ID IP address rather than the Nhop interface address.
4.5.2. PLR Behavior on Resv RRO Change 4.5.2. PLR Behavior on Resv RRO Change
When a PLR router that has already made NP available detects a change When a PLR router that has already made NP available for an LSP
in the RRO carried in the Resv message indicating that the router's detects a change in the RRO carried in the Resv message that
former NP-MP is no longer present in the LSP path, then the router indicates that the router's former NP-MP is no longer present on the
SHOULD send a "Remote" PathTear directly to its former NP-MP. path of the LSP, then the router MUST send a "Remote" PathTear
directly to its former NP-MP.
In the example topology in Figure 1, let us assume A has made node In the example topology Figure 1, let us assume A has made node
protection available and C has concluded it is the NP-MP for PLR A. protection available for an LSP and C has concluded it is the NP-MP
When the B-C link fails then C, implementing the procedure specified for PLR A. When the B-C link fails then C, implementing the
in Section 4.3.4 of this document, will retain state till: the remote procedure specified in Section 4.3.4 of this document, will retain
Node-ID signaling adjacency with A goes down, or a PathTear or a the states corresponding to the LSP until: the remote Node-ID
ResvTear is received for its PSB or RSB respectively. If B also has signaling adjacency with A goes down, or a PathTear or a ResvTear is
made node protection available, B will eventually complete backup LSP received for its PSB or RSB respectively. If B also has made node
signaling with its NP-MP D and trigger a Resv to A with RRO changed. protection available, B will eventually complete backup LSP signaling
The new RRO of the LSP carried in the Resv will not contain C. When with its NP-MP D and trigger a Resv to A with RRO changed. The new
A processes the Resv with a new RRO not containing C - its former NP- RRO of the LSP carried in the Resv will not contain C. When A
MP, A SHOULD send a "Remote" PathTear to C. When C receives the processes the Resv message with a new RRO not containing C - its
"Remote" PathTear for its PSB state, C will send a normal PathTear former NP-MP, A MUST send a "Remote" PathTear to C. When C receives
downstream to D and delete both the PSB and RSB states corresponding the "Remote" PathTear for its PSB state, C will send a normal
to the LSP. As D has already received backup LSP signaling from B, D PathTear downstream to D and delete both the PSB and RSB states
will retain control plane and forwarding states corresponding to the corresponding to the LSP. As D has already received backup LSP
LSP. signaling from B, D will retain control plane and forwarding states
corresponding to the LSP.
4.5.3. LSP Preemption during Local Repair 4.5.3. LSP Preemption during Local Repair
4.5.3.1. Preemption on LP-MP after Phop Link Failure 4.5.3.1. Preemption on LP-MP after Phop Link Failure
If an LSP is preempted on an LP-MP after its Phop or incoming link If an LSP is preempted on an LP-MP after its Phop or the incoming
has already failed but the backup LSP has not been signaled yet, then link has already failed but the backup LSP has not been signaled yet
the node SHOULD send a normal PathTear and delete both the PSB and as part of local repair procedure, then the node MUST send a normal
RSB states corresponding to the LSP. As the LP-MP has retained LSP PathTear and delete both the PSB and RSB states corresponding to the
state expecting the PLR to perform backup LSP signaling, preemption LSP. As the LP-MP has retained the LSP state expecting the PLR to
would bring down the LSP and the node would not be LP-MP any more initiate backup LSP signaling, preemption would bring down the LSP
requiring the node to clean up LSP state. and the node would not be LP-MP any more requiring the node to clean
up the LSP state.
4.5.3.2. Preemption on NP-MP after Phop Link Failure 4.5.3.2. Preemption on NP-MP after Phop Link Failure
If an LSP is preempted on an NP-MP after its Phop link has already If an LSP is preempted on an NP-MP after its Phop link has already
failed but the backup LSP has not been signaled yet, then the node failed but the backup LSP has not been signaled yet, then the node
SHOULD send a normal PathTear and delete the PSB and RSB states MUST send a normal PathTear and delete the PSB and RSB states
corresponding to the LSP. As the NP-MP has retained LSP state corresponding to the LSP. As the NP-MP has retained LSP state
expecting the PLR to perform backup LSP signaling, preemption would expecting the PLR to initiate backup LSP signaling, preemption would
bring down the LSP and the node would not be NP-MP any more requiring bring down the LSP and the node would not be NP-MP any more requiring
the node to clean up LSP state. the node to clean up LSP state.
Let us consider that B-C link goes down on the same example topology Let us consider that B-C link goes down on the same example topology
(Figure 1). As C is the NP-MP for the PLR A, C will retain LSP (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP
state. state.
1. The LSP is preempted on C. 1. The LSP is preempted on C.
2. C will delete the RSB state corresponding to the LSP. But C 2. C will delete the RSB state corresponding to the LSP. But C
cannot send a PathErr or a ResvTear to the PLR A because the cannot send a PathErr or a ResvTear to the PLR A because the
backup LSP has not been signaled yet. backup LSP has not been signaled yet.
3. As the only reason for C having retained state after Phop node 3. As the only reason for C having retained state after Phop node
failure was that it was an NP-MP, C SHOULD send a normal PathTear failure was that it was an NP-MP, C MUST send a normal PathTear to
to D and delete its PSB state also. D would also delete the PSB D and delete its PSB state also. D would also delete the PSB and
and RSB states on receiving a PathTear from C. RSB states on receiving a PathTear from C.
4. B starts backup LSP signaling to D. But as D does not have the 4. B starts backup LSP signaling to D. But as D does not have the
LSP state, it will reject the backup LSP Path and send a PathErr LSP state, it will reject the backup LSP Path and send a PathErr
to B. to B.
5. B will delete its reservation and send a ResvTear to A. 5. B will delete its reservation and send a ResvTear to A.
4.6. Backward Compatibility Procedures 4.6. Backward Compatibility Procedures
The "Refresh interval Independent FRR" or RI-RSVP-FRR referred below "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set
in this section refers to the changes that have been defined in of procedures defined in this document to elimiate the reliance of
previous sections. Any implementation that does not support them has periodic refreshes. The extensions proposed in RSVP-TE Summary FRR
been termed as "non-RI-RSVP-FRR implementation". The extensions [RFC8796] may apply to implementations that do not support RI-RSVP-
proposed in RSVP-TE Summary FRR [RFC8796] are applicable to FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state
implementations that do not support RI-RSVP-FRR. On the other hand, cleanup namely Conditional and "Remote" PathTear require support from
changes proposed relating to LSP state cleanup namely Conditional and one-hop and two-hop neighboring nodes along the LSP path. So
"Remote" PathTear require support from one-hop and two-hop procedures that fall under LSP state cleanup category MUST NOT be
neighboring nodes along the LSP path. So procedures that fall under turned on if any of the nodes involved in the node protection FRR
LSP state cleanup category SHOULD be turned on only if all nodes i.e. the PLR, the MP and the intermediate node in the case of NP,
involved in the node protection FRR i.e. the PLR, the MP and the DOES NOT support RI-RSVP-FRR extensions. Note that for LSPs
intermediate node in the case of NP, support the extensions. Note requesting link protection, only the PLR and the LP-MP MUST support
that for LSPs requesting only link protection, the PLR and the LP-MP the extensions.
need to support the extensions.
4.6.1. Detecting Support for Refresh interval Independent FRR 4.6.1. Detecting Support for Refresh interval Independent FRR
An implementation supporting the extensions specified in previous An implementation supporting RI-RSVP-FRR extensions SHOULD set the
sections (called RI-RSVP-FRR here after) SHOULD set the flag "Refresh flag "Refresh interval Independent RSVP" or RI-RSVP flag in the
interval Independent RSVP" or RI-RSVP flag in the CAPABILITY object CAPABILITY object carried in Hello messages as specified in RSVP-TE
carried in Hello messages. The RI-RSVP flag is specified in RSVP-TE Scaling Techniques [RFC8370]. If an implementation does not set the
Scaling Techniques [RFC8370]. flag even if it supports RI-RSVP-FRR extensions, then its neighbors
will view the node as any node that does not support the extensions.
- As nodes supporting the extensions SHOULD initiate Node Hellos - As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID
with adjacent nodes, a node on the path of protected LSP can based signaling adjacency with all immedate neighbors, such a node
determine whether its Phop or Nhop neighbor supports RI-RSVP-FRR on the path of a protected LSP can determine whether its Phop and
enhancements from the Hello messages sent by the neighbor. Nhop neighbors support RI-RSVP-FRR enhancements.
- If a node attempts to make node protection available, then the PLR - As nodes supporting the RI-RSVP-FRR extensions also initiate Node-
SHOULD initiate a remote Node-ID signaling adjacency with its ID based signaling adjacency with the NNhop along the path of the
NNhop. If the NNhop (a) does not reply to remote node Hello LSP requested node protection Section 4.2.1, each node along the
message or (b) does not set the RI-RSVP flag in the CAPABILITY LSP path can determine whether its NNhop node supports RI-RSVP-FRR
object carried in its Node-ID Hello messages, then the PLR can enhancements. If the NNhop (a) does not reply to remote Node-ID
conclude that NNhop does not support RI-RSVP-FRR extensions. 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.
- If node protection is requested for an LSP and if (a) the PPhop - If node protection is requested for an LSP and if (a) the PPhop
node has not included a matching B-SFRR-Ready Extended Association node has not included a matching B-SFRR-Ready Extended Association
object in its Path messages or (b) the PPhop node has not object in its Path messages or (b) the PPhop node has not
initiated remote node Hello messages or (c) the PPhop node does 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 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 Node-ID Hello messages, then the node MUST conclude that the PLR
does not support RI-RSVP-FRR extensions. The details are does not support RI-RSVP-FRR extensions.
described in the "Procedures for Backward Compatibility" section
below.
4.6.2. Procedures for Backward Compatibility 4.6.2. Procedures for Backward Compatibility
The procedures defined hereafter are performed on a subset of LSPs Every node that supports RI-RSVP-FRR MUST support the procedures
that traverse a node, rather than on all LSPs that traverse a node. defined in this section in order to support backward compatibility
This behavior is required to support backward compatibility for a for those subset of LSPs that also traverse nodes that do not support
subset of LSPs traversing nodes running non-RI-RSVP-FRR RI-RSVP-FRR.
implementations.
4.6.2.1. Lack of support on Downstream Node 4.6.2.1. Lack of support on Downstream Node
The procedures on the downstream direction are as follows. The procedures on the downstream direction are as follows.
- If the Nhop does not support the RI-RSVP-FRR extensions, then the - If a node finds that the Nhop node along the LSP does not support
node SHOULD reduce the "refresh period" in the TIME_VALUES object the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh
carried in the Path to the default short refresh interval. period" in the TIME_VALUES object carried in the Path messages to
the default short refresh interval.
- If node protection is requested and the NNhop node does not - If node protection is requested for the LSP and the NNhop node
support the enhancements, then the node SHOULD reduce the "refresh along the LSP path does not support the RI-RSVP-FRR extensions,
period" in the TIME_VALUES object carried in the Path to the then the node MUST reduce the "refresh period" in the TIME_VALUES
default short refresh interval. object carried in the Path messages to the default short refresh
interval.
If the node reduces the refresh time from the above procedures, it If a node reduces the refresh time using the above procedures, it
MUST NOT send any "Remote" PathTear or Conditional PathTear messages. MUST NOT send any "Remote" PathTear or Conditional PathTear message
to the downstream node.
Consider the example topology in Figure 1. If C does not support the Consider the example topology in Figure 1. If C does not support the
RI-RSVP-FRR extensions, then: RI-RSVP-FRR extensions, then:
- A and B SHOULD reduce the refresh time to default short refresh - A and B MUST reduce the refresh time to the default short refresh
interval of 30 seconds and trigger a Path interval of 30 seconds and trigger a Path message
- If B is not an MP and if Phop link of B fails, B cannot send - If B is not an MP and if Phop link of B fails, B cannot send
Conditional PathTear to C but MUST time out the PSB state from A Conditional PathTear to C but MUST time out the PSB state from A
normally. This would be accomplished if A would also reduce the normally. Note that B can time out the PSB state A normally only
refresh time to default value. So if C does not support the RI- if A did not set long refresh in the TIME_VALUES object carried in
RSVP-FRR extensions, then Phop B and the PPhop A SHOULD reduce the the Path messages sent earlier.
refresh period to the default short refresh interval.
4.6.2.2. Lack of support on Upstream Node 4.6.2.2. Lack of support on Upstream Node
The procedures are as follows. The procedures are as follows.
- If Phop node does not support the RI-RSVP-FRR extensions, then the - If a node finds that the Phop node along the LSP path does not
node SHOULD reduce the "refresh period" in the TIME_VALUES object support the RI-RSVP-FRR extensions, then the node MUST reduce the
carried in the Resv to the default short refresh interval. "refresh period" in the TIME_VALUES object carried in the Resv
messages to the default short refresh interval.
- If node protection is requested and the Phop node does not support - If node protection is requested for the LSP and the Phop node
the RI-RSVP-FRR extensions, then the node SHOULD reduce the along the LSP path does not support the RI-RSVP-FRR extensions,
"refresh period" in the TIME_VALUES object carried in the Path to then the the node MUST reduce the "refresh period" in the
the default short refresh interval (thus, the Nhop can use TIME_VALUES object carried in the Path messages to the default
compatible values when sending a Resv). short refresh interval (thus, the Nhop can use compatible values
when sending a Resv).
- If node protection is requested and the PPhop node does not - If node protection is requested for the LSP and the PPhop node
support the RI-RSVP-FRR extensions, then the node SHOULD reduce does not support the RI-RSVP-FRR extensions, then the node MUST
the "refresh period" in the TIME_VALUES object carried in the Resv reduce the "refresh period" in the TIME_VALUES object carried in
to the default short refresh interval. the Resv messages to the default short refresh interval.
- If the node reduces the refresh time from the above procedures, it - If the node reduces the refresh time using the above procedures,
SHOULD also not execute MP procedures specified in Section 4.3 of it MUST NOT execute MP procedures specified in Section 4.3 of this
this document. document.
4.6.2.3. Incremental Deployment 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR
If a node supporting facility backup protection [RFC4090] sets the
RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR
extensions, then it leaves room for stale state to linger around for
an inordinate period of time or disruption of normal FRR operation.
Consider the example topology Figure 1 provided in this document.
- 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.
- Intead 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.
- 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.
4.6.2.4. Incremental Deployment
The backward compatibility procedures described in the previous sub- The backward compatibility procedures described in the previous sub-
sections imply that a router supporting the RI-RSVP-FRR extensions sections imply that a router supporting the RI-RSVP-FRR extensions
specified in this document can apply the procedures specified in the specified in this document can apply the procedures specified in the
document either in the downstream or upstream direction of an LSP, document either in the downstream or upstream direction of an LSP,
depending on the capability of the routers downstream or upstream in depending on the capability of the routers downstream or upstream in
the LSP path. the LSP path.
- RI-RSVP-FRR extensions and procedures are enabled for downstream - RI-RSVP-FRR extensions and procedures are enabled for downstream
Path, PathTear and ResvErr messages corresponding to an LSP if Path, PathTear and ResvErr messages corresponding to an LSP if
skipping to change at page 22, line 9 skipping to change at page 23, line 18
extensions specified in this document is deployed on all routers in 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 applied request node protection, then the FRR extensions will only be applied
for the LSP segments that traverse the particular region. This will for the LSP segments that traverse the particular region. This will
aid incremental deployment of these extensions and also allow reaping aid incremental deployment of these extensions and also allow reaping
the benefits of the extensions in portions of the network where it is the benefits of the extensions in portions of the network where it is
supported. supported.
5. Security Considerations 5. Security Considerations
The security considerations pertaining to the original RSVP protocol The security considerations pertaining to [RFC2961], [RFC4090],
[RFC2205], [RFC3209] and [RFC5920] remain relevant. [RFC8370], [RFC8796] and [RFC5920] remain relevant. When using RSVP
Cryptographic Authentication [RFC2747], more robust algorithms
[RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed
message digest where possible.
This document extends the applicability of Node-ID based Hello This document extends the applicability of Node-ID based Hello
session between immediate neighbors. The Node-ID based Hello session session between immediate neighbors. The Node-ID based Hello session
between the PLR and the NP-MP may require the two routers to exchange between the PLR and the NP-MP may require the two routers to exchange
Hello messages with non-immediate neighbor. So, the implementations Hello messages with non-immediate neighbor. So, the implementations
SHOULD provide the option to configure Node-ID neighbor specific or SHOULD provide the option to configure Node-ID neighbor specific or
global authentication key to authentication messages received from global authentication key to authentication messages received from
Node-ID neighbors. The network administrator MAY utilize this option Node-ID neighbors. The network administrator SHOULD utilize this
to enable RSVP-TE routers to authenticate Node-ID Hello messages option to enable RSVP-TE routers to authenticate Node-ID Hello
received with TTL greater than 1. Implementations SHOULD also messages received with TTL greater than 1. Implementations SHOULD
provide the option to specify a limit on the number of Node-ID based also provide the option to specify a limit on the number of Node-ID
Hello sessions that can be established on a router supporting the based Hello sessions that can be established on a router supporting
extensions defined in this document. the extensions defined in this document.
6. IANA Considerations 6. IANA Considerations
6.1. New Object - CONDITIONS 6.1. New Object - CONDITIONS
RSVP Change Guidelines [RFC3936] defines the Class-Number name space RSVP Change Guidelines [RFC3936] defines the Class-Number name space
for RSVP objects. The name space is managed by IANA. for RSVP objects. The name space is managed by IANA.
IANA registry: RSVP Parameters IANA registry: RSVP Parameters
Subsection: Class Names, Class Numbers, and Class Types Subsection: Class Names, Class Numbers, and Class Types
A new RSVP object using a Class-Number from 128-183 range called the A new RSVP object using a Class-Number from 128-183 range called the
"CONDITIONS" object is defined in Section 4.4 of this document. The "CONDITIONS" object is defined in Section 4.4 of this document. The
Class-Number from 128-183 range will be allocated by IANA. Class-Number from 128-183 range will be allocated by IANA.
6.2. CONDITIONS Flags
Apart from allocating Class-Number for the CONDITIONS object, the
allocation of the Merge-point condition bit or M-bit Section 4.4 will
also be done by IANA.
Flag: 0x1 Name: Merge-point condition bit or M-bit
7. Acknowledgements 7. Acknowledgements
We are very grateful to Yakov Rekhter for his contributions to the We are very grateful to Yakov Rekhter for his contributions to the
development of the idea and thorough review of content of the draft. development of the idea and thorough review of content of the draft.
Thanks to Raveendra Torvi and Yimin Shen for their comments and We are thankful to Raveendra Torvi and Yimin Shen for their comments
inputs. and inputs on early versions of the draft. We also thank Alexander
Okonnikov for his review and comments on the draft.
8. Contributors 8. Contributors
Markus Jork Markus Jork
128 Technology Juniper Networks, Inc.
Email: mjork@128technology.net Email: mjork@juniper.net
Harish Sitaraman Harish Sitaraman
Individual Contributor Individual Contributor
Email: harish.ietf@gmail.com Email: harish.ietf@gmail.com
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks, Inc. Juniper Networks, Inc.
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Ebben Aries Ebben Aries
Arrcus, Inc. Arrcus, Inc.
skipping to change at page 23, line 34 skipping to change at page 25, line 10
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, DOI 10.17487/RFC2747, January
2000, <https://www.rfc-editor.org/info/rfc2747>.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
<https://www.rfc-editor.org/info/rfc2961>. <https://www.rfc-editor.org/info/rfc2961>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 24, line 39 skipping to change at page 26, line 18
<https://www.rfc-editor.org/info/rfc8370>. <https://www.rfc-editor.org/info/rfc8370>.
[RFC8796] Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A., [RFC8796] Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A.,
Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute
Extensions for Label Switched Path (LSP) Tunnels", Extensions for Label Switched Path (LSP) Tunnels",
RFC 8796, DOI 10.17487/RFC8796, July 2020, RFC 8796, DOI 10.17487/RFC8796, July 2020,
<https://www.rfc-editor.org/info/rfc8796>. <https://www.rfc-editor.org/info/rfc8796>.
9.2. Informative References 9.2. Informative References
[FIPS-180-3]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-3, October 2008.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
Authors' Addresses Authors' Addresses
Chandra Ramachandran Chandra Ramachandran
Juniper Networks, Inc. Juniper Networks, Inc.
Email: csekar@juniper.net Email: csekar@juniper.net
 End of changes. 93 change blocks. 
326 lines changed or deleted 418 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/