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/