< draft-ietf-mpls-ri-rsvp-frr-05.txt   draft-ietf-mpls-ri-rsvp-frr-06.txt >
MPLS Working Group C. Ramachandran MPLS Working Group C. Ramachandran
Internet-Draft Juniper Networks Internet-Draft T. Saad
Updates: 4090 (if approved) I. Minei Updates: 4090 (if approved) Juniper Networks, Inc.
Intended status: Standards Track Google, Inc Intended status: Standards Track I. Minei
Expires: August 12, 2019 D. Pacella Expires: December 22, 2019 Google, Inc.
Verizon D. Pacella
T. Saad Verizon, Inc.
Cisco Systems Inc. June 20, 2019
February 8, 2019
Refresh Interval Independent FRR Facility Protection Refresh-interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-05 draft-ietf-mpls-ri-rsvp-frr-06
Abstract Abstract
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 LSP related states along the reserved path. In the and maintain the Label Switched Path (LSP) related states along the
absence of refresh messages, the LSP related states are automatically reserved path. In the absence of refresh messages, the LSP-related
deleted. Reliance on periodic refreshes and refresh timeouts are states are automatically deleted. Reliance on periodic refreshes and
problematic from the scalability point of view. The number of RSVP- refresh timeouts are problematic from the scalability point of view.
TE LSPs that a router needs to maintain has been growing in service The number of RSVP-TE LSPs that a router needs to maintain has been
provider networks and the implementations should be capable of growing in service provider networks and the implementations should
handling increase in LSP scale. be capable of handling increase in LSP scale.
RFC 2961 specifies mechanisms to eliminate the reliance on periodic RFC 2961 specifies mechanisms to eliminate the reliance on periodic
refresh and refresh timeout of RSVP messages, and enables a router to refresh and refresh timeout of RSVP messages, and enables a router to
increase the message refresh interval to values much longer than the increase the message refresh interval to values much longer than the
default 30 seconds defined in RFC 2205. However, the protocol default 30 seconds defined in RFC 2205. However, the protocol
extensions defined in RFC 4090 for supporting fast reroute (FRR) extensions defined in RFC 4090 for supporting Fast ReRoute (FRR)
using bypass tunnels implicitly rely on short refresh timeouts to using bypass tunnels implicitly rely on short refresh timeouts to
cleanup stale states. cleanup stale states.
In order to eliminate the reliance on refresh timeouts, the routers In order to eliminate the reliance on refresh timeouts, the routers
should unambiguously determine when a particular LSP state should be should unambiguously determine when a particular LSP state should be
deleted. Coupling LSP state with the corresponding RSVP-TE signaling deleted. Coupling LSP state with the corresponding RSVP-TE signaling
adjacencies as recommended in RFC 8370 will apply in scenarios other adjacencies as recommended in RFC 8370 will apply in scenarios other
than RFC 4090 FRR using bypass tunnels. In scenarios involving RFC than RFC 4090 FRR using bypass tunnels. In scenarios involving RFC
4090 FRR using bypass tunnels, additional explicit tear down messages 4090 FRR using bypass tunnels, additional explicit tear down messages
are necessary. Refresh-interval Independent RSVP FRR (RI-RSVP-FRR) are necessary. Refresh-interval Independent RSVP FRR (RI-RSVP-FRR)
extensions specified in this document consists of procedures to extensions specified in this document consists of procedures to
enable LSP state cleanup that are essential in scenarios not covered enable LSP state cleanup that are essential in scenarios not covered
by procedures defined in RSVP-TE Scaling Recommendations. Hence, by procedures defined in RSVP-TE Scaling Recommendations. Hence,
this document updates the procedures defined in RFC 4090 to support this document updates the procedures defined in RFC 4090 to support
Refresh-Interval Independent RSVP (RI-RSVP) capability specified in Refresh-interval Independent RSVP (RI-RSVP) capability specified in
RFC 8370. RFC 8370.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Status of This Memo Status of This Memo
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 August 12, 2019. This Internet-Draft will expire on December 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 3, line 4 skipping to change at page 3, line 4
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . 8
4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 8 4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 12 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 Path Tear . . . . . . . . . . . . . . . . . . 14 4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15
4.4.1. Sending Conditional Path Tear . . . . . . . . . . . . 14 4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15
4.4.2. Processing Conditional Path Tear . . . . . . . . . . 15 4.4.2. Processing Conditional PathTear . . . . . . . . . . . 15
4.4.3. CONDITIONS object . . . . . . . . . . . . . . . . . . 15 4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16
4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 16 4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . 17 4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18
4.5.3.1. Preemption on LP-MP after Phop Link failure . . . 17 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 . . . . . . . . . . . . 18 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 . . . . . . . . 19 4.6.2. Procedures for Backward Compatibility . . . . . . . . 20
4.6.2.1. Lack of support on Downstream Node . . . . . . . 19 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 . . . . . . . . 20
4.6.2.3. Incremental Deployment . . . . . . . . . . . . . 20 4.6.2.3. Incremental Deployment . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 22 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
RSVP-TE Fast Reroute [RFC4090] defines two local repair techniques to RSVP-TE Fast ReRoute [RFC4090] defines two local repair techniques to
reroute label switched path (LSP) traffic over pre-established backup reroute Label Switched Path (LSP) traffic over pre-established backup
tunnel. Facility backup method allows one or more LSPs traversing a tunnel. Facility backup method allows one or more LSPs traversing a
connected link or node to be protected using a bypass tunnel. The connected link or node to be protected using a bypass tunnel. The
many-to-one nature of local repair technique is attractive from many-to-one nature of local repair technique is attractive from
scalability point of view. This document enumerates facility backup scalability point of view. This document enumerates facility backup
procedures in RFC 4090 that rely on refresh timeout and hence make procedures in [RFC4090] that rely on refresh timeout and hence make
facility backup method refresh-interval dependent. The RSVP-TE facility backup method refresh-interval dependent. The RSVP-TE
extensions defined in this document will enhance the facility backup extensions defined in this document will enhance the facility backup
protection mechanism by making the corresponding procedures refresh- protection mechanism by making the corresponding procedures refresh-
interval independent. interval independent.
1.1. Motivation 1.1. Motivation
Standard RSVP [RFC2205] maintains state via the generation of RSVP Base RSVP [RFC2205] maintains state via the generation of RSVP Path/
Path/Resv refresh messages. Refresh messages are used to both Resv refresh messages. Refresh messages are used to both synchronize
synchronize state between RSVP neighbors and to recover from lost state between RSVP neighbors and to recover from lost RSVP messages.
RSVP messages. The use of Refresh messages to cover many possible The use of Refresh messages to cover many possible failures has
failures has resulted in a number of operational problems. resulted in a number of operational problems.
- One problem relates to RSVP control plane scaling due to periodic - One problem relates to RSVP control plane scaling due to periodic
refreshes of Path and Resv messages, another relates to the refreshes of Path and Resv messages, another relates to the
reliability and latency of RSVP signaling. reliability and latency of RSVP signaling.
- An additional problem is the time to clean up the stale state - An additional problem is the time to clean up the stale state
after a tear message is lost. For more on these problems see after a tear message is lost. For more on these problems see
Section 1 of RSVP Refresh Overhead Reduction Extensions [RFC2961]. Section 1 of RSVP Refresh Overhead Reduction Extensions [RFC2961].
The problems listed above adversely affect RSVP control plane The problems listed above adversely affect RSVP control plane
scalability and RSVP-TE [RFC3209] inherited these problems from scalability and RSVP-TE [RFC3209] inherited these problems from
standard RSVP. Procedures specified in [RFC2961] address the above standard RSVP. Procedures specified in [RFC2961] address the above
mentioned problems by eliminating dependency on refreshes for state mentioned problems by eliminating dependency on refreshes for state
synchronization and for recovering from lost RSVP messages, and by synchronization and for recovering from lost RSVP messages, and by
eliminating dependency on refresh timeout for stale state cleanup. eliminating dependency on refresh timeout for stale state cleanup.
Implementing these procedures allows implementations to improve RSVP- Implementing these procedures allows implementations to improve RSVP-
TE control plane scalability. For more details on eliminating TE control plane scalability. For more details on eliminating
dependency on refresh timeout for stale state cleanup, refer to dependency on refresh timeout for stale state cleanup, refer to
"Refresh Interval Independent RSVP" section 3 of RSVP-TE Scaling "Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling
Techniques [RFC8370]. Techniques [RFC8370].
However, the procedures specified in RSVP-TE Scaling Techniques However, the procedures specified in RSVP-TE Scaling Techniques
[RFC8370] do not fully address stale state cleanup for facility [RFC8370] do not fully address stale state cleanup for facility
backup protection [RFC4090], as facility backup protection still backup protection [RFC4090], as facility backup protection still
depends on refresh timeouts for stale state cleanup. depends on refresh timeouts for stale state cleanup.
The procedures specified in this document, in combination with RSVP- The procedures specified in this document, in combination with RSVP-
TE Scaling Techniques [RFC8370], eliminate facility backup protection TE Scaling Techniques [RFC8370], eliminate facility backup protection
dependency on refresh timeouts for stale state cleanup including the dependency on refresh timeouts for stale state cleanup. The document
cleanup for facility backup protection. The document hence updates hence updates the semantics of Refresh-interval Independent RSVP (RI-
the semantics of Refresh-Interval Independent RSVP (RI-RSVP) RSVP) capability specified in Section 3 of RSVP-TE Scaling Techniques
capability specified in Section 3 of RSVP-TE Scaling Techniques
[RFC8370]. [RFC8370].
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] and [RFC4558].
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 LSP PPhop node: Previous-Previous-hop router along the label switched
path
LP-MP node: Merge Point router at the tail of Link-protecting bypass Nhop node: Next-hop router along the label switched path
PPhop node: Next-Next-hop router along the label switched path
PLR: Point of Local Repair router as defined in [RFC4090]
MP: Merge Point router as defined in [RFC4090]
LP-MP node: Merge Point router at the tail of Link-Protecting bypass
tunnel tunnel
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
Conditional PathTear: PathTear message containing a suggestion to a B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object
receiving downstream router to retain Path state if the receiving defined in Summary FRR extensions [I-D.ietf-mpls-summary-frr-rsvpte]
router is NP-MP and is added by the PLR for each protected LSP.
Remote PathTear: PathTear message sent from Point of Local Repair Conditional PathTear: A PathTear message containing a suggestion to a
(PLR) to MP to delete LSP state on MP if PLR had not reliably sent receiving downstream router to retain the path state if the receiving
backup Path state before router is an NP-MP
3. Problem Description 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
sent the backup Path state before
3. Problem Description
E E
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
A ----- B ----- C ----- D A ----- B ----- C ----- D
\ / \ /
\ / \ /
\ / \ /
\ / \ /
\ / \ /
\ / \ /
F F
Figure 1: Example Topology Figure 1: Example Topology
In the topology in Figure 1, consider a large number of LSPs from A In the topology in Figure 1, let us consider a large number of LSPs
to D transiting B and C. Assume that refresh interval has been from A to D transiting B and C. Assume that refresh interval has
configured to be long of the order of minutes and refresh reduction been configured to be long of the order of minutes and refresh
extensions are enabled on all routers. reduction extensions are enabled on all routers.
Also assume that node protection has been configured for the LSPs and Also let us assume that node protection has been configured for the
the LSPs are protected by each router in the following way LSPs and the LSPs are protected by each router in the following way
- A has made node protection available using bypass LSP A -> E -> C; - A has made node protection available using bypass LSP A -> E -> C;
A is the Point of Local Repair (PLR) and C is Node Protecting A is the PLR and C is the NP-MP
Merge Point (NP-MP)
- B has made node protection available using bypass LSP B -> F -> D; - B has made node protection available using bypass LSP B -> F -> D;
B is the PLR and D is the NP-MP B is the PLR and D is the NP-MP
- C has made link protection available using bypass LSP C -> B -> F - C has made link protection available using bypass LSP C -> B -> F
-> D; C is the PLR and D is the Link Protecting Merge Point (LP- -> D; C is the PLR and D is the LP-MP
MP)
In the above condition, assume that B-C link fails. The following is In the above condition, assume that 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.
1. B performs local repair and re-directs LSP traffic over the bypass 1. B performs local repair and re-directs LSP traffic over the bypass
LSP B -> F -> D. LSP B -> F -> D.
2. B also creates backup state for the LSP and triggers sending of 2. B also creates backup state for the LSP and triggers sending of
backup LSP state to D over the bypass LSP B -> F -> D. backup LSP state to D over the bypass LSP B -> F -> D.
3. D receives backup LSP states and merges the backups with the 3. D receives backup LSP states and merges the backups with the
protected LSPs. protected LSPs.
4. As the link on C, over which the LSP states are refreshed has 4. As the link on C, over which the LSP states are refreshed, has
failed, C will no longer receive state refreshes. Consequently failed, C will no longer receive state refreshes. Consequently
the protected LSP states on C will time out and C will send tear the protected LSP states on C will time out and C will send the
down message for all LSPs. As each router should consider itself tear down messages for all LSPs. As each router should consider
as a Merge Point, C will time out the state only after waiting for itself as an MP, C will time out the state only after waiting for
an additional duration equal to refresh timeout. an additional duration equal to refresh timeout.
While the above sequence of events has been described in [RFC4090], While the above sequence of events has been described in [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.
- If the protected LSP on C times out before D receives signaling - If the protected LSP on C times out before D receives signaling
for the backup LSP, then D would receive PathTear from C prior to for the backup LSP, then D would receive a PathTear from C prior
receiving signaling for the backup LSP, thus resulting in deleting to receiving signaling for the backup LSP, thus resulting in
the LSP state. This would be possible at scale even with default deleting the LSP state. This would be possible at scale even with
refresh time. default refresh time.
- If upon the link failure C is to keep state until its timeout, - 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 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 of stale state on C. Alternatively, if upon the link failure C is
to delete the state and send PathTear to D, this would result in 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 deleting the state on D, thus deleting the LSP. D needs a
reliable mechanism to determine whether it is MP or not to reliable mechanism to determine whether it is an MP or not to
overcome this problem. overcome this problem.
- If head-end A attempts to tear down LSP after step 1 but before - 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 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 message before step 2 and delete the LSP state from its state
database. If B deletes its state without informing D, with long database. If B deletes its state without informing D, with long
refresh interval this could cause (large) buildup of stale state refresh interval this could cause (large) buildup of stale state
on D. on D.
- If B fails to perform local repair in step 1, then B will delete - If B fails to perform local repair in step 1, then B will delete
skipping to change at page 7, line 46 skipping to change at page 8, line 14
addition, introduce PLR and MP procedures to establish Node-ID addition, introduce PLR and MP procedures to establish Node-ID
based hello session between the PLR and the MP to detect router based hello session between the PLR and the MP to detect router
failures and to determine capability. See section 4.2 for more failures and to determine capability. See section 4.2 for more
details. This part of the solution re-uses some of the extensions details. This part of the solution re-uses some of the extensions
defined in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte] defined in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte]
and RSVP-TE Scaling Techniques [RFC8370], and the subsequent sub- and RSVP-TE Scaling Techniques [RFC8370], and the subsequent sub-
sections will list the extensions in these drafts that are sections will list the extensions in these drafts that are
utilized in this document. utilized in this document.
- 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 MP through the MP determination the node has not found itself as an MP through the MP
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 tear down message - Introduce extensions to enable a router to send a tear down
to the downstream router that enables the receiving router to message to the downstream router that enables the receiving router
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 - Enhance facility protection by allowing a PLR to directly send a
tear down message to MP without requiring the PLR to either have a tear down message to the MP without requiring the PLR to either
working bypass LSP or have already signaled backup LSP state. See have a working bypass LSP or have already signaled backup LSP
section 4.5 for more details. 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 RFC 4090 facility protection FRR MAY set the RI- A node supporting [RFC4090] facility protection FRR MAY set the RI-
RSVP capability (I bit) defined in Section 3 of RSVP-TE Scaling RSVP capability (I bit) defined in Section 3 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 RFC 4090 facility in the rest of this document. A node supporting [RFC4090] facility
bypass FRR but not supporting the extensions specified in this bypass FRR but not supporting the extensions specified in this
document MUST reset RI-RSVP capability (I bit) in the outgoing Node- document MUST reset the RI-RSVP capability (I bit) in the outgoing
ID based Hello messages. Hence, this document updates RFC 4090 by Node-ID based Hello messages. Hence, this document updates [RFC4090]
defining extensions and additional procedures over facility by defining extensions and additional procedures over facility
protection FRR defined in RFC 4090 in order to advertise RI-RSVP protection FRR defined in [RFC4090] in order to advertise RI-RSVP
capability [RFC8370]. capability [RFC8370].
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 RFC 4090, when a protected LSP As per the procedures specified in [RFC4090], when a protected LSP
comes up and if the "local protection desired" flag is set in the comes up and if the "local protection desired" flag is set in the
SESSION_ATTRIBUTE object, each node along the LSP path attempts to SESSION_ATTRIBUTE object, each node along the LSP path attempts to
make local protection available for the LSP. 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 a LP-bypass LSP to Nhop node avoiding only the link that create an LP-bypass LSP to the Nhop node avoiding only the link
protected LSP takes to reach Nhop that the protected LSP takes to reach 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 a LP-bypass LSP to Nhop node avoiding the link attempts to create an LP-bypass LSP to the Nhop node avoiding the
that the protected LSP takes to reach 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 RFC 4090, this document specifies the following specified in [RFC4090], this document specifies the following
additional procedures to support RI-RSVP defined in RFC 8370. additional procedures to support RI-RSVP defined in [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 SHOULD select the router ID of the NNhop or Nhop node from the
Node-ID sub-object included RRO object carried in RESV message. Node-ID sub-object included in the RRO object carried in the Resv
If the MP has not included Node-ID sub-object in RESV RRO and if message. If the MP has not included a Node-ID sub-object in the
the PLR and the MP are in the same area, then the PLR may utilize Resv RRO and if the PLR and the MP are in the same area, then the
the TED to determine the router ID corresponding to the interface PLR may utilize the TED to determine the router ID corresponding
address included by the MP in the RRO object. If the NP-MP in a to the interface address included by the MP in the RRO object. If
different IGP area has not included Node-ID sub-object in RRO the NP-MP in a different IGP area has not included a Node-ID sub-
object, then the PLR SHOULD execute backward compatibility object in RRO object, then the PLR MUST execute backward
procedures as if the downstream nodes along the LSP do not support compatibility procedures as if the downstream nodes along the LSP
the extensions defined in the document (see Section 4.6.2.1). do not support the extensions defined in the document (see
Section 4.6.2.1).
- The PLR SHOULD also include its router ID in a Node-ID sub-object - The PLR MUST also include its router ID in a Node-ID sub-object in
in RRO object carried in PATH message. While including its router RRO object carried in a Path message. While including its router
ID in the Node-ID sub-object carried in the outgoing PATH message, 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 the PLR MUST include the Node-ID sub-object after including its
IPv4/IPv6 address or unnumbered interface ID sub-object. 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 SHOULD 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 to establish the RSVP-TE signaling
adjacency. This Hello session is used to detect MP node failure adjacency. This Hello session is used to detect MP node failure
as well as determine the capability of the MP node. If the MP has as well as determine the capability of the MP node. If the MP has
set the I-bit in CAPABILITY object [RFC8370] carried in Hello set the I-bit in the CAPABILITY object [RFC8370] carried in Hello
message corresponding to Node-ID based Hello session, then the PLR message corresponding to the Node-ID based Hello session, then the
SHOULD conclude that the MP supports refresh-interval independent PLR SHOULD conclude that the MP supports refresh-interval
FRR procedures defined in this document. If the MP has not sent independent FRR procedures defined in this document. If the MP
Node-ID based Hello messages or has not set the I-bit in has not sent Node-ID based Hello messages or has not set the I-bit
CAPABILITY object [RFC8370], then the PLR SHOULD execute backward in CAPABILITY object [RFC8370], then the PLR MUST execute backward
compatibility procedures defined in Section 4.6.2.1 of this compatibility procedures defined in Section 4.6.2.1 of this
document. document.
- If the bypass LSP comes up and the PLR has made local protection - If the bypass LSP comes up and the PLR has made local protection
available for one or more LSPs, then the PLR SHOULD include B- available for one or more LSPs, then [I-D.ietf-mpls-summary-frr-
SFRR-Ready Extended Association object and triggers PATH message rsvpte] applies: the PLR MUST include B-SFRR-Ready Extended
to be sent for those LSPs. If a B-SFRR-Ready Extended Association Association object and trigger a Path message to be sent for those
object is included in the PATH message, then the encoding and LSPs. If a B-SFRR-Ready Extended Association object is included
ordering rules object specified in RSVP-TE Summary FRR in the Path message, then the encoding and object ordering rules
specified in RSVP-TE Summary FRR
[I-D.ietf-mpls-summary-frr-rsvpte] MUST be followed. [I-D.ietf-mpls-summary-frr-rsvpte] MUST be followed.
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 SHOULD 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 PLR and MP. The default hello based Hello messages exchanged between the PLR and the MP. The
interval for this Node-ID hello session SHOULD be set to the default default hello interval for this Node-ID hello session SHOULD be set
specified in RSVP-TE Scaling Techniques [RFC8370]. to 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 RFC 4090, 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 RFC 8370. 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 SHOULD also include its router ID in the Node-ID sub-object document MUST also include its router ID in the Node-ID sub-object of
in the RRO object carried in the RESV message of the LSPs. If the the RRO object carried in the Resv message of the LSPs. If the PLR
PLR has not included Node-ID sub-object in the RRO object carried in has not included a Node-ID sub-object in the RRO object carried in
PATH message and if the PLR is in a different IGP area, then the the Path message and if the PLR is in a different IGP area, then the
router SHOULD NOT execute the MP procedures specified in this router MUST NOT execute the MP procedures specified in this document
document for those LSPs. Instead, the node SHOULD execute backward for those LSPs. Instead, the node MUST execute backward
compatibility procedures defined in Section 4.6.2.2 as if the compatibility procedures defined in Section 4.6.2.2 as if the
upstream nodes along the LSP do not support the extensions defined in upstream nodes along the LSP do not support the extensions defined in
this document. this document.
The node should determine whether the incoming PATH messages contains A node receiving Path messages should determine whether they contain
B-SFRR-Ready Extended Association object with the Node-ID address of a B-SFRR-Ready Extended Association object with the Node-ID address
the PLR as the source and its own Node-ID as the destination. In of the PLR as the source and its own Node-ID as the destination. In
addition the node should determine whether it has an operational addition the node should determine whether it has an operational
remote Node-ID signaling adjacency with the PLR. If either the PLR remote Node-ID signaling adjacency with the PLR. If either the PLR
has not included B-SFRR-Ready Extended Association object or if there has not included the B-SFRR-Ready Extended Association object or if
is no operational Node-ID signaling adjacency with the PLR or if the there is no operational Node-ID signaling adjacency with the PLR or
PLR has not advertised RI-RSVP capability in its Node-ID based Hello if the PLR has not advertised RI-RSVP capability in its Node-ID based
messages, then the node SHOULD execute backward compatibility Hello messages, then the node MUST execute 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
the PATH message and if there is an operational remote signaling the Path message and if there is an operational remote signaling
adjacency with the PLR that has advertised RI-RSVP capability (I-bit) adjacency with the PLR that has advertised RI-RSVP capability (I-bit)
[RFC8370] in its Node-ID based Hello messages, then the node SHOULD [RFC8370] in its Node-ID based Hello messages, then the node SHOULD
consider itself as the MP for the corresponding PLR. The matching consider itself as the MP for the corresponding PLR. The matching
and ordering rules for Bypass Summary FRR Extended Association and ordering rules for Bypass Summary FRR Extended Association
specified in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte] specified in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte]
MUST be followed by implementations supporting this document. MUST be 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 NP-MP. SHOULD 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 LP-MP. SHOULD 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, it SHOULD create a remote path
state for the LSP. The "remote" state is identical to the protected state for the LSP. The only difference between the "remote" path
LSP path state except for the difference in RSVP_HOP object. The state and the LSP state is the RSVP_HOP object. The RSVP_HOP object
RSVP_HOP object in "remote" Path state contains the address that the in a "remote" path state contains the address that the PLR uses to
PLR uses to send Node-ID hello messages to MP. send Node-ID hello messages to the MP.
The MP SHOULD consider the "remote" path state automatically deleted The MP SHOULD consider the "remote" path state automatically deleted
if: if:
- MP later receives a PATH with no matching B-SFRR-Ready Extended - The MP later receives a Path with no matching B-SFRR-Ready
Association object corresponding to the PLR's IP address contained Extended Association object corresponding to the PLR's IP address
in PATH RRO, or contained in the Path RRO, or
- Node signaling adjacency with PLR goes down, or - The Node-ID signaling adjacency with the PLR goes down, or
- MP receives backup LSP signaling from PLR or - The MP receives backup LSP signaling from the PLR or
- MP receives PathTear, or - The MP receives a PathTear, or
- MP deletes the LSP state on local policy or exception event - The MP deletes the LSP state on local policy or exception event
Unlike the normal path state that is either locally generated on the Unlike the normal path state that is either locally generated on the
Ingress or created from a PATH message from the Phop node, the ingress or created by a Path message from the Phop node, the "remote"
"remote" path state is not signaled explicitly from PLR. The purpose path state is not signaled explicitly from the PLR. The purpose of
of "remote" path state is to enable the PLR to explicitly tear down "remote" path state is to enable the PLR to explicitly tear down the
path and reservation states corresponding to the LSP by sending tear path and reservation states corresponding to the LSP by sending a
message for the "remote" path state. Such message tearing down tear message for the "remote" path state. Such a message tearing
"remote" path state is called "Remote PathTear". down "remote" path state is called "Remote" PathTear.
The scenarios in which "Remote" PathTear is applied are described in The scenarios in which a "Remote" PathTear is applied are described
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 for routers on the LSP path for
different kinds of failures. The procedures described on detecting different kinds of failures. The procedures described on detecting
RSVP control plane adjacency failures do not impact the RSVP-TE RSVP control plane adjacency failures do not impact the RSVP-TE
graceful restart mechanisms ([RFC3473], [RFC5063]). If the router graceful restart mechanisms ([RFC3473], [RFC5063]). If the router
executing these procedures act as helper for neighboring router, then executing these procedures act as helper for neighboring router, then
the control plane adjacency will be declared as having failed after the control plane adjacency will be declared as having failed after
taking into account the grace period extended for neighbor by the taking into account the grace period extended for neighbor by the
helper. helper.
Immediate node failures are detected from the state of Node-ID hello Node failures are detected from the state of Node-ID hello sessions
sessions established with immediate neighbors. RSVP-TE Scaling established with immediate neighbors. RSVP-TE Scaling Techniques
Techniques [RFC8370] recommends each router to establish Node-ID [RFC8370] recommends each router to establish Node-ID hello sessions
hello sessions with all its immediate neighbors. PLR or MP node with all its immediate neighbors. PLR or MP node failure is detected
failure is detected from the state of remote signaling adjacency from the state of remote signaling adjacency established according to
established according to Section 4.2.2 of this document. 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 Phop link or Phop node failure and the router
is not an MP for the LSP, then it SHOULD send Conditional PathTear is not an MP for the LSP, then it SHOULD send a Conditional PathTear
(refer to Section 4.4 "Conditional PathTear" below) and delete PSB (refer to Section 4.4 "Conditional PathTear" below) and delete the
and RSB states corresponding to the LSP. 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 LP-MP for the When the Phop link for an LSP fails on a router that is an LP-MP for
LSP, the LP-MP SHOULD retain PSB and RSB states corresponding to the the LSP, the LP-MP MUST retain the PSB and RSB states corresponding
LSP till the occurrence of any of the following events. to the LSP till the occurrence of any of the following events.
- Node-ID signaling adjacency with Phop PLR goes down, or - The Node-ID signaling adjacency with the Phop PLR goes down, or
- MP receives normal or "Remote" PathTear for PSB, or - The MP receives a normal or "Remote" PathTear for its PSB, or
- MP receives ResvTear RSB. - The MP receives a ResvTear for its RSB.
When a router that is LP-MP for an LSP detects Phop node failure from When a router that is an LP-MP for an LSP detects Phop node failure
Node-ID signaling adjacency state, the LP-MP SHOULD send normal from the Node-ID signaling adjacency state, the LP-MP SHOULD send a
PathTear and delete PSB and RSB states corresponding to the LSP. normal PathTear and delete the PSB and RSB states corresponding to
the LSP.
4.3.3. NP-MP Behavior 4.3.3. NP-MP Behavior
When a router that is NP-MP for an LSP detects Phop link failure, or When a router that is an NP-MP for an LSP detects Phop link failure,
Phop node failure from Node-ID signaling adjacency, the router SHOULD or Phop node failure from the Node-ID signaling adjacency, the router
retain 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.
- Remote Node-ID signaling adjacency with PPhop PLR goes down, or - The remote Node-ID signaling adjacency with the PPhop PLR goes
down, or
- MP receives normal or "Remote" PathTear for PSB, or - The MP receives a normal or "Remote" PathTear for its PSB, or
- MP receives ResvTear for RSB. - The MP receives a ResvTear for its RSB.
When a router that is NP-MP does not detect Phop link or node When a router that is an NP-MP does not detect Phop link or node
failure, but receives Conditional PathTear from the Phop node, then failure, but receives a Conditional PathTear from the Phop node, then
the router SHOULD retain PSB and RSB states corresponding to the LSP the router MUST retain the PSB and RSB states corresponding to the
till the occurrence of any of the following events. LSP till the occurrence of any of the following events.
- Remote Node-ID signaling adjacency with PPhop PLR goes down, or - The remote Node-ID signaling adjacency with the PPhop PLR goes
down, or
- MP receives normal or "Remote" PathTear for PSB, or - The MP receives a normal or "Remote" PathTear for its PSB, or
- MP receives ResvTear for RSB. - The MP receives a ResvTear for its RSB.
Receiving Conditional PathTear from the Phop node will not impact the Receiving a Conditional PathTear from the Phop node will not impact
"remote" state from the PPhop PLR. Note that Phop node would send the "remote" state from the PPhop PLR. Note that Phop node would
Conditional PathTear if it was not an MP. send a Conditional PathTear if it was not an MP.
In the example topology in Figure 1, assume C & D are NP-MP for PLRs In the example topology in Figure 1, we assume C & D are the NP-MPs
A & B respectively. Now when A-B link fails, as B is not MP and its for the PLRs A & B respectively. Now when A-B link fails, as B is
Phop link has failed, B will delete LSP state (this behavior is not an MP and its Phop link has failed, B will delete LSP state (this
required for unprotected LSPs - Section 4.3.1). In the data plane, behavior is required for unprotected LSPs - Section 4.3.1). In the
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 NP-MP for 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 Conditional PathTear from B, it decides to retain 1. When C receives a Conditional PathTear from B, it decides to
LSP state as it is NP-MP of PLR A. C also SHOULD check whether retain LSP state as it is the NP-MP of the PLR A. C also SHOULD
Phop B had previously signaled availability of node protection. check whether Phop B had previously signaled availability of node
As B had previously signaled NP availability by including B-SFRR- protection. As B had previously signaled NP availability by
Ready Extended Association object, C SHOULD remove the B-SFRR- including B-SFRR-Ready Extended Association object, C SHOULD
Ready Extended Association object containing Association Source remove the B-SFRR-Ready Extended Association object containing
set to B from the PATH message and trigger PATH to D. Association Source set to B from the Path message and trigger a
Path to D.
2. When D receives triggered PATH, it realizes that it is no longer 2. When D receives a triggered Path, 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 PATH further down because the only state. D does not propagate the Path further down because the
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 both LP-MP as well as NP-MP at the same time for Phop A router may be simultaneously the LP-MP as well as the NP-MP for the
and PPhop nodes respectively of an LSP. If Phop link fails on such Phop and the PPhop nodes respectively of an LSP. If Phop link fails
node, the node SHOULD retain PSB and RSB states corresponding to the on such node, 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.
- 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
- MP receives normal or "Remote" PathTear for PSB, or - The MP receives a normal or "Remote" PathTear for its PSB, or
- MP receives ResvTear for 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 LP-MP and NP-MP detects Phop node failure,
then the node SHOULD retain PSB and RSB states corresponding to the then the node MUST retain the PSB and RSB states corresponding to the
LSP till the occurrence of any of the following events. LSP till the occurrence of any of the following events.
- Remote Node-ID signaling adjacency with PPhop PLR goes down, or - The remote Node-ID signaling adjacency with the PPhop PLR goes
down, or
- MP receives normal or "Remote" PathTear for PSB, or - The MP receives a normal or "Remote" PathTear for its PSB, or
- MP receives ResvTear for RSB. - The MP receives a ResvTear for its RSB.
4.4. Conditional Path Tear 4.4. Conditional PathTear
In the example provided in the Section 4.3.3, B deletes PSB and RSB In the example provided in the Section 4.3.3, B deletes the PSB and
states corresponding to the LSP once B detects its link to Phop went RSB states corresponding to the LSP once B detects its link to Phop
down as B is not MP. If B were to send PathTear normally, then C went down as B is not an MP. If B were to send a PathTear normally,
would delete LSP state immediately. In order to avoid this, there then C would delete LSP state immediately. In order to avoid this,
should be some mechanism by which B can indicate to C that B does not there should be some mechanism by which B can indicate to C that B
require the receiving node to unconditionally delete the LSP state does not require the receiving node to unconditionally delete the LSP
immediately. For this, B SHOULD add a new optional object called state immediately. For this, B SHOULD add a new optional CONDITIONS
CONDITIONS object in PathTear. The new optional object is defined in object in the PathTear. The CONDITIONS object is defined in
Section 4.4.3. If node C also understands the new object, then C Section 4.4.3. If node C also understands the new object, then C
SHOULD delete LSP state only if it is not an NP-MP - in other words C SHOULD delete LSP state only if it is not an NP-MP - in other words C
SHOULD delete LSP state if there is no "remote" PLR path state on C. SHOULD delete LSP state if there is no "remote" PLR path state on C.
4.4.1. Sending Conditional Path Tear 4.4.1. Sending Conditional PathTear
A router that is not an MP for an LSP SHOULD delete PSB and RSB A router that is not an MP for an LSP SHOULD delete the PSB and RSB
states corresponding to the LSP if Phop link or 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 SHOULD
send Conditional PathTear if the following are also true. send a Conditional PathTear if the following are also true.
- Ingress has requested node protection for the LSP, and - The ingress has requested node protection for the LSP, and
- PathTear is not received from the upstream node - No PathTear is received from the upstream node
4.4.2. Processing Conditional Path Tear 4.4.2. Processing Conditional PathTear
When a router that is not an NP-MP receives Conditional PathTear, the When a router that is not an NP-MP receives a Conditional PathTear,
node SHOULD delete PSB and RSB states corresponding to the LSP, and the node SHOULD delete the PSB and RSB states corresponding to the
process Conditional PathTear by considering it as normal PathTear. LSP, and process the Conditional PathTear by considering it as a
Specifically, the node SHOULD NOT propagate Conditional PathTear normal PathTear. Specifically, the node MUST NOT propagate the
downstream but remove the optional object and send normal PathTear Conditional PathTear downstream but remove the optional object and
downstream. send a normal PathTear downstream.
When a node that is an NP-MP receives Conditional PathTear, it SHOULD 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 SHOULD check whether the Phop node
had previously included B-SFRR-Ready Extended Association object in had previously included the B-SFRR-Ready Extended Association object
PATH. If the object had been included previously by the Phop, then in the Path. If the object had been included previously by the Phop,
the node processing Conditional PathTear from the Phop SHOULD remove then the node processing the Conditional PathTear from the Phop
the corresponding object and trigger PATH downstream. SHOULD remove the corresponding object and trigger a Path downstream.
If 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 SHOULD consider the message
as normal PathTear. The node SHOULD propagate normal PathTear as a normal PathTear. The node SHOULD 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
SHOULD ignore the new object but process the message as normal SHOULD ignore the new object but process the message as a normal
PathTear without generating any error, the Class-Num of the new PathTear without generating any error, the Class-Num of the new
object SHOULD be 10bbbbbb where 'b' represents a bit (from object MUST be 10bbbbbb where 'b' represents a bit (from Section 3.10
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 SHOULD 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |M| | Reserved |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CONDITIONS Object Figure 2: CONDITIONS Object
Length Length: This contains the size of the object in bytes and should
This contains the size of the object in bytes and should be set to be set to eight.
eight.
Class Class: To be assigned
To be assigned
C-type C-type: 1
1
M bit M bit: If the M bit is set to 1, then the PathTear message SHOULD
If M-bit is set to 1, then the PathTear message SHOULD be be processed according to the receiver router role, i.e. if it is
processed based on the condition if the receiver router is a Merge an MP or not.
Point or not.
If M-bit is set to 0, then the PathTear message SHOULD be If M-bit is set to 0, then the PathTear message SHOULD be
processed as normal PathTear message. processed as a normal PathTear message.
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 "remote" the LSP is being locally repaired, the PLR SHOULD send a "Remote"
PathTear message instructing the MP to delete PSB and RSB states PathTear message instructing the MP to delete the PSB and RSB states
corresponding to the LSP. The TTL in "remote" PathTear message corresponding to the LSP. The TTL in the "Remote" PathTear message
SHOULD be set to 255. SHOULD be set to 255.
Consider node C in example topology (Figure 1) has gone down and B Let us consider that node C, in example topology (Figure 1), has gone
locally repairs the LSP. down and 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 normal PathTear to B. 2. A sends a normal PathTear to B.
3. Assume B has not initiated backup signaling for the LSR. To 3. Assume B has not initiated backup signaling for the LSR. To
enable LSP state cleanup, B SHOULD send "remote" PathTear with enable LSP state cleanup, B SHOULD send a "Remote" PathTear with
destination IP address set to that of D used in Node-ID signaling destination IP address set to that of D used in the Node-ID
adjacency with D, and RSVP_HOP object containing local address signaling adjacency with D, and RSVP_HOP object containing local
used in Node-ID signaling adjacency. address used in the Node-ID signaling adjacency.
4. B then deletes 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 PSB and RSB states SHOULD accept the "Remote" PathTear and delete the PSB and RSB
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 should be
considered as a case for cleaning up LSP state from PLR to the considered as a case for cleaning up LSP state from the PLR to the
Egress. PLR would achieve this using "remote" PathTear to clean up Egress. The PLR would achieve this using "Remote" PathTear to clean
state from MP. If MP has retained state, then it would propagate up the state from the MP. If the MP has retained the LSP state, then
PathTear downstream thereby achieving state cleanup. Note that in it would propagate the PathTear downstream thereby achieving state
the case of link protection, the PathTear would be directed to LP-MP cleanup. Note that in the case of link protection, the PathTear
node IP address rather than the Nhop interface address. would be directed to the LP-MP node's 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 router that has already made NP available detects a change in When a PLR router that has already made NP available detects a change
the RRO carried in RESV message, and if the RRO change indicates that in the RRO carried in the Resv message indicating that the router's
the router's former NP-MP is no longer present in the LSP path, then former NP-MP is no longer present in the LSP path, then the router
the router SHOULD send "Remote" PathTear directly to its former NP- SHOULD send a "Remote" PathTear directly to its former NP-MP.
MP.
In the example topology in Figure 1, assume A has made node In the example topology in Figure 1, let us assume A has made node
protection available and C has concluded it is the NP-MP for A. When protection available and C has concluded it is the NP-MP for PLR A.
the B-C link fails then C, implementing the procedure specified in When the B-C link fails then C, implementing the procedure specified
Section 4.3.4 of this document, will retain state till: remote Node- in Section 4.3.4 of this document, will retain state till: the remote
ID signaling adjacency with A goes down, or PathTear or ResvTear is Node-ID signaling adjacency with A goes down, or a PathTear or a
received for PSB or RSB respectively. If B also has made node ResvTear is received for its PSB or RSB respectively. If B also has
protection available, B will eventually complete backup LSP signaling made node protection available, B will eventually complete backup LSP
with its NP-MP D and trigger RESV to A with RRO changed. The new RRO signaling with its NP-MP D and trigger a Resv to A with RRO changed.
of the LSP carried in RESV will not contain C. When A processes the The new RRO of the LSP carried in the Resv will not contain C. When
RESV with a new RRO not containing C - its former NP-MP, A SHOULD A processes the Resv with a new RRO not containing C - its former NP-
send "Remote" PathTear to C. When C receives a "Remote" PathTear for MP, A SHOULD send a "Remote" PathTear to C. When C receives the
its PSB state, C will send normal PathTear downstream to D and delete "Remote" PathTear for its PSB state, C will send a normal PathTear
both PSB and RSB states corresponding to the LSP. As D has already downstream to D and delete both the PSB and RSB states corresponding
received backup LSP signaling from B, D will retain control plane and to the LSP. As D has already received backup LSP signaling from B, D
forwarding states corresponding to the LSP. 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 LP-MP after its Phop or incoming link has If an LSP is preempted on an LP-MP after its Phop or incoming link
already failed but the backup LSP has not been signaled yet, then the has already failed but the backup LSP has not been signaled yet, then
node SHOULD send normal PathTear and delete both PSB and RSB states the node SHOULD send a normal PathTear and delete both the PSB and
corresponding to the LSP. As the LP-MP has retained LSP state RSB states corresponding to the LSP. As the LP-MP has retained LSP
expecting the PLR to perform backup LSP signaling, preemption would state expecting the PLR to perform backup LSP signaling, preemption
bring down the LSP and the node would not be LP-MP any more requiring would bring down the LSP and the node would not be LP-MP any more
the node to clean up LSP state. requiring the node to clean up 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 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 normal PathTear and delete PSB and RSB states SHOULD 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 perform 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.
Consider B-C link goes down on the same example topology (Figure 1). Let us consider that B-C link goes down on the same example topology
As C is NP-MP for PLR A, C will retain LSP state. (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP
state.
1. The LSP is preempted on C. 1. The LSP is preempted on C.
2. C will delete RSB state corresponding to the LSP. But C cannot 2. C will delete the RSB state corresponding to the LSP. But C
send PathErr or ResvTear to PLR A because backup LSP has not been cannot send a PathErr or a ResvTear to the PLR A because the
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 NP-MP, C SHOULD send normal PathTear to D failure was that it was an NP-MP, C SHOULD send a normal PathTear
and delete PSB state also. D would also delete PSB and RSB states to D and delete its PSB state also. D would also delete the PSB
on receiving PathTear from C. and 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 backup LSP PATH and send PathErr to B. LSP state, it will reject the backup LSP Path and send a PathErr
to B.
5. B will delete its reservation and send 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 The "Refresh interval Independent FRR" or RI-RSVP-FRR referred below
in this section refers to the changes that have been proposed in in this section refers to the changes that have been defined in
previous sections. Any implementation that does not support them has previous sections. Any implementation that does not support them has
been termed as "non-RI-RSVP-FRR implementation". The extensions been termed as "non-RI-RSVP-FRR implementation". The extensions
proposed in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte] proposed in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte]
are applicable to implementations that do not support RI-RSVP-FRR. are applicable to implementations that do not support RI-RSVP-FRR.
On the other hand, changes proposed relating to LSP state cleanup On the other hand, changes proposed relating to LSP state cleanup
namely Conditional and remote PathTear require support from one-hop namely Conditional and "Remote" PathTear require support from one-hop
and two-hop neighboring nodes along the LSP path. So procedures that and two-hop neighboring nodes along the LSP path. So procedures that
fall under LSP state cleanup category SHOULD be turned on only if all fall under LSP state cleanup category SHOULD be turned on only if all
nodes involved in the node protection FRR i.e. PLR, MP and nodes involved in the node protection FRR i.e. the PLR, the MP and
intermediate node in the case of NP, support the extensions. Note the intermediate node in the case of NP, support the extensions.
that for LSPs requesting only link protection, the PLR and the LP-MP Note that for LSPs requesting only link protection, the PLR and the
should support the extensions. LP-MP 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 the extensions specified in previous
sections (called RI-RSVP-FRR here after) SHOULD set the flag "Refresh sections (called RI-RSVP-FRR here after) SHOULD set the flag "Refresh
interval Independent RSVP" or RI-RSVP in CAPABILITY object carried in interval Independent RSVP" or RI-RSVP flag in the CAPABILITY object
Hello messages. The RI-RSVP flag is specified in RSVP-TE Scaling carried in Hello messages. The RI-RSVP flag is specified in RSVP-TE
Techniques [RFC8370]. Scaling Techniques [RFC8370].
- As nodes supporting the extensions SHOULD initiate Node Hellos - As nodes supporting the extensions SHOULD initiate Node Hellos
with adjacent nodes, a node on the path of protected LSP can with adjacent nodes, a node on the path of protected LSP can
determine whether its Phop or Nhop neighbor supports RI-RSVP-FRR determine whether its Phop or Nhop neighbor supports RI-RSVP-FRR
enhancements from the Hello messages sent by the neighbor. enhancements from the Hello messages sent by the neighbor.
- If a node attempts to make node protection available, then the PLR - If a node attempts to make node protection available, then the PLR
SHOULD initiate remote Node-ID signaling adjacency with NNhop. If SHOULD initiate a remote Node-ID signaling adjacency with its
the NNhop (a) does not reply to remote node Hello message or (b) NNhop. If the NNhop (a) does not reply to remote node Hello
does not set RI-RSVP flag in CAPABILITY object carried in its message or (b) does not set the RI-RSVP flag in the CAPABILITY
Node-ID Hello messages, then the PLR can conclude that NNhop does object carried in its Node-ID Hello messages, then the PLR can
not support RI-RSVP-FRR extensions. conclude that NNhop does not support RI-RSVP-FRR extensions.
- If node protection is requested for an LSP and if (a) PPhop node - If node protection is requested for an LSP and if (a) the PPhop
has not included a matching B-SFRR-Ready Extended Association node has not included a matching B-SFRR-Ready Extended Association
object in PATH or (b) PPhop node has not initiated remote node object in its Path messages or (b) the PPhop node has not
Hello messages or (c) PPhop node does not set RI-RSVP flag in initiated remote node Hello messages or (c) the PPhop node does
CAPABILITY object carried in its Node-ID Hello messages, then the not set the RI-RSVP flag in the CAPABILITY object carried in its
node SHOULD conclude that the PLR does not support RI-RSVP-FRR Node-ID Hello messages, then the node MUST conclude that the PLR
extensions. The details are described in the "Procedures for does not support RI-RSVP-FRR extensions. The details are
backward compatibility" section below. 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 The procedures defined hereafter are performed on a subset of LSPs
that traverse a node, rather than on all LSPs that traverse a node. that traverse a node, rather than on all LSPs that traverse a node.
This behavior is required to support backward compatibility for a This behavior is required to support backward compatibility for a
subset of LSPs traversing nodes running non-RI-RSVP-FRR subset of LSPs traversing nodes running non-RI-RSVP-FRR
implementations. 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 the Nhop does not support the RI-RSVP-FRR extensions, then the
node SHOULD reduce the "refresh period" in TIME_VALUES object node SHOULD reduce the "refresh period" in the TIME_VALUES object
carried in PATH to default short refresh default value. carried in the Path to the default short refresh interval.
- If node protection is requested and the NNhop node does not - If node protection is requested and the NNhop node does not
support the enhancements, then the node SHOULD reduce the "refresh support the enhancements, then the node SHOULD reduce the "refresh
period" in TIME_VALUES object carried in PATH to a short refresh period" in the TIME_VALUES object carried in the Path to the
default value. default short refresh interval.
If the node reduces the refresh time from the above procedures, it If the node reduces the refresh time from the above procedures, it
SHOULD also not send remote PathTear or Conditional PathTear MUST NOT send any "Remote" PathTear or Conditional PathTear messages.
messages.
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 value of 30 - A and B SHOULD reduce the refresh time to default short refresh
seconds and trigger PATH interval of 30 seconds and trigger a Path
- 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 SHOULD time out 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. This would be accomplished if A would also reduce the
refresh time to default value. So if C does not support the RI- refresh time to default value. So if C does not support the RI-
RSVP-FRR extensions, then Phop B and PPhop A SHOULD reduce refresh RSVP-FRR extensions, then Phop B and the PPhop A SHOULD reduce the
time to a small default value. 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 on the upstream direction are as follows. The procedures on the upstream direction are as follows.
- If Phop node does not support the RI-RSVP-FRR extensions, then the - If Phop node does not support the RI-RSVP-FRR extensions, then the
node SHOULD reduce the "refresh period" in TIME_VALUES object node SHOULD reduce the "refresh period" in the TIME_VALUES object
carried in RESV to default short refresh time value. carried in the Resv to the default short refresh interval.
- If node protection is requested and the Phop node does not support - If node protection is requested and the Phop node does not support
the RI-RSVP-FRR extensions, then the node SHOULD reduce the the RI-RSVP-FRR extensions, then the node SHOULD reduce the
"refresh period" in TIME_VALUES object carried in PATH to default "refresh period" in the TIME_VALUES object carried in the Path to
value. the default short refresh interval.
- If node protection is requested and PPhop node does not support - If node protection is requested and the PPhop node does not
the RI-RSVP-FRR extensions, then the node SHOULD reduce the support the RI-RSVP-FRR extensions, then the node SHOULD reduce
"refresh period" in TIME_VALUES object carried in RESV to default the "refresh period" in the TIME_VALUES object carried in the Resv
value. 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 from the above procedures, it
SHOULD also not execute MP procedures specified in Section 4.3 of SHOULD also not execute MP procedures specified in Section 4.3 of
this document. this document.
4.6.2.3. Incremental Deployment 4.6.2.3. 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
skipping to change at page 21, line 24 skipping to change at page 21, line 49
node protection is requested for the LSP and both Nhop & NNhop node protection is requested for the LSP and both Nhop & NNhop
nodes support the extensions nodes support the extensions
- RI-RSVP-FRR extensions and procedures are enabled for upstream - RI-RSVP-FRR extensions and procedures are enabled for upstream
PathErr, Resv and ResvTear messages corresponding to an LSP if PathErr, Resv and ResvTear messages corresponding to an LSP if
link protection is requested for the LSP and the Phop node link protection is requested for the LSP and the Phop node
supports the extensions supports the extensions
- RI-RSVP-FRR extensions and procedures are enabled for upstream - RI-RSVP-FRR extensions and procedures are enabled for upstream
PathErr, Resv and ResvTear messages corresponding to an LSP if PathErr, Resv and ResvTear messages corresponding to an LSP if
node protection is requested for the LSP and both Phop and PPhop node protection is requested for the LSP and both Phop and the
nodes support the extensions PPhop support the extensions
For example, if an implementation supporting the RI-RSVP-FRR For example, if an implementation supporting the RI-RSVP-FRR
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 the original RSVP protocol
[RFC2205], [RFC3209] and [RFC5920] remain relevant. [RFC2205], [RFC3209] and [RFC5920] remain relevant.
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 PLR and NP-MP may require the two routers to exchange Hello between the PLR and the NP-MP may require the two routers to exchange
messages with non-immediate neighbor. So, the implementations SHOULD Hello messages with non-immediate neighbor. So, the implementations
provide the option to configure Node-ID neighbor specific or global SHOULD provide the option to configure Node-ID neighbor specific or
authentication key to authentication messages received from Node-ID global authentication key to authentication messages received from
neighbors. The network administrator MAY utilize this option to Node-ID neighbors. The network administrator MAY utilize this option
enable RSVP-TE routers to authenticate Node-ID Hello messages to enable RSVP-TE routers to authenticate Node-ID Hello messages
received with TTL greater than 1. Implementations SHOULD also received with TTL greater than 1. Implementations SHOULD also
provide the option to specify a limit on the number of Node-ID based 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 Hello sessions that can be established on a router supporting the
extensions defined in this document. 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
skipping to change at page 22, line 31 skipping to change at page 23, line 8
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 Thanks to Raveendra Torvi and Yimin Shen for their comments and
inputs. inputs.
8. Contributors 8. Contributors
Markus Jork Markus Jork
Juniper Networks 128 Technology
Email: mjork@juniper.net Email: mjork@128technology.net
Harish Sitaraman Harish Sitaraman
Juniper Networks Individual Contributor
Email: hsitaraman@juniper.net Email: harish.ietf@gmail.com
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks, Inc.
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Ebben Aries Ebben Aries
Juniper Networks Arrcus, Inc.
Email: exa@juniper.net Email: exa@arrcus.com
Mike Taillon Mike Taillon
Cisco Systems Inc. Cisco Systems, Inc.
Email: mtaillon@cisco.com Email: mtaillon@cisco.com
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-mpls-summary-frr-rsvpte] [I-D.ietf-mpls-summary-frr-rsvpte]
Taillon, M., Saad, T., Gandhi, R., Deshmukh, A., Jork, M., Taillon, M., Saad, T., Gandhi, R., Deshmukh, A., Jork, M.,
and V. Beeram, "RSVP-TE Summary Fast Reroute Extensions and V. Beeram, "RSVP-TE Summary Fast Reroute Extensions
for LSP Tunnels", draft-ietf-mpls-summary-frr-rsvpte-02 for LSP Tunnels", draft-ietf-mpls-summary-frr-rsvpte-04
(work in progress), November 2018. (work in progress), May 2019.
[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>.
skipping to change at page 24, line 28 skipping to change at page 25, line 4
Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018,
<https://www.rfc-editor.org/info/rfc8370>. <https://www.rfc-editor.org/info/rfc8370>.
9.2. Informative References 9.2. Informative References
[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 Juniper Networks, Inc.
Email: csekar@juniper.net Email: csekar@juniper.net
Tarek Saad
Juniper Networks, Inc.
Email: tsaad@juniper.net
Ina Minei Ina Minei
Google, Inc Google, Inc.
Email: inaminei@google.com Email: inaminei@google.com
Dante Pacella Dante Pacella
Verizon Verizon, Inc.
Email: dante.j.pacella@verizon.com Email: dante.j.pacella@verizon.com
Tarek Saad
Cisco Systems Inc.
Email: tsaad@cisco.com
 End of changes. 171 change blocks. 
403 lines changed or deleted 421 lines changed or added

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