rfc9705.original		rfc9705.txt
	MPLS Working Group C. Ramachandran		Internet Engineering Task Force (IETF) C. Ramachandran
	Internet-Draft Juniper Networks, Inc.		Request for Comments: 9705 Juniper Networks, Inc.
	Updates: 4090 (if approved) T. Saad		Updates: 4090 T. Saad
	Intended status: Standards Track Cisco Systems, Inc.		Category: Standards Track Cisco Systems, Inc.
	Expires: 14 February 2025 I. Minei		ISSN: 2070-1721 I. Minei
	Google, Inc.		Google, Inc.
	D. Pacella		D. Pacella
	Verizon, Inc.		Verizon, Inc.
	13 August 2024		December 2024
	Refresh-interval Independent FRR Facility Protection		Refresh-Interval Independent Fast Reroute (FRR) Facility Protection
	draft-ietf-mpls-ri-rsvp-frr-22
	Abstract		Abstract
	The RSVP-TE Fast Reroute extensions specified in RFC 4090 defines two		The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090
	local repair techniques to reroute Label Switched Path (LSP) traffic		define two local repair techniques to reroute Label Switched Path
	over pre-established backup tunnel. Facility backup method allows		(LSP) traffic over pre-established backup tunnels. Facility backup
	one or more LSPs traversing a connected link or node to be protected		methods allow one or more LSPs traversing a connected link or node to
	using a bypass tunnel. The many-to-one nature of local repair		be protected using a bypass tunnel. The many-to-one nature of local
	technique is attractive from scalability point of view. This		repair techniques is attractive from a scalability point of view.
	document enumerates facility backup procedures in RFC 4090 that rely		This document enumerates facility backup procedures in RFC 4090 that
	on refresh timeout and hence make facility backup method refresh-		rely on refresh timeout, hence, making facility backup methods
	interval dependent. The RSVP-TE extensions defined in this document		refresh-interval dependent. The RSVP-TE extensions defined in this
	will enhance the facility backup protection mechanism by making the		document will enhance the facility backup protection mechanism by
	corresponding procedures refresh-interval independent and hence		making the corresponding procedures refresh-interval independent, and
	compatible with Refresh-interval Independent RSVP (RI-RSVP) specified		hence, compatible with the Refresh-Interval Independent RSVP (RI-
	in RFC 8370. Hence, this document updates RFC 4090 in order to		RSVP) capability specified in RFC 8370. Hence, this document updates
	support RI-RSVP capability specified in RFC 8370.		RFC 4090 in order to support the RI-RSVP capability specified in RFC
			8370.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 14 February 2025.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9705.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Motivation
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology
	3. Problem Description . . . . . . . . . . . . . . . . . . . . . 6		2.1. Requirements Language
	4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 8		3. Problem Description
	4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP		4. Solution Aspects
	Capability . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. Requirement on RFC 4090 Capable Node to Advertise the
	4.2. Signaling Handshake between PLR and MP . . . . . . . . . 9		RI-RSVP Capability
	4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9		4.2. Signaling Handshake Between PLR and MP
	4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10		4.2.1. PLR Behavior
	4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 11		4.2.2. Remote Signaling Adjacency
	4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 12		4.2.3. MP Behavior
	4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12		4.2.4. "Remote" State on MP
	4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 13		4.3. Impact of Failures on LSP State
	4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13		4.3.1. Non-MP Behavior
	4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13		4.3.2. LP-MP Behavior
	4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 15		4.3.3. NP-MP Behavior
	4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15		4.3.4. Behavior of a Router That Is Both the LP-MP and NP-MP
	4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15		4.4. Conditional PathTear
	4.4.2. Processing Conditional PathTear . . . . . . . . . . . 16		4.4.1. Sending the Conditional PathTear
	4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16		4.4.2. Processing the Conditional PathTear
	4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 17		4.4.3. CONDITIONS Object
	4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 18		4.5. Remote State Teardown
	4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 18		4.5.1. PLR Behavior on Local Repair Failure
	4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18		4.5.2. PLR Behavior on Resv RRO Change
	4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 19		4.5.3. LSP Preemption During Local Repair
	4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 19		4.5.3.1. Preemption on LP-MP After Phop Link Failure
	4.6. Backward Compatibility Procedures . . . . . . . . . . . . 20		4.5.3.2. Preemption on NP-MP After Phop Link Failure
	4.6.1. Detecting Support for Refresh interval Independent		4.6. Backward Compatibility Procedures
	FRR . . . . . . . . . . . . . . . . . . . . . . . . . 20		4.6.1. Detecting Support for Refresh-Interval Independent FRR
	4.6.2. Procedures for Backward Compatibility . . . . . . . . 21		4.6.2. Procedures for Backward Compatibility
	4.6.2.1. Lack of support on Downstream Node . . . . . . . 21		4.6.2.1. Lack of Support on Downstream Nodes
	4.6.2.2. Lack of support on Upstream Node . . . . . . . . 21		4.6.2.2. Lack of Support on Upstream Nodes
	4.6.2.3. Incremental Deployment . . . . . . . . . . . . . 22		4.6.2.3. Incremental Deployment
	4.7. Consequence of Advertising RI-RSVP without RI-RSVP-FRR . 23		4.7. Consequences of Advertising RI-RSVP Without RI-RSVP-FRR
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 24		5. Security Considerations
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		6. IANA Considerations
	6.1. CONDITIONS Object . . . . . . . . . . . . . . . . . . . . 24		6.1. CONDITIONS Object
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25		7. References
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25		7.1. Normative References
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		7.2. Informative References
	9.1. Normative References . . . . . . . . . . . . . . . . . . 25		Acknowledgements
	9.2. Informative References . . . . . . . . . . . . . . . . . 27		Contributors
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses
	1. Introduction		1. Introduction
	RSVP-TE relies on periodic refresh of RSVP messages to synchronize		RSVP-TE relies on a periodic refresh of RSVP messages to synchronize
	and maintain the Label Switched Path (LSP) related states along the		and maintain the states related to the Label Switched Path (LSP)
	reserved path. In the absence of refresh messages, the LSP-related		along the reserved path. In the absence of refresh messages, the
	states are automatically deleted. Reliance on periodic refreshes and		LSP-related states are automatically deleted. Reliance on periodic
	refresh timeouts are problematic from the scalability point of view.		refreshes and refresh timeouts are problematic from the scalability
	The number of RSVP-TE LSPs that a router needs to maintain has been		point of view. The number of RSVP-TE LSPs that a router needs to
	growing in service provider networks and the implementations should		maintain has been growing in service provider networks, and the
	be capable of handling increase in LSP scale.		implementations should be capable of handling increases in LSP scale.
	[RFC2961] specifies mechanisms to eliminate the reliance on periodic		[RFC2961] specifies mechanisms to eliminate the reliance on periodic
	refresh and refresh timeout of RSVP messages and enables a router to		refreshes and refresh timeouts of RSVP messages and enables a router
	increase the message refresh interval to values much longer than the		to increase the message refresh interval to values much longer than
	default 30 seconds defined in [RFC2205]. However, the protocol		the default 30 seconds defined in [RFC2205]. However, the protocol
	extensions defined in [RFC4090] for supporting Fast Reroute (FRR)		extensions defined in [RFC4090] 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.		clean up 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. In scenarios involving [RFC4090] FRR using bypass tunnels,		deleted. In scenarios involving FRR using bypass tunnels [RFC4090],
	additional explicit tear down messages are necessary. Refresh-		additional explicit teardown messages are necessary. The Refresh-
	interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in		Interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in
	this document consists of procedures to enable LSP state cleanup that		this document consist of procedures to enable LSP state cleanup that
	are essential in supporting RI-RSVP capability for [RFC4090] FRR		are essential in supporting the RI-RSVP capability for FRR using
	using bypass tunnels.		bypass tunnels from [RFC4090].
	1.1. Motivation		1.1. Motivation
	Base RSVP [RFC2205] maintains state via the generation of RSVP Path/		Base RSVP [RFC2205] maintains state via the generation of RSVP Path
	Resv refresh messages. Refresh messages are used to both synchronize		and Resv refresh messages. Refresh messages are used to both
	state between RSVP neighbors and to recover from lost RSVP messages.		synchronize state between RSVP neighbors and to recover from lost
	The use of Refresh messages to cover many possible failures has		RSVP messages. The use of Refresh messages to cover many possible
	resulted in a number of operational problems.		failures has 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 and 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 [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 also
	eliminating dependency on refresh timeout for stale state cleanup.		by 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 timeouts for stale state cleanup, refer to
	"Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling		Section 3 of [RFC8370].
	Techniques [RFC8370].
	However, the facility backup protection procedures specified in		However, the facility backup protection procedures specified in
	[RFC4090] do not fully address stale state cleanup as the procedures		[RFC4090] do not fully address stale state cleanup as the procedures
	depend on refresh timeouts for stale state cleanup. The updated		depend on refresh timeouts for stale state cleanup. The updated
	facility backup protection procedures specified in this document, in		facility backup protection procedures specified in this document, in
	combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this		combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this
	dependency on refresh timeouts for stale state cleanup.		dependency on refresh timeouts for stale state cleanup.
	The procedures specified in this document assume reliable delivery of		The procedures specified in this document assume reliable delivery of
	RSVP messages, as specified in [RFC2961]. Therefore, this document		RSVP messages, as specified in [RFC2961]. Therefore, this document
	makes support for [RFC2961] a pre-requisite.		makes support for [RFC2961] a prerequisite.
	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], [RFC4558], [RFC8370] and [RFC8796].		[RFC2205], [RFC3209], [RFC4090], [RFC4558], [RFC8370], and [RFC8796].
	Phop node: Previous-hop router along the label switched path		Phop node: Previous-Hop router along the LSP
	PPhop node: Previous-Previous-hop router along the label switched		PPhop node: Previous-Previous-Hop router along the LSP
	path
	Nhop node: Next-hop router along the label switched path		Nhop node: Next-Hop router along the LSP
	NNhop node: Next-Next-hop router along the label switched path		NNhop node: Next-Next-Hop router along the LSP
	PLR: Point of Local Repair router as defined in [RFC4090]		PLR: Point of Local Repair router as defined in [RFC4090]
	MP: Merge Point 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		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
	RRO: Record Route Object as defined in [RFC3209]		PSB: Path State Block
	TED: Traffic Engineering Database		RSB: Reservation State Block
	LSP state: The combination of "path state" maintained as Path State		RRO: Record Route Object as defined in [RFC3209]
	Block (PSB) and "reservation state" maintained as Reservation State
	Block (RSB) forms an individual LSP state on an RSVP-TE speaker
	RI-RSVP: The set of procedures defined in Section 3 of RSVP-TE		TED: Traffic Engineering Database
	Scaling Techniques [RFC8370] to eliminate RSVP's reliance on periodic
	message refreshes
	B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object		LSP state: The combination of "path state" maintained as a PSB and
	defined in Summary FRR extensions [RFC8796] and is added by the PLR		"reservation state" maintained as an RSB forms an individual LSP
	for each protected LSP.		state on an RSVP-TE speaker
	RI-RSVP-FRR: The set of procedures defined in this document to		RI-RSVP: The set of procedures defined in Section 3 of [RFC8370] to
	eliminate RSVP's reliance of periodic message refreshes when		eliminate RSVP's reliance on periodic message refreshes
	supporting facility backup protection [RFC4090]
	Conditional PathTear: A PathTear message containing a suggestion to a		B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object
	receiving downstream router to retain the path state if the receiving		as defined in [RFC8796] and added by the PLR for each protected
	router is an NP-MP		LSP
	Remote PathTear: A PathTear message sent from a Point of Local Repair		RI-RSVP-FRR: The set of procedures defined in this document to
	(PLR) to the MP to delete the LSP state on the MP if PLR had not		eliminate RSVP's reliance on periodic message refreshes when
	previously sent the backup Path state reliably		supporting facility backup protection [RFC4090]
			Conditional PathTear: A PathTear message containing a suggestion to
			a receiving downstream router to retain the path state if the
			receiving router is an NP-MP
			Remote PathTear: A PathTear message sent from a PLR to the MP to
			delete the LSP state on the MP if the PLR had not previously sent
			the backup path state reliably
			2.1. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. Problem Description		3. Problem Description
	E		E
	/ \		/ \
	/ \		/ \
	/ \		/ \
	/ \		/ \
	/ \		/ \
	/ \		/ \
	skipping to change at page 6, line 42 ¶		skipping to change at line 273 ¶
	\ /		\ /
	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, consider a large number of LSPs from A
	to D transiting B and C. Assume that refresh interval has been		to D transiting B and C. Assume that refresh interval has been
	configured to be long of the order of minutes and refresh reduction		configured to be long of the order of minutes and refresh reduction
	extensions are enabled on all routers.		extensions are enabled on all routers.
	Also assume that node protection has been configured for the LSPs and		In addition, 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 PLR and C is the NP-MP		A is the PLR and C is the 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 LP-MP		-> D; C is the PLR and D is the LP-MP.
	In the above condition, assume that B-C link fails. The following is		In the above condition, assume that the B-C link fails. The
	the sequence of events that is expected to occur for all protected		following is the sequence of events that is expected to occur for all
	LSPs under normal conditions.		protected LSPs under normal conditions.
	1. B performs local repair and re-directs LSP traffic over the		Step 1. B performs a local repair and redirects LSP traffic over the
	bypass LSP B -> F -> D.		bypass LSP B -> F -> D.
	2. B also creates backup state for the LSP and triggers sending of		Step 2. B also creates a backup state for the LSP and triggers the
	backup LSP state to D over the bypass LSP B -> F -> D.		sending of a backup LSP state to D over the bypass LSP B ->
			F -> D.
	3. D receives backup LSP states and merges the backups with the		Step 3. D receives the backup LSP states and merges the backups with
	protected LSPs.		the protected LSPs.
	4. As the link on C, over which the LSP states are refreshed, has		Step 4. As the link on C, over which the LSP states are refreshed,
	failed, C will no longer receive state refreshes. Consequently,		has failed, C will no longer receive state refreshes.
	the protected LSP states on C will time out and C will send the		Consequently, the protected LSP states on C will time out
	tear down messages for all LSPs. As each router should consider		and C will send the teardown messages for all LSPs. As each
	itself as an MP, C will time out the state only after waiting for		router should consider itself as an MP, C will time out the
	an additional duration equal to refresh timeout.		state only after waiting for an additional duration equal to
			the 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 a PathTear from C prior		for the backup LSP, then D would receive a PathTear from C prior
	to receiving signaling for the backup LSP, thus resulting in		to receiving signaling for the backup LSP, thus resulting in
	deleting the LSP state. This would be possible at scale even with		deleting the LSP state. This would be possible at scale even with
	default refresh time.		the default refresh time.
	- If upon the link failure C is to keep state until its timeout,		* If C is to keep state until its timeout upon the link failure,
	then with long refresh interval this may result in a large amount		then with a long refresh interval, this may result in a large
	of stale state on C. Alternatively, if upon the link failure C is		amount of stale state on C. Alternatively, if C is to delete the
	to delete the state and send a PathTear to D, this would result in		state and send a PathTear to D upon the link failure, then this
	deleting the state on D, thus deleting the LSP. D needs a		would result in deleting the state on D, thus deleting the LSP. D
	reliable mechanism to determine whether it is an MP or not to		needs a reliable mechanism to determine whether or not it is an MP
	overcome this problem.		to 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 the LSP after Step 1 but
	step 2 of the above sequence, then B may receive the tear down		before Step 2 of the above sequence, then B may receive the
	message before step 2 and delete the LSP state from its state		teardown message before Step 2 and delete the LSP state from its
	database. If B deletes its state without informing D, with long		state database. If B deletes its state without informing D, with
	refresh interval this could cause (large) buildup of stale state		a long refresh interval, this could cause a (large) buildup of
	on D.		stale state on D.
	- If B fails to perform local repair in step 1, then B will delete		* If B fails to perform a local repair in Step 1, then B will delete
	the LSP state from its state database without informing D. As B		the LSP state from its state database without informing D. As B
	deletes its state without informing D, with long refresh interval		deletes its state without informing D, with a long refresh
	this could cause (large) buildup of stale state on D.		interval, this could cause a (large) buildup of stale state on D.
	The purpose of this document is to provide solutions to the above		The purpose of this document is to provide solutions to the above
	problems which will then make it practical to scale up to a large		problems, which will then make it practical to scale up to a large
	number of protected LSPs in the network.		number of protected LSPs in the network.
	4. Solution Aspects		4. Solution Aspects
	The solution consists of five parts.		The solution consists of five parts:
	- Utilize MP determination mechanism specified in RSVP-TE Summary		1. Utilize the MP determination mechanism specified in RSVP-TE
	FRR [RFC8796] that enables the PLR to signal the availability of		Summary FRR [RFC8796] that enables the PLR to signal the
	local protection to the MP. In addition, introduce PLR and MP		availability of local protection to the MP. In addition,
	procedures to establish Node-ID based hello session between the		introduce PLR and MP procedures to establish Node-ID-based Hello
	PLR and the MP to detect router failures and to determine		sessions between the PLR and the MP to detect router failures and
	capability. See Section 4.2 of this document for more details.		to determine capability. See Section 4.2 of this document for
	This part of the solution re-uses some of the extensions defined		more details. This part of the solution reuses some of the
	in RSVP-TE Summary FRR [RFC8796] and RSVP-TE Scaling Techniques		extensions defined in [RFC8796] and [RFC8370], and the subsequent
	[RFC8370], and the subsequent sub-sections will list the		subsections will list the extensions in these documents that are
	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		2. Handle upstream link or node failures by cleaning up LSP states
	the node has not found itself as an MP through the MP		if the node has not found itself as an MP through the MP
	determination mechanism. See Section 4.3 of this document for		determination mechanism. See Section 4.3 of this document for
	more details.		more details.
	- Introduce extensions to enable a router to send a tear down		3. Introduce extensions to enable a router to send a teardown
	message to the downstream router that enables the receiving router		message to the downstream router that enables the receiving
	to conditionally delete its local LSP state. See Section 4.4 of		router to conditionally delete its local LSP state. See
	this document for more details.		Section 4.4 of this document for more details.
	- Enhance facility backup protection by allowing a PLR to directly		4. Enhance facility backup protection by allowing a PLR to directly
	send a tear down message to the MP without requiring the PLR to		send a teardown message to the MP without requiring the PLR to
	either have a working bypass LSP or have already signaled backup		either have a working bypass LSP or have already signaled the
	LSP state. See Section 4.5 of this document for more details.		backup LSP state. See Section 4.5 of this document for more
			details.
	- Introduce extensions to enable the above procedures to be backward		5. Introduce extensions to enable the above procedures to be
	compatible with routers along the LSP path running implementation		backward compatible with routers along the LSP path running
	that do not support these procedures. See Section 4.6 of this		implementations that do not support these procedures. See
	document for more details.		Section 4.6 of this document for more details.
	4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP		4.1. Requirement on RFC 4090 Capable Node to Advertise the RI-RSVP
	Capability		Capability
	A node supporting facility backup protection [RFC4090] MUST NOT set		A node supporting facility backup protection [RFC4090] MUST NOT set
	the RI-RSVP flag (I bit) that is defined in Section 3.1 of RSVP-TE		the RI-RSVP flag (I-bit) that is defined in Section 3.1 of [RFC8370]
	Scaling Techniques [RFC8370] unless it supports all the extensions		unless it supports all the extensions specified in the rest of this
	specified in the rest of this document. Hence, this document updates		document. Hence, this document updates [RFC4090] by defining
	[RFC4090] by defining extensions and additional procedures over		extensions and additional procedures over facility backup protection
	facility backup protection [RFC4090] in order to advertise RI-RSVP		[RFC4090] in order to advertise the RI-RSVP capability [RFC8370].
	capability [RFC8370]. However, if a node supporting facility backup		However, if a node supporting facility backup protection [RFC4090]
	protection [RFC4090] does set the RI-RSVP capability (I bit) but does		does set the RI-RSVP capability (I-bit) but does not support all the
	not support all the extensions specified in the rest of this		extensions specified in the rest of this document, then it may result
	document, then it may result in lingering stale states due to the		in lingering stale states due to the long refresh intervals
	long refresh intervals recommended by [RFC8370]. This can also		recommended by [RFC8370]. This can also disrupt normal Fast Reroute
	disrupt normal Fast Reroute (FRR) operation. Section 4.7 of this		(FRR) operations. Section 4.7 of this document delves into this in
	document delves on this in detail.		detail.
	4.2. Signaling Handshake between PLR and MP		4.2. Signaling Handshake Between PLR and MP
	4.2.1. PLR Behavior		4.2.1. PLR Behavior
	As per the facility backup procedures [RFC4090], when an LSP becomes		As per the facility backup procedures [RFC4090], when an LSP becomes
	operational on a node and the "local protection desired" flag has		operational on a node and the "local protection desired" flag has
	been set in the SESSION_ATTRIBUTE object carried in the Path message		been set in the SESSION_ATTRIBUTE object carried in the Path message
	corresponding to the LSP, then the node attempts to make local		corresponding to the LSP, then the node attempts to make local
	protection available for the LSP.		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 an NP-bypass LSP to the
	NNhop node avoiding the Nhop node on protected LSP path. In case		NNhop node avoiding the Nhop node on a protected LSP path. In
	node protection could not be made available, the node attempts to		case node protection could not be made available, the node
	create an LP-bypass LSP to the Nhop node avoiding only the link		attempts to create an LP-bypass LSP to the Nhop node avoiding only
	that the protected LSP takes to reach the Nhop		the link that the protected LSP takes to reach the Nhop.
	- If the "node protection desired" flag is not set, then the PLR		* If the "node protection desired" flag is not set, then the PLR
	attempts to create an LP-bypass LSP to the Nhop node avoiding the		attempts to create an LP-bypass LSP to the Nhop node avoiding the
	link that the protected LSP takes to reach the Nhop		link that the protected LSP takes to reach the Nhop.
	With regard to the PLR procedures described above and that are		With regard to the PLR procedures described above and specified in
	specified in [RFC4090], this document specifies the following		[RFC4090], this document specifies the following additional
	additional procedures to support RI-RSVP [RFC8370].		procedures to support RI-RSVP [RFC8370].
	- While selecting the destination address of the bypass LSP, the PLR		* While selecting the destination address of the bypass LSP, the PLR
	MUST select the router ID of the NNhop or Nhop node from the Node-		MUST select the router ID of the NNhop or Nhop node from the Node-
	ID sub-object included in the RRO object carried in the most		ID sub-object included in the RRO object that is carried in the
	recent Resv message corresponding to the LSP. If the MP has not		most recent Resv message corresponding to the LSP. If the MP has
	included a Node-ID sub-object in the Resv RRO and if the PLR and		not included a Node-ID sub-object in the Resv RRO and if the PLR
	the MP are in the same area, then the PLR may utilize the TED to		and the MP are in the same area, then the PLR may utilize the TED
	determine the router ID corresponding to the interface address		to determine the router ID corresponding to the interface address
	included by the MP in the RRO object. If the NP-MP in a different		that is included by the MP in the RRO object. If the NP-MP in a
	IGP area has not included a Node-ID sub-object in RRO object, then		different IGP area has not included a Node-ID sub-object in the
	the PLR MUST execute backward compatibility procedures as if the		RRO object, then the PLR MUST execute backward compatibility
	downstream nodes along the LSP do not support the extensions		procedures as if the downstream nodes along the LSP do not support
	defined in the document (see Section 4.6.2.1).		the extensions defined in the document (see Section 4.6.2.1).
	- The PLR MUST also include its router ID in a Node-ID sub-object in		* The PLR MUST also include its router ID in a Node-ID sub-object in
	RRO object carried in any subsequent Path message corresponding to		the RRO object that is carried in any subsequent Path message
	the LSP. While including its router ID in the Node-ID sub-object		corresponding to the LSP. While including its router ID in the
	carried in the outgoing Path message, the PLR MUST include the		Node-ID sub-object carried in the outgoing Path message, the PLR
	Node-ID sub-object after including its IPv4/IPv6 address or		MUST include the Node-ID sub-object after including its IPv4/IPv6
	unnumbered interface ID sub-object.		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 an NP-bypass or an LP-
	the PLR MUST initiate a Node-ID based Hello session to the NNhop		bypass, the PLR MUST initiate a Node-ID-based Hello session to the
	or Nhop node respectively along the LSP to establish the RSVP-TE		NNhop or Nhop node respectively along the LSP to establish the
	signaling adjacency. This Hello session is used to detect MP node		RSVP-TE signaling adjacency. This Hello session is used to detect
	failure as well as determine the capability of the MP node. If		MP node failure as well as to determine the capability of the MP
	the MP has set the I-bit in the CAPABILITY object [RFC8370]		node. If the MP has set the I-bit in the CAPABILITY object
	carried in Hello message corresponding to the Node-ID based Hello		[RFC8370] carried in the Hello message corresponding to the Node-
	session, then the PLR MUST conclude that the MP supports refresh-		ID-based Hello session, then the PLR MUST conclude that the MP
	interval independent FRR procedures defined in this document. If		supports refresh-interval independent FRR procedures defined in
	the MP has not sent Node-ID based Hello messages or has not set		this document. If the MP has not sent Node-ID-based Hello
	the I-bit in CAPABILITY object [RFC8370], then the PLR MUST		messages or has not set the I-bit in the CAPABILITY object
	execute backward compatibility procedures defined in		[RFC8370], then the PLR MUST execute backward compatibility
	Section 4.6.2.1 of this document.		procedures defined in Section 4.6.2.1 of this document.
	- When the PLR associates a bypass to a protected LSP, it MUST		* When the PLR associates a bypass to a protected LSP, it MUST
	include a B-SFRR-Ready Extended Association object [RFC8796] and		include a B-SFRR-Ready Extended Association object [RFC8796] and
	trigger a Path message to be sent for the LSP. If a B-SFRR-Ready		trigger a Path message to be sent for the LSP. If a B-SFRR-Ready
	Extended Association object is included in the Path message		Extended Association object is included in the Path message
	corresponding to the LSP, the encoding and object ordering rules		corresponding to the LSP, the encoding and object ordering rules
	specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. In		specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. In
	addition to those rules, the PLR MUST set the Association Source		addition to those rules, the PLR MUST set the Association Source
	in the object to its Node-ID address.		in the object to its Node-ID address.
	4.2.2. Remote Signaling Adjacency		4.2.2. Remote Signaling Adjacency
	A Node-ID based RSVP-TE Hello session is one in which Node-ID is used		A Node-ID-based RSVP-TE Hello session is one in which a Node-ID is
	in the source and the destination address fields of RSVP Hello		used 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		sessions 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 sessions between any two routers that are
	not immediate neighbors, the router that supports the extensions		not immediate neighbors, the router that supports the extensions
	defined in the document MUST set TTL to 255 in all outgoing Node-ID		defined in the document MUST set the TTL to 255 in all outgoing Node-
	based Hello messages exchanged between the PLR and the MP. The		ID-based Hello messages exchanged between the PLR and the MP. The
	default hello interval for this Node-ID hello session MUST be set to		default hello interval for this Node-ID Hello session MUST be set to
	the default specified in RSVP-TE Scaling Techniques [RFC8370].		the default specified in RSVP-TE Scaling Techniques [RFC8370].
	In the rest of the document the term "signaling adjacency", or		In the rest of the document, the terms "signaling adjacency" and
	"remote signaling adjacency" refers specifically to the RSVP-TE		"remote signaling adjacency" refer specifically to the RSVP-TE
	signaling adjacency.		signaling adjacency.
	4.2.3. MP Behavior		4.2.3. MP Behavior
	With regard to the MP procedures that are defined in [RFC4090] this		With regard to the MP procedures that are defined in [RFC4090], this
	document specifies the following additional procedures to support RI-		document specifies the following additional procedures to support RI-
	RSVP defined in [RFC8370].		RSVP as defined in [RFC8370].
	Each node along an LSP path supporting the extensions defined in this		Each node along an LSP path supporting the extensions defined in this
	document MUST also include its router ID in the Node-ID sub-object of		document MUST also include its router ID in the Node-ID sub-object of
	the RRO object carried in the Resv message of the corresponding LSP.		the RRO object that is carried in the Resv message of the
	If the PLR has not included a Node-ID sub-object in the RRO object		corresponding LSP. If the PLR has not included a Node-ID sub-object
	carried in the Path message and if the PLR is in a different IGP		in the RRO object that is carried in the Path message and if the PLR
	area, then the router MUST NOT execute the MP procedures specified in		is in a different IGP area, then the router MUST NOT execute the MP
	this document for those LSPs. Instead, the node MUST execute		procedures specified in this document for those LSPs. Instead, the
	backward compatibility procedures defined in Section 4.6.2.2 of this		node MUST execute backward compatibility procedures defined in
	document as if the upstream nodes along the LSP do not support the		Section 4.6.2.2 of this document as if the upstream nodes along the
	extensions defined in this document.		LSP do not support the extensions defined in this document.
	A node receiving a Path message should determine whether the message		A node receiving a Path message should determine:
	contains a B-SFRR-Ready Extended Association object with its own
	address as the bypass destination address and whether it has an
	operational Node-ID signaling adjacency with the Association source.
	If the PLR has not included the B-SFRR-Ready Extended Association
	object or if there is no operational Node-ID signaling adjacency with
	the PLR identified by the Association source address or if the PLR
	has not advertised RI-RSVP capability in its Node-ID based Hello
	messages, then the node MUST execute the backward compatibility
	procedures defined in Section 4.6.2.2 of this document.
	If a matching B-SFRR-Ready Extended Association object is found in in		* whether the message contains a B-SFRR-Ready Extended Association
			object with its own address as the bypass destination address and
			* whether it has an operational Node-ID signaling adjacency with the
			Association source.
			The node MUST execute the backward compatibility procedures defined
			in Section 4.6.2.2 of this document if:
			* the PLR has not included the B-SFRR-Ready Extended Association
			object,
			* there is no operational Node-ID signaling adjacency with the PLR
			identified by the Association source address, or
			* the PLR has not advertised the RI-RSVP capability in its Node-ID-
			based Hello messages.
			If a matching B-SFRR-Ready Extended Association object is found in
	the Path message and if there is an operational remote Node-ID		the Path message and if there is an operational remote Node-ID
	signaling adjacency with the PLR (identified by the Association		signaling adjacency with the PLR (identified by the Association
	source) that has advertised RI-RSVP capability (I-bit) [RFC8370],		source) that has advertised the RI-RSVP capability (I-bit) [RFC8370],
	then the node MUST consider itself as the MP for the PLR. The		then the node MUST consider itself as the MP for the PLR. The
	matching and ordering rules for Bypass Summary FRR Extended		matching and ordering rules for Bypass Summary FRR Extended
	Association specified in RSVP-TE Summary FRR [RFC8796] MUST be		Association specified in RSVP-TE Summary FRR [RFC8796] MUST be
	followed by the implementations supporting this document.		followed by the implementations supporting this document.
	- If a matching Bypass Summary FRR Extended Association object is		* If a matching Bypass Summary FRR Extended Association object is
	included by the PPhop node of an LSP and if a corresponding Node-		included by the PPhop node of an LSP and if a corresponding Node-
	ID signaling adjacency exists with the PPhop node, then the router		ID signaling adjacency exists with the PPhop node, then the router
	MUST conclude it is the NP-MP.		MUST conclude it is the NP-MP.
	- If a matching Bypass Summary FRR Extended Association object is		* If a matching Bypass Summary FRR Extended Association object is
	included by the Phop node of an LSP and if a corresponding Node-ID		included by the Phop node of an LSP and if a corresponding Node-ID
	signaling adjacency exists with the Phop node, then the router		signaling adjacency exists with the Phop node, then the router
	MUST conclude it is the LP-MP.		MUST conclude it is the LP-MP.
	4.2.4. "Remote" State on MP		4.2.4. "Remote" State on MP
	Once a router concludes it is the MP for a PLR running refresh-		Once a router concludes it is the MP for a PLR running refresh-
	interval independent FRR procedures as described in the preceding		interval independent FRR procedures as described in the preceding
	section, it MUST create a remote path state for the LSP. The only		section, it MUST create a remote path state for the LSP. The only
	difference between the "remote" path state and the LSP state is the		difference between the "remote" path state and the LSP state is the
	RSVP_HOP object. The RSVP_HOP object in a "remote" path state		RSVP_HOP object. The RSVP_HOP object in a "remote" path state
	contains the address that the PLR uses to send Node-ID hello messages		contains the address that the PLR uses to send Node-ID Hello messages
	to the MP.		to the MP.
	The MP MUST consider the "remote" path state corresponding to the LSP		The MP MUST consider the "remote" path state corresponding to the LSP
	automatically deleted if:		automatically deleted if:
	- The MP later receives a Path message for the LSP with no matching		* the MP later receives a Path message for the LSP with no matching
	B-SFRR-Ready Extended Association object corresponding to the		B-SFRR-Ready Extended Association object corresponding to the
	PLR's IP address contained in the Path RRO, or		PLR's IP address contained in the Path RRO,
	- The Node-ID signaling adjacency with the PLR goes down, or		* the Node-ID signaling adjacency with the PLR goes down,
	- The MP receives backup LSP signaling for the LSP from the PLR or		* the MP receives backup LSP signaling for the LSP from the PLR,
	- The MP receives a PathTear for the LSP, or		* the MP receives a PathTear for the LSP, or
	- The MP deletes the LSP state on a local policy or an exception		* the MP deletes the LSP state on a local policy or an exception
	event		event.
	The purpose of "remote" path state is to enable the PLR to explicitly		The purpose of "remote" path state is to enable the PLR to explicitly
	tear down the path and reservation states corresponding to the LSP by		tear down the path and reservation states corresponding to the LSP by
	sending a tear message for the "remote" path state. Such a message		sending a tear message for the "remote" path state. Such a message
	tearing down "remote" path state is called "Remote" PathTear.		tearing down the "remote" path state is called "Remote" PathTear.
	The scenarios in which a "Remote" PathTear is applied are described		The scenarios in which a "Remote" PathTear is applied are described
	in Section 4.5 of this document.		in Section 4.5 of this document.
	4.3. Impact of Failures on LSP State		4.3. Impact of Failures on LSP State
	This section describes the procedures that must be executed upon		This section describes the procedures that must be executed upon
	different kinds of failures by nodes along the path of the LSP. The		different kinds of failures by nodes along the path of the LSP. The
	procedures that must be executed upon detecting RSVP signaling		procedures that must be executed upon detecting RSVP signaling
	adjacency failures do not impact the RSVP-TE graceful restart		adjacency failures do not impact the RSVP-TE graceful restart
	mechanisms ([RFC3473], [RFC5063]). If a node executing these		mechanisms [RFC3473] [RFC5063]. If a node executing these procedures
	procedures acts as a helper for a neighboring router, then the		acts as a helper for a neighboring router, then the signaling
	signaling adjacency with the neighbor will be declared as having		adjacency with the neighbor will be declared as having failed only
	failed only after taking into account the grace period extended for		after taking into account the grace period extended for the neighbor
	the neighbor by this node acting as a helper.		by this node acting as a helper.
	Node failures are detected from the state of Node-ID hello sessions		Node failures are detected from the state of Node-ID Hello sessions
	established with immediate neighbors. RSVP-TE Scaling Techniques		established with immediate neighbors. RSVP-TE Scaling Techniques
	[RFC8370] recommends that each node establish Node-ID hello sessions		[RFC8370] recommends that each node establish Node-ID Hello sessions
	with all its immediate neighbors. Non-immediate PLR or MP failure is		with all its immediate neighbors. A non-immediate PLR or MP failure
	detected from the state of remote signaling adjacency established		is detected from the state of remote signaling adjacency established
	according to Section 4.2.2 of this document.		according to Section 4.2.2 of this document.
	4.3.1. Non-MP Behavior		4.3.1. Non-MP Behavior
	When a router detects the Phop link or the Phop node failure for an		When a router detects the Phop link or the Phop node failure for an
	LSP and the router is not an MP for the LSP, then it MUST send a		LSP and the router is not an MP for the LSP, then it MUST send a
	Conditional PathTear (refer to Section 4.4 of this document) and		Conditional PathTear (refer to Section 4.4 of this document) and
	delete the PSB and RSB states corresponding to the LSP.		delete the PSB and RSB states corresponding to the LSP.
	4.3.2. LP-MP Behavior		4.3.2. LP-MP Behavior
	When the Phop link for an LSP fails on a router that is an LP-MP for		When the Phop link for an LSP fails on a router that is an LP-MP for
	the LSP, the LP-MP MUST retain the PSB and RSB states corresponding		the LSP, the LP-MP MUST retain the PSB and RSB states corresponding
	to the LSP till the occurrence of any of the following events.		to the LSP until the occurrence of any of the following events:
	- The Node-ID signaling adjacency with the Phop PLR goes down, or		* the Node-ID signaling adjacency with the Phop PLR goes down,
	- The MP receives a normal or "Remote" PathTear for its PSB, or		* the MP receives a normal or "Remote" PathTear for its PSB, or
	- The MP receives a ResvTear for its RSB.		* the MP receives a ResvTear for its RSB.
	When a router that is an LP-MP for an LSP detects Phop node failure		When a router that is an LP-MP for an LSP detects Phop node failure
	from the Node-ID signaling adjacency state, the LP-MP MUST send a		from the Node-ID signaling adjacency state, the LP-MP MUST send a
	normal PathTear and delete the PSB and RSB states corresponding to		normal PathTear and delete the PSB and RSB states corresponding to
	the LSP.		the LSP.
	4.3.3. NP-MP Behavior		4.3.3. NP-MP Behavior
	When a router that is an NP-MP for an LSP detects Phop link failure,		When a router that is an NP-MP for an LSP detects Phop link failure
	or Phop node failure from the Node-ID signaling adjacency, the router		or Phop node failure from the Node-ID signaling adjacency, the router
	MUST retain the PSB and RSB states corresponding to the LSP till the		MUST retain the PSB and RSB states corresponding to the LSP until the
	occurrence of any of the following events.		occurrence of any of the following events:
	- The remote Node-ID signaling adjacency with the PPhop PLR goes		* the remote Node-ID signaling adjacency with the PPhop PLR goes
	down, or		down,
	- The MP receives a normal or "Remote" PathTear for its PSB, or		* the MP receives a normal or "Remote" PathTear for its PSB, or
	- The MP receives a ResvTear for its RSB.		* the MP receives a ResvTear for its RSB.
	When a router that is an NP-MP for an LSP did not detect the Phop		When a router that is an NP-MP for an LSP does not detect the Phop
	link or the Phop node failure, but receives a Conditional PathTear		link or the Phop node failure but receives a Conditional PathTear
	from the Phop node, then the router MUST retain the PSB and RSB		from the Phop node, then the router MUST retain the PSB and RSB
	states corresponding to the LSP till the occurrence of any of the		states corresponding to the LSP until the occurrence of any of the
	following events.		following events:
	- The remote Node-ID signaling adjacency with the PPhop PLR goes		* the remote Node-ID signaling adjacency with the PPhop PLR goes
	down, or		down,
	- The MP receives a normal or "Remote" PathTear for its PSB, or		* the MP receives a normal or "Remote" PathTear for its PSB, or
	- The MP receives a ResvTear for its RSB.		* the MP receives a ResvTear for its RSB.
	Receiving a Conditional PathTear from the Phop node will not impact		Receiving a Conditional PathTear from the Phop node will not impact
	the "remote" state from the PPhop PLR. Note that the Phop node must		the "remote" state from the PPhop PLR. Note that the Phop node must
	have sent the Conditional PathTear as it was not an MP for the LSP		have sent the Conditional PathTear as it was not an MP for the LSP
	(see Section 4.3.1 of this document).		(see Section 4.3.1 of this document).
	In the example topology Figure 1, we assume C & D are the NP-MPs for		In the example topology in Figure 1, we assume C and D are the NP-MPs
	the PLRs A & B respectively. Now when A-B link fails, as B is not an		for the PLRs A and B, respectively. Now, when the A-B link fails, B
	MP and its Phop link has failed, B will delete the LSP state (this		will delete the LSP state, because B is not an MP and its Phop link
	behavior is required for unprotected LSPs - refer to Section 4.3.1 of		has failed (this behavior is required for unprotected LSPs; refer to
	this document). In the data plane, that would require B to delete		Section 4.3.1 of this document). In the data plane, that would
	the label forwarding entry corresponding to the LSP. So if B's		require B to delete the label forwarding entry corresponding to the
	downstream nodes C and D continue to retain state, it would not be		LSP. Thus, if B's downstream nodes C and D continue to retain state,
	correct for D to continue to assume itself as the NP-MP for the PLR		it would not be correct for D to continue to assume itself as the NP-
	B.		MP for the PLR B.
	The mechanism that enables D to stop considering itself as the NP-MP		The mechanism that enables D to stop considering itself as the NP-MP
	for B and delete the corresponding "remote" path state is given		for B and delete the corresponding "remote" path state is given
	below.		below.
	1. When C receives a Conditional PathTear from B, it decides to		1. When C receives a Conditional PathTear from B, it decides to
	retain LSP state as it is the NP-MP of the PLR A. It also checks		retain the LSP state as it is the NP-MP of the PLR A. It also
	whether Phop B had previously signaled availability of node		checks whether Phop B had previously signaled availability of
	protection. As B had previously signaled NP availability by		node protection. As B had previously signaled NP availability by
	including B-SFRR-Ready Extended Association object, C removes the		including the B-SFRR-Ready Extended Association object, C removes
	B-SFRR-Ready Extended Association object containing Association		the B-SFRR-Ready Extended Association object containing the
	Source set to B from the Path message and trigger a Path to D.		Association Source set to B from the Path message and triggers a
			Path to D.
	2. When D receives the Path message, it realizes that it is no		2. When D receives the Path message, it realizes that it is no
	longer the NP-MP for B and so it deletes the corresponding		longer the NP-MP for B and so it deletes the corresponding
	"remote" path state. D does not propagate the Path further down		"remote" path state. D does not propagate the Path further down
	because the only change is that the B-SFRR-Ready Extended		because the only change is that the B-SFRR-Ready Extended
	Association object corresponding to Association Source B is no		Association object corresponding to Association Source B is no
	longer present in the Path message.		longer present in the 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 the LP-MP and NP-MP
	A router may simultaneously be the LP-MP as well as the NP-MP for the		A router may simultaneously be the LP-MP and the NP-MP for the Phop
	Phop and the PPhop nodes respectively of an LSP. If the Phop link		and PPhop nodes of an LSP, respectively. If the Phop link fails on
	fails on such a node, the node MUST retain the PSB and RSB states		such a node, the node MUST retain the PSB and RSB states
	corresponding to the LSP till the occurrence of any of the following		corresponding to the LSP until the occurrence of any of the following
	events.		events:
	- Both Node-ID signaling adjacencies with Phop and PPhop nodes go		* both Node-ID signaling adjacencies with Phop and PPhop nodes go
	down, or		down,
	- The MP receives a normal or "Remote" PathTear for its PSB, or		* the MP receives a normal or "Remote" PathTear for its PSB, or
	- The MP receives a ResvTear for its RSB.		* the MP receives a ResvTear for its RSB.
	If a router that is both an LP-MP and an NP-MP detects Phop node		If a router that is both an LP-MP and an NP-MP detects Phop node
	failure, then the node MUST retain the PSB and RSB states		failure, then the node MUST retain the PSB and RSB states
	corresponding to the LSP till the occurrence of any of the following		corresponding to the LSP until the occurrence of any of the following
	events.		events:
	- The remote Node-ID signaling adjacency with the PPhop PLR goes		* the remote Node-ID signaling adjacency with the PPhop PLR goes
	down, or		down,
	- The MP receives a normal or "Remote" PathTear for its PSB, or		* the MP receives a normal or "Remote" PathTear for its PSB, or
	- The MP receives a ResvTear for its RSB.		* the MP receives a ResvTear for its RSB.
	4.4. Conditional PathTear		4.4. Conditional PathTear
	In the example provided in Section 4.3.3 of this document, B deletes		In the example provided in Section 4.3.3 of this document, B deletes
	the PSB and RSB states corresponding to the LSP once B detects its		the PSB and RSB states corresponding to the LSP once B detects its
	Phop link went down as B is not an MP. If B were to send a PathTear		Phop link that went down as B is not an MP. If B were to send a
	normally, then C would delete LSP state immediately. In order to		PathTear normally, then C would delete the LSP state immediately. In
	avoid this, there should be some mechanism by which B can indicate to		order to avoid this, there should be some mechanism by which B can
	C that B does not require the receiving node to unconditionally		indicate to C that B does not require the receiving node to
	delete the LSP state immediately. For this, B MUST add a new		unconditionally delete the LSP state immediately. For this, B MUST
	optional CONDITIONS object in the PathTear. The CONDITIONS object is		add a new optional CONDITIONS object in the PathTear. The CONDITIONS
	defined in Section 4.4.3 of this document. If node C also		object is defined in Section 4.4.3 of this document. If node C also
	understands the new object, then C MUST NOT delete the LSP state if		understands the new object, then C MUST NOT delete the LSP state if
	it is an NP-MP.		it is an NP-MP.
	4.4.1. Sending Conditional PathTear		4.4.1. Sending the Conditional PathTear
	A router that is not an MP for an LSP MUST delete the PSB and RSB		A router that is not an MP for an LSP MUST delete the PSB and RSB
	states corresponding to the LSP if the Phop link or the Phop Node-ID		states corresponding to the LSP if the Phop link or the Phop Node-ID
	signaling adjacency goes down (see Section 4.3.1 of this document).		signaling adjacency goes down (see Section 4.3.1 of this document).
	The router MUST send a Conditional PathTear if the following are also		The router MUST send a Conditional PathTear if the following are also
	true.		true:
	- The ingress has requested node protection for the LSP, and		* the ingress has requested node protection for the LSP and
	- No PathTear is received from the upstream node		* no PathTear is received from the upstream node.
	4.4.2. Processing Conditional PathTear		4.4.2. Processing the Conditional PathTear
	When a router that is not an NP-MP receives a Conditional PathTear,		When a router that is not an NP-MP receives a Conditional PathTear,
	the node MUST delete the PSB and RSB states corresponding to the LSP,		the node MUST delete the PSB and RSB states corresponding to the LSP
	and process the Conditional PathTear by considering it as a normal		and process the Conditional PathTear by considering it as a normal
	PathTear. Specifically, the node MUST NOT propagate the Conditional		PathTear. Specifically, the node MUST NOT propagate the Conditional
	PathTear downstream but remove the optional object and send a normal		PathTear downstream but remove the optional object and send a normal
	PathTear downstream.		PathTear downstream.
	When a node that is an NP-MP receives a Conditional PathTear, it MUST		When a node that is an NP-MP receives a Conditional PathTear, it MUST
	NOT delete LSP state. The node MUST check whether the Phop node had		NOT delete the LSP state. The node MUST check whether the Phop node
	previously included the B-SFRR-Ready Extended Association object in		had previously included the B-SFRR-Ready Extended Association object
	the Path. If the object had been included previously by the Phop,		in the Path. If the object had been included previously by the Phop,
	then the node processing the Conditional PathTear from the Phop MUST		then the node processing the Conditional PathTear from the Phop MUST
	remove the corresponding object and trigger a Path downstream.		remove the corresponding object and trigger a Path downstream.
	If a Conditional PathTear is received from a neighbor that has not		If a Conditional PathTear is received from a neighbor that has not
	advertised support (refer to Section 4.6 of this document) for the		advertised support (refer to Section 4.6 of this document) for the
	new procedures defined in this document, then the node MUST consider		new procedures defined in this document, then the node MUST consider
	the message as a normal PathTear. The node MUST propagate the normal		the message as a normal PathTear. The node MUST propagate the normal
	PathTear downstream and delete the LSP state.		PathTear downstream and delete the LSP state.
	4.4.3. CONDITIONS Object		4.4.3. CONDITIONS Object
	Any implementation that does not support Conditional PathTear needs		Any implementation that does not support a Conditional PathTear needs
	to ignore the new object but process the message as a normal PathTear		to ignore the new object but process the message as a normal PathTear
	without generating any error. For this reason, the Class-Num of the		without generating any error. For this reason, the Class-Num of the
	new object follows the pattern 10bbbbbb where 'b' represents a bit.		new object follows the pattern 10bbbbbb, where "b" represents a bit.
	(The behavior for objects of this type is specified in Section 3.10		(The behavior for objects of this type is specified in Section 3.10
	of [RFC2205]).		of [RFC2205].)
	The new object is called as "CONDITIONS" object that will specify the		The new object is called the "CONDITIONS" object and will specify the
	conditions under which default processing rules of the RSVP-TE		conditions under which default processing rules of the RSVP-TE
	message MUST be invoked.		message MUST be invoked.
	The object has the following format:		The object has the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class | C-type |		| Length | Class | C-type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags (Reserved) |M|		| Flags (Reserved) |M|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: CONDITIONS Object		Figure 2: CONDITIONS Object
	* Class: TBA1		Class: 135
	C-type: 1		C-type: 1
	Flags is a 32 bit field. Bit 31 is the Merge-point condition (M)		Flags: 32 bit field
	bit: If the M bit is set to 1, then the PathTear message MUST be		M: Bit 31 is the Merge-point condition (M) bit. If the M bit is set
	processed according to the receiver router role, i.e. if the		to 1, then the PathTear message MUST be processed according to the
	receiving router is an MP or not for the LSP. If it is not set,		receiver router role, i.e., if the receiving router is an MP or
	then the PathTear message MUST be processed as a normal PathTear		not for the LSP. If it is not set, then the PathTear message MUST
	message for the LSP.		be processed as a normal PathTear message for the LSP.
	Bits 0-30 are reserved, they MUST be set to zero on transmission
	and MUST be ignored on receipt.		Bits 0-30 are reserved; they MUST be set to zero on transmission and
			MUST be ignored on receipt.
	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 until the completion of backup LSP
	signaling to perform state cleanup. In this case, the PLR MUST send		signaling to perform state cleanup. In this case, the PLR MUST send
	a "Remote" PathTear message instructing the MP to delete the PSB and		a "Remote" PathTear message instructing the MP to delete the PSB and
	RSB states corresponding to the LSP. The TTL in the "Remote"		RSB states corresponding to the LSP. The TTL in the "Remote"
	PathTear message MUST be set to 255. Doing this enables LSP state		PathTear message MUST be set to 255. Doing this enables LSP state
	cleanup when the LSP is being locally repaired.		cleanup when the LSP is being locally repaired.
	Consider that node C in the example topology (Figure 1) has gone down		Consider that node C in the example topology (Figure 1) has gone down
	and node B locally repairs the LSP.		and node B locally repairs the LSP:
	1. Ingress A receives a management event to tear down the LSP.		1. Ingress A receives a management event to tear down the LSP.
	2. A sends a normal PathTear for the LSP to B.		2. A sends a normal PathTear for the LSP to B.
	3. Assume B has not initiated the backup signaling for the LSP		3. Assume B has not initiated the backup signaling for the LSP
	during local repair. To enable LSP state cleanup, B sends a		during local repair. To enable LSP state cleanup, B sends a
	"Remote" PathTear with destination IP address set to that of the		"Remote" PathTear with the destination IP address set to that of
	node D used in the Node-ID signaling adjacency with D, and the		the node D used in the Node-ID signaling adjacency with D and the
	RSVP_HOP object containing local address used in the Node-ID		RSVP_HOP object containing the local address used in the Node-ID
	signaling adjacency.		signaling adjacency.
	4. B then deletes the PSB and RSB states corresponding to the LSP.		4. B then deletes the PSB and RSB states corresponding to the LSP.
	5. On D there would be a remote signaling adjacency with B and so D		5. On D, there would be a remote signaling adjacency with B, and so
	accepts the "Remote" PathTear and delete the PSB and RSB states		D accepts the "Remote" PathTear and deletes 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, the PLR MUST send a		If local repair fails on the PLR after a failure, the PLR MUST send a
	"Remote" PathTear to the MP. The purpose of this is to clean up LSP		"Remote" PathTear to the MP. The purpose of this is to clean up LSP
	state from the PLR to the Egress. Upon receiving the PathTear, the		state from the PLR to the egress. Upon receiving the PathTear, the
	MP MUST delete the states corresponding to the LSP and also propagate		MP MUST delete the states corresponding to the LSP and also propagate
	the PathTear downstream thereby achieving state cleanup from all		the PathTear downstream, thereby achieving state cleanup from all
	downstream nodes up to the LSP egress. Note that in the case of link		downstream nodes up to the LSP egress. Note that in the case of link
	protection, the PathTear MUST be directed to the LP-MP's Node-ID IP		protection, the PathTear MUST be directed to the LP-MP's Node-ID IP
	address rather than the Nhop interface address.		address rather than the Nhop interface address.
	4.5.2. PLR Behavior on Resv RRO Change		4.5.2. PLR Behavior on Resv RRO Change
	When a PLR router that has already made NP available for an LSP		When a PLR router that has already made NP available for an LSP
	detects a change in the RRO carried in the Resv message that		detects a change in the RRO carried in the Resv message that
	indicates that the router's former NP-MP is no longer present on the		indicates that the router's former NP-MP is no longer present on the
	path of the LSP, then the router MUST send a "Remote" PathTear		path of the LSP, then the router MUST send a "Remote" PathTear
	directly to its former NP-MP.		directly to its former NP-MP.
	In the example topology Figure 1, assume node A has made node		In the example topology in Figure 1, assume node A has made node
	protection available for an LSP and C has concluded it is the NP-MP		protection available for an LSP and C has concluded it is the NP-MP
	for PLR A. When the B-C link fails then C, implementing the		for PLR A. When the B-C link fails, then C, implementing the
	procedure specified in Section 4.3.4 of this document, will retain		procedure specified in Section 4.3.4 of this document, will retain
	the states corresponding to the LSP until: the remote Node-ID		the states corresponding to the LSP until one of the following
	signaling adjacency with A goes down, or a PathTear or a ResvTear is		occurs:
	received for its PSB or RSB respectively. If B also has made node
	protection available, B will eventually complete backup LSP signaling
	with its NP-MP D and trigger a Resv to A with RRO changed. The new
	RRO of the LSP carried in the Resv will not contain C. When A
	processes the Resv message with a new RRO not containing C - its
	former NP-MP, A sends a "Remote" PathTear to C. When C receives the
	"Remote" PathTear for its PSB state, C will send a normal PathTear
	downstream to D and delete both the PSB and RSB states corresponding
	to the LSP. As D has already received backup LSP signaling from B, D
	will retain control plane and forwarding states corresponding to the
	LSP.
	4.5.3. LSP Preemption during Local Repair		* the remote Node-ID signaling adjacency with A goes down or
	4.5.3.1. Preemption on LP-MP after Phop Link Failure
			* a PathTear or a ResvTear is received for its PSB or RSB,
			respectively.
			If B also has made node protection available, B will eventually
			complete backup LSP signaling with its NP-MP D and trigger a Resv to
			A with RRO changed. The new RRO of the LSP carried in the Resv will
			not contain C. When A processes the Resv message with a new RRO not
			containing C, its former NP-MP, A, sends a "Remote" PathTear to C.
			When C receives the "Remote" PathTear for its PSB state, C will send
			a normal PathTear downstream to D and delete both the PSB and RSB
			states corresponding to the LSP. As D has already received backup
			LSP signaling from B, D will retain the control plane and forwarding
			states corresponding to the LSP.
			4.5.3. LSP Preemption During Local Repair
			4.5.3.1. Preemption on LP-MP After Phop Link Failure
	If an LSP is preempted on an LP-MP after its Phop link has already		If an LSP is preempted on an LP-MP after its Phop link has already
	failed but the backup LSP has not been signaled yet as part of local		failed but the backup LSP has not been signaled yet as part of the
	repair procedure, then the node MUST send a normal PathTear and		local repair procedure, then the node MUST send a normal PathTear and
	delete both the PSB and RSB states corresponding to the LSP. As the		delete both the PSB and RSB states corresponding to the LSP. As the
	LP-MP has retained the LSP state expecting the PLR to initiate backup		LP-MP has retained the LSP state expecting the PLR to initiate backup
	LSP signaling, preemption would bring down the LSP and the node would		LSP signaling, preemption would bring down the LSP and the node would
	not be LP-MP any more requiring the node to clean up the LSP state.		not be LP-MP anymore, requiring the node to clean up the LSP state.
	4.5.3.2. Preemption on NP-MP after Phop Link Failure		4.5.3.2. Preemption on NP-MP After Phop Link Failure
	If an LSP is preempted on an NP-MP after its Phop link has already		If an LSP is preempted on an NP-MP after its Phop link has already
	failed but the backup LSP has not been signaled yet, then the node		failed but the backup LSP has not been signaled yet, then the node
	MUST send a normal PathTear and delete the PSB and RSB states		MUST send a normal PathTear and delete the PSB and RSB states
	corresponding to the LSP. As the NP-MP has retained LSP state		corresponding to the LSP. As the NP-MP has retained the LSP state
	expecting the PLR to initiate backup LSP signaling, preemption would		expecting the PLR to initiate backup LSP signaling, preemption would
	bring down the LSP and the node would not be NP-MP any more requiring		bring down the LSP and the node would not be NP-MP anymore, requiring
	the node to clean up LSP state.		the node to clean up LSP state.
	Consider that B-C link goes down on the same example topology		Consider that the B-C link goes down on the same example topology
	(Figure 1). As C is the NP-MP for the PLR A, C will retain LSP		(Figure 1). As C is the NP-MP for the PLR A, C will retain the LSP
	state.		state.
	1. The LSP is preempted on C.		1. The LSP is preempted on C.
	2. C will delete the RSB state corresponding to the LSP. But C		2. C will delete the RSB state corresponding to the LSP. However, C
	cannot send a PathErr or a ResvTear to the PLR A because the		cannot send a PathErr or a ResvTear to the PLR A because the
	backup LSP has not been signaled yet.		backup LSP has not been signaled yet.
	3. As the only reason for C having retained state after Phop node		3. As the only reason for C having retained state after Phop node
	failure was that it was an NP-MP, C sends a normal PathTear to D		failure was that it was an NP-MP, C sends a normal PathTear to D
	and delete its PSB state also. D would also delete the PSB and		and also deletes its PSB state. D would also delete the PSB and
	RSB states on receiving a PathTear from C.		RSB states on receiving a PathTear from C.
	4. B starts backup LSP signaling to D. But as D does not have the		4. B starts backup LSP signaling to D. However, as D does not have
	LSP state, it will reject the backup LSP Path and send a PathErr		the LSP state, it will reject the backup LSP Path and send a
	to B.		PathErr to B.
	5. B will delete its reservation and send a ResvTear to A.		5. B will delete its reservation and send a ResvTear to A.
	4.6. Backward Compatibility Procedures		4.6. Backward Compatibility Procedures
	"Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set		"Refresh-Interval Independent FRR" and "RI-RSVP-FRR" refer to the set
	of procedures defined in this document to eliminate the reliance of		of procedures defined in this document to eliminate the reliance on
	periodic refreshes. The extensions proposed in RSVP-TE Summary FRR		periodic refreshes. The extensions proposed in RSVP-TE Summary FRR
	[RFC8796] may apply to implementations that do not support RI-RSVP-		[RFC8796] may apply to implementations that do not support RI-RSVP-
	FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state		FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state
	cleanup namely Conditional and "Remote" PathTear require support from		cleanup, namely Conditional and "Remote" PathTears, require support
	one-hop and two-hop neighboring nodes along the LSP path. So		from one-hop and two-hop neighboring nodes along the LSP path. Thus,
	procedures that fall under LSP state cleanup category MUST NOT be		procedures that fall under the LSP state cleanup category MUST NOT be
	turned on if any of the nodes involved in the node protection FRR		turned on if any of the nodes involved in the node protection FRR
	i.e. the PLR, the MP and the intermediate node in the case of NP,		(i.e., the PLR, the MP, and the intermediate node in the case of NP)
	does not support RI-RSVP-FRR extensions. Note that for LSPs		do not support RI-RSVP-FRR extensions. Note that for LSPs requesting
	requesting link protection, only the PLR and the LP-MP MUST support		link protection, only the PLR and the LP-MP MUST support the
	the extensions.		extensions.
	4.6.1. Detecting Support for Refresh interval Independent FRR		4.6.1. Detecting Support for Refresh-Interval Independent FRR
	An implementation supporting RI-RSVP-FRR extensions MUST set the flag		An implementation supporting RI-RSVP-FRR extensions MUST set the flag
	"Refresh interval Independent RSVP" or RI-RSVP flag in the CAPABILITY		"Refresh interval Independent RSVP" or RI-RSVP flag in the CAPABILITY
	object carried in Hello messages as specified in RSVP-TE Scaling		object carried in Hello messages as specified in RSVP-TE Scaling
	Techniques [RFC8370]. If an implementation does not set the flag		Techniques [RFC8370]. If an implementation does not set the flag
	even if it supports RI-RSVP-FRR extensions, then its neighbors will		even if it supports RI-RSVP-FRR extensions, then its neighbors will
	view the node as any node that does not support the extensions.		view the node as any node that does not support the extensions.
	- As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID		* As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID-
	based signaling adjacency with all immediate neighbors, such a		based signaling adjacency with all immediate neighbors, such a
	node on the path of a protected LSP can determine whether its Phop		node on the path of a protected LSP can determine whether its Phop
	and Nhop neighbors support RI-RSVP-FRR enhancements.		and Nhop neighbors support RI-RSVP-FRR enhancements.
	- As nodes supporting the RI-RSVP-FRR extensions also initiate Node-		* As nodes supporting the RI-RSVP-FRR extensions also initiate Node-
	ID based signaling adjacency with the NNhop along the path of the		ID-based signaling adjacency with the NNhop along the path of the
	LSP requested node protection (see Section 4.2.1 of this		LSP requesting node protection (see Section 4.2.1 of this
	document), each node along the LSP path can determine whether its		document), each node along the LSP path can determine whether its
	NNhop node supports RI-RSVP-FRR enhancements. If the NNhop (a)		NNhop node supports RI-RSVP-FRR enhancements. If the NNhop (a)
	does not reply to remote Node-ID Hello messages or (b) does not		does not reply to remote Node-ID Hello messages or (b) does not
	set the RI-RSVP flag in the CAPABILITY object carried in its Node-		set the RI-RSVP flag in the CAPABILITY object carried in its Node-
	ID Hello messages, then the node acting as the PLR can conclude		ID Hello messages, then the node acting as the PLR can conclude
	that NNhop does not support RI-RSVP-FRR extensions.		that NNhop does not support RI-RSVP-FRR extensions.
	- If node protection is requested for an LSP and if (a) the PPhop		* If node protection is requested for an LSP and if (a) the PPhop
	node has not included a matching B-SFRR-Ready Extended Association		node has not included a matching B-SFRR-Ready Extended Association
	object in its Path messages or (b) the PPhop node has not		object in its Path messages, (b) the PPhop node has not initiated
	initiated remote Node-ID Hello messages or (c) the PPhop node does		remote Node-ID Hello messages, or (c) the PPhop node does not set
	not set the RI-RSVP flag in the CAPABILITY object carried in its		the RI-RSVP flag in the CAPABILITY object carried in its Node-ID
	Node-ID Hello messages, then the node MUST conclude that the PLR		Hello messages, then the node MUST conclude that the PLR does not
	does not support RI-RSVP-FRR extensions.		support RI-RSVP-FRR extensions.
	4.6.2. Procedures for Backward Compatibility		4.6.2. Procedures for Backward Compatibility
	Every node that supports RI-RSVP-FRR MUST support the procedures		Every node that supports RI-RSVP-FRR MUST support the procedures
	defined in this section in order to support backward compatibility		defined in this section in order to support backward compatibility
	for those subset of LSPs that also traverse nodes that do not support		for those subsets of LSPs that also traverse nodes that do not
	RI-RSVP-FRR.		support RI-RSVP-FRR.
	4.6.2.1. Lack of support on Downstream Node		4.6.2.1. Lack of Support on Downstream Nodes
	The procedures on the downstream direction are as follows.		The procedures on the downstream direction are as follows:
	- If a node finds that the Nhop node along the LSP does not support		* If a node finds that the Nhop node along the LSP does not support
	the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh		the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh
	period" in the TIME_VALUES object carried in the Path messages to		period" in the TIME_VALUES object carried in the Path messages to
	the default short refresh interval.		the default short refresh interval.
	- If node protection is requested for the LSP and the NNhop node		* If node protection is requested for the LSP and the NNhop node
	along the LSP path does not support the RI-RSVP-FRR extensions,		along the LSP path does not support the RI-RSVP-FRR extensions,
	then the node MUST reduce the "refresh period" in the TIME_VALUES		then the node MUST reduce the "refresh period" in the TIME_VALUES
	object carried in the Path messages to the default short refresh		object carried in the Path messages to the default short refresh
	interval.		interval.
	If a node reduces the refresh time using the above procedures, it		If a node reduces the refresh time using the above procedures, it
	MUST NOT send any "Remote" PathTear or Conditional PathTear message		MUST NOT send any "Remote" PathTear or Conditional PathTear message
	to the downstream node.		to the downstream node.
	Consider the example topology in Figure 1. If C does not support the		Consider the example topology in Figure 1. If C does not support the
	RI-RSVP-FRR extensions, then:		RI-RSVP-FRR extensions, then:
	- A and B reduce the refresh time to the default short refresh		* A and B reduce the refresh time to the default short refresh
	interval of 30 seconds and trigger a Path message		interval of 30 seconds and trigger a Path message.
	- If B is not an MP and if Phop link of B fails, B cannot send		* If B is not an MP and if the Phop link of B fails, B cannot send a
	Conditional PathTear to C but times out the PSB state from A		Conditional PathTear to C but times out the PSB state from A
	normally. Note that B can time out the PSB state A normally only		normally. Note that B can only normally time out the PSB state A
	if A did not set long refresh in the TIME_VALUES object carried in		if A did not set the long refresh in the TIME_VALUES object
	the Path messages sent earlier.		carried in the Path messages sent earlier.
	4.6.2.2. Lack of support on Upstream Node		4.6.2.2. Lack of Support on Upstream Nodes
	The procedures are as follows.		The procedures on the upstream direction are as follows:
	- If a node finds that the Phop node along the LSP path does not		* If a node finds that the Phop node along the LSP path does not
	support the RI-RSVP-FRR extensions, then the node MUST reduce the		support the RI-RSVP-FRR extensions, then the node MUST reduce the
	"refresh period" in the TIME_VALUES object carried in the Resv		"refresh period" in the TIME_VALUES object carried in the Resv
	messages to the default short refresh interval.		messages to the default short refresh interval.
	- If node protection is requested for the LSP and the Phop node		* If node protection is requested for the LSP and the Phop node
	along the LSP path does not support the RI-RSVP-FRR extensions,		along the LSP path does not support the RI-RSVP-FRR extensions,
	then the node MUST reduce the "refresh period" in the TIME_VALUES		then the node MUST reduce the "refresh period" in the TIME_VALUES
	object carried in the Path messages to the default short refresh		object carried in the Path messages to the default short refresh
	interval (thus, the Nhop can use compatible values when sending a		interval (thus, the Nhop can use compatible values when sending a
	Resv).		Resv).
	- If node protection is requested for the LSP and the PPhop node		* If node protection is requested for the LSP and the PPhop node
	does not support the RI-RSVP-FRR extensions, then the node MUST		does not support the RI-RSVP-FRR extensions, then the node MUST
	reduce the "refresh period" in the TIME_VALUES object carried in		reduce the "refresh period" in the TIME_VALUES object carried in
	the Resv messages to the default short refresh interval.		the Resv messages to the default short refresh interval.
	- If the node reduces the refresh time using the above procedures,		* If the node reduces the refresh time using the above procedures,
	it MUST NOT execute MP procedures specified in Section 4.3 of this		it MUST NOT execute MP procedures specified in Section 4.3 of this
	document.		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
	sections imply that a router supporting the RI-RSVP-FRR extensions		subsections 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 this
	document either in the downstream or upstream direction of an LSP,		document either in the downstream or upstream direction of an LSP,
	depending on the capability of the routers downstream or upstream in		depending on the capability of the routers downstream or upstream in
	the LSP path.		the LSP path.
	- RI-RSVP-FRR extensions and procedures are enabled for downstream		* RI-RSVP-FRR extensions and procedures are enabled for downstream
	Path, PathTear and ResvErr messages corresponding to an LSP if		Path, PathTear, and ResvErr messages corresponding to an LSP if
	link protection is requested for the LSP and the Nhop node		link protection is requested for the LSP and the Nhop node
	supports the extensions		supports the extensions.
	- RI-RSVP-FRR extensions and procedures are enabled for downstream		* RI-RSVP-FRR extensions and procedures are enabled for downstream
	Path, PathTear and ResvErr messages corresponding to an LSP if		Path, PathTear, and ResvErr messages corresponding to an LSP if
	node protection is requested for the LSP and both Nhop & NNhop		node protection is requested for the LSP and both Nhop and 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 the		node protection is requested for the LSP and both Phop and PPhop
	PPhop support the extensions		nodes 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 a
	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.
	4.7. Consequence of Advertising RI-RSVP without RI-RSVP-FRR		4.7. Consequences of Advertising RI-RSVP Without RI-RSVP-FRR
	If a node supporting facility backup protection [RFC4090] sets the		If a node supporting facility backup protection [RFC4090] sets the
	RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR		RI-RSVP capability (I-bit) but does not support the RI-RSVP-FRR
	extensions, due to an implementation bug or configuration error, then		extensions, due to an implementation bug or configuration error, then
	it leaves room for stale state to linger around for an inordinate		it leaves room for the stale state to linger around for an inordinate
	period of time or disruption of normal FRR operation (see Section 3		period of time or for disruption of normal FRR operations (see
	of this document). Consider the example topology Figure 1 provided		Section 3 of this document). Consider the example topology
	in this document.		(Figure 1) provided in this document.
	- Assume node B does set RI-RSVP capability in its Node-ID based		* Assume node B does set the RI-RSVP capability in its Node-ID-based
	Hello messages even though it does not support RI-RSVP-FRR		Hello messages even though it does not support RI-RSVP-FRR
	extensions. When B detects the failure of its Phop link along an		extensions. When B detects the failure of its Phop link along an
	LSP, it will not send Conditional PathTear to C as required by the		LSP, it will not send a Conditional PathTear to C as required by
	RI-RSVP-FRR procedures. If B simply leaves the LSP state without		the RI-RSVP-FRR procedures. If B simply leaves the LSP state
	deleting, then B may end up holding on to the stale state until		without deleting, then B may end up holding on to the stale state
	the (long) refresh timeout.		until the (long) refresh timeout.
	- Instead of node B, assume node C does set RI-RSVP capability in		* Instead of node B, assume node C does set the RI-RSVP capability
	its Node-id based Hello messages even though it does not support		in its Node-ID-based Hello messages even though it does not
	RI-RSVP-FRR extensions. When B details the failure of its Phop		support RI-RSVP-FRR extensions. When B details the failure of its
	link along an LSP, it will send Conditional PathTear to C as		Phop link along an LSP, it will send a Conditional PathTear to C
	required by the RI-RSVP-FRR procedures. But, C would not		as required by the RI-RSVP-FRR procedures. However, C would not
	recognize the condition encoded in the PathTear and end up tearing		recognize the condition encoded in the PathTear and end up tearing
	down the LSP.		down the LSP.
	- Assume node B does set RI-RSVP capability in its Node-ID based		* Assume node B does set the RI-RSVP capability in its Node-ID-based
	Hello messages even though it does not support RI-RSVP-FRR		Hello messages even though it does not support RI-RSVP-FRR
	extensions. Also assume local repair is about to commence on node		extensions. In addition, assume local repair is about to commence
	B for an LSP that has only requested link protection. That is, B		on node B for an LSP that has only requested link protection, that
	has not initiated the backup LSP signaling for the LSP. If node B		is, B has not initiated the backup LSP signaling for the LSP. If
	receives a normal PathTear at this time from ingress A because of		node B receives a normal PathTear at this time from ingress A
	a management event initiated on A, then B simply deletes the LSP		because of a management event initiated on A, then B simply
	state without sending a Remote PathTear to the LP-MP C. So, C may		deletes the LSP state without sending a Remote PathTear to the LP-
	end up holding on to the stale state until the (long) refresh		MP C, so C may end up holding on to the stale state until the
	timeout.		(long) refresh timeout.
	5. Security Considerations		5. Security Considerations
	The security considerations pertaining to the original RSVP protocol		The security considerations pertaining to the original RSVP protocols
	[RFC2205], [RFC3209] and [RFC5920] remain relevant. When using RSVP		([RFC2205], [RFC3209], and [RFC5920]) remain relevant. When using
	Cryptographic Authentication [RFC2747], more robust algorithms such		RSVP cryptographic authentication [RFC2747], more robust algorithms
	as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 [RFC2104][FIPS-180-4]		such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 [RFC2104]
	SHOULD be used when computing the keyed message digest where		[FIPS-180-4] SHOULD be used when computing the keyed message digest
	possible.		where possible.
	This document extends the applicability of Node-ID based Hello		This document extends the applicability of Node-ID-based Hello
	session between immediate neighbors. The Node-ID based Hello session		sessions between immediate neighbors. The Node-ID-based Hello
	between the PLR and the NP-MP may require the two routers to exchange		session between the PLR and the NP-MP may require the two routers to
	Hello messages with non-immediate neighbor. So, the implementations		exchange Hello messages with a non-immediate neighbor. Therefore,
	SHOULD provide the option to configure Node-ID neighbor specific or		the implementations SHOULD provide the option to configure a Node-ID
	global authentication key to authentication messages received from		neighbor specific or global authentication key to authentication
	Node-ID neighbors. The network administrator SHOULD utilize this		messages received from Node-ID neighbors. The network administrator
	option to enable RSVP-TE routers to authenticate Node-ID Hello		SHOULD utilize this option to enable RSVP-TE routers to authenticate
	messages received with TTL greater than 1. Implementations SHOULD		Node-ID Hello messages received with a TTL greater than 1.
	also provide the option to specify a limit on the number of Node-ID		Implementations SHOULD also provide the option to specify a limit on
	based Hello sessions that can be established on a router supporting		the number of Node-ID-based Hello sessions that can be established on
	the extensions defined in this document.		a router supporting the extensions defined in this document.
	6. IANA Considerations		6. IANA Considerations
	6.1. CONDITIONS Object		6.1. CONDITIONS Object
	IANA maintains the Class Names, Class Numbers, and Class Types		IANA maintains the "Class Names, Class Numbers, and Class Types"
	registries in the "RSVP parameters" registry group (see		registry in the "RSVP Parameters" registry group (see
	http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml).		http://www.iana.org/assignments/rsvp-parameters/). IANA has extended
	IANA is requested to extend these registries by adding a new Class		these registries by adding a new Class Number (in the 10bbbbbb range)
	Number (in the 10bbbbbb range) and assign a new C-Type under this		and assigning a new C-Type under this Class Number, as described
	Class Number, as described below (see Section 4.4.3):		below (see Section 4.4.3):
	Class Number Class Name Reference
	TBA1 CONDITIONS This document
	Class Type of C-types - TBA1 CONDITIONS
	Value Class Name Reference
	1 CONDITIONS This document
	IANA is requested to add a new sub-registry for "CONDITIONS Object
	Flags" as shown below. Assignments of additional Class Type values
	for Class Name "CONDITIONS" are to be performed via "IETF Review"
	[RFC8126].
	Bit Number 32-bit Value Name Reference
	0-30 Unassigned
	31 0x0001 Merge-point This document
	All assignments in this sub-registry are to be performed via "IETF
	Review" [RFC8126].
	7. Acknowledgements		+==============+============+===========+
			| Class Number | Class Name | Reference |
			+==============+============+===========+
			| 135 | CONDITIONS | RFC 9705 |
			+--------------+------------+-----------+
	We are very grateful to Yakov Rekhter for his contributions to the		Table 1: Class Names, Class Numbers,
	development of the idea and thorough review of content of the draft.		and Class Types
	We are thankful to Raveendra Torvi and Yimin Shen for their comments
	and inputs on early versions of the draft. We also thank Alexander
	Okonnikov for his review and comments on the draft.
	8. Contributors		+=======+=============+===========+
			| Value | Description | Reference |
			+=======+=============+===========+
			| 1 | CONDITIONS | RFC 9705 |
			+-------+-------------+-----------+
	Markus Jork		Table 2: Class Type or C-Types
	Juniper Networks, Inc.		- 135 CONDITIONS
	Email: mjork@juniper.net
	Harish Sitaraman		IANA has added a subregistry called "CONDITIONS Object Flags" as
	Individual Contributor		shown below. Assignments of additional Class Type values for Class
	Email: harish.ietf@gmail.com		Name "CONDITIONS" are to be performed via "IETF Review" [RFC8126].
	Vishnu Pavan Beeram		+============+==============+=============+===========+
	Juniper Networks, Inc.		| Bit Number | 32-Bit Value | Name | Reference |
	Email: vbeeram@juniper.net		+============+==============+=============+===========+
			| 0-30 | | Unassigned | |
			+------------+--------------+-------------+-----------+
			| 31 | 0x0001 | Merge-point | RFC 9705 |
			+------------+--------------+-------------+-----------+
	Ebben Aries		Table 3: CONDITIONS Object Flags
	Juniper Networks, Inc.
	Email: exa@juniper.com
	Mike Taillon		All assignments in this subregistry are to be performed via "IETF
	Cisco Systems, Inc.		Review" [RFC8126].
	Email: mtaillon@cisco.com
	9. References		7. References
	9.1. Normative References		7.1. Normative References
	[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 27, line 25 ¶		skipping to change at line 1227 ¶
	T. Saad, "Techniques to Improve the Scalability of RSVP-TE		T. Saad, "Techniques to Improve the Scalability of RSVP-TE
	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>.
	[RFC8796] Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A.,		[RFC8796] Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A.,
	Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute		Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute
	Extensions for Label Switched Path (LSP) Tunnels",		Extensions for Label Switched Path (LSP) Tunnels",
	RFC 8796, DOI 10.17487/RFC8796, July 2020,		RFC 8796, DOI 10.17487/RFC8796, July 2020,
	<https://www.rfc-editor.org/info/rfc8796>.		<https://www.rfc-editor.org/info/rfc8796>.
	9.2. Informative References		7.2. Informative References
	[FIPS-180-4]		[FIPS-180-4]
	National Institute of Standards and Technology, "Secure		National Institute of Standards and Technology, "Secure
	Hash Standard", FIPS 180-4, August 2015.		Hash Standard", FIPS PUB 180-4,
			DOI 10.6028/NIST.FIPS.180-4, August 2015,
			<https://nvlpubs.nist.gov/nistpubs/FIPS/
			NIST.FIPS.180-4.pdf>.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	DOI 10.17487/RFC2104, February 1997,		DOI 10.17487/RFC2104, February 1997,
	<https://www.rfc-editor.org/info/rfc2104>.		<https://www.rfc-editor.org/info/rfc2104>.
	[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS		[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
	Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,		Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
	<https://www.rfc-editor.org/info/rfc5920>.		<https://www.rfc-editor.org/info/rfc5920>.
			Acknowledgements
			We are very grateful to Yakov Rekhter for his contributions to the
			development of the idea and thorough review of the content of the
			document. We are thankful to Raveendra Torvi and Yimin Shen for
			their comments and inputs on early versions of the document. We also
			thank Alexander Okonnikov for his review and comments on the
			document.
			Contributors
			Markus Jork
			Juniper Networks, Inc.
			Email: mjork@juniper.net
			Harish Sitaraman
			Individual Contributor
			Email: harish.ietf@gmail.com
			Vishnu Pavan Beeram
			Juniper Networks, Inc.
			Email: vbeeram@juniper.net
			Ebben Aries
			Juniper Networks, Inc.
			Email: exa@juniper.com
			Mike Taillon
			Cisco Systems, Inc.
			Email: mtaillon@cisco.com
	Authors' Addresses		Authors' Addresses
	Chandra Ramachandran		Chandra Ramachandran
	Juniper Networks, Inc.		Juniper Networks, Inc.
	Email: csekar@juniper.net		Email: csekar@juniper.net
	Tarek Saad		Tarek Saad
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: tsaad@cisco.com		Email: tsaad@cisco.com
	Ina Minei		Ina Minei
	Google, Inc.		Google, Inc.
	Email: inaminei@google.com		Email: inaminei@google.com
	Dante Pacella		Dante Pacella
	Verizon, Inc.		Verizon, Inc.
	Email: dante.j.pacella@verizon.com		Email: dante.j.pacella@verizon.com
End of changes. 208 change blocks.
	620 lines changed or deleted		659 lines changed or added
This html diff was produced by rfcdiff 1.48.