draft-ietf-mpls-ri-rsvp-frr-11.txt		draft-ietf-mpls-ri-rsvp-frr-12.txt
	MPLS Working Group C. Ramachandran		MPLS Working Group C R. Ramachandran
	Internet-Draft T. Saad		Internet-Draft T S. Saad
	Updates: 4090 (if approved) Juniper Networks, Inc.		Updates: 4090 (if approved) Juniper Networks, Inc.
	Intended status: Standards Track I. Minei		Intended status: Standards Track I M. Minei
	Expires: December 22, 2021 Google, Inc.		Expires: 22 June 2022 Google, Inc.
	D. Pacella		D P. Pacella
	Verizon, Inc.		Verizon, Inc.
	June 20, 2021		19 December 2021
	Refresh-interval Independent FRR Facility Protection		Refresh-interval Independent FRR Facility Protection
	draft-ietf-mpls-ri-rsvp-frr-11		draft-ietf-mpls-ri-rsvp-frr-12
	Abstract		Abstract
	RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two		RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two
	local repair techniques to reroute Label Switched Path (LSP) traffic		local repair techniques to reroute Label Switched Path (LSP) traffic
	over pre-established backup tunnel. Facility backup method allows		over pre-established backup tunnel. Facility backup method allows
	one or more LSPs traversing a connected link or node to be protected		one or more LSPs traversing a connected link or node to be protected
	using a bypass tunnel. The many-to-one nature of local repair		using a bypass tunnel. The many-to-one nature of local repair
	technique is attractive from scalability point of view. This		technique is attractive from scalability point of view. This
	document enumerates facility backup procedures in RFC 4090 that rely		document enumerates facility backup procedures in RFC 4090 that rely
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 22, 2021.		This Internet-Draft will expire on 22 June 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5		3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5
	4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7		4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP		4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP
	Capability . . . . . . . . . . . . . . . . . . . . . . . 8		Capability . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Signaling Handshake between PLR and MP . . . . . . . . . 9		4.2. Signaling Handshake between PLR and MP . . . . . . . . . 9
	4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9		4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9
	4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10		4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10
	4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10		4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10
	4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 11		4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 12
	4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12		4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12
	4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12		4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 13
	4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13		4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13
	4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13		4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13
	4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 14		4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 15
	4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15		4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15
	4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15		4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15
	4.4.2. Processing Conditional PathTear . . . . . . . . . . . 15		4.4.2. Processing Conditional PathTear . . . . . . . . . . . 16
	4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16		4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16
	4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 17		4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 17
	4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 17		4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 18
	4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 17		4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 18
	4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18		4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18
	4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 18		4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 18
	4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 18		4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 19
	4.6. Backward Compatibility Procedures . . . . . . . . . . . . 19		4.6. Backward Compatibility Procedures . . . . . . . . . . . . 19
	4.6.1. Detecting Support for Refresh interval Independent		4.6.1. Detecting Support for Refresh interval Independent
	FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19		FRR . . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.6.2. Procedures for Backward Compatibility . . . . . . . . 20		4.6.2. Procedures for Backward Compatibility . . . . . . . . 20
	4.6.2.1. Lack of support on Downstream Node . . . . . . . 20		4.6.2.1. Lack of support on Downstream Node . . . . . . . 20
	4.6.2.2. Lack of support on Upstream Node . . . . . . . . 21		4.6.2.2. Lack of support on Upstream Node . . . . . . . . 21
	4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR . . . . . 21		4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR . . . . . 22
	4.6.2.4. Incremental Deployment . . . . . . . . . . . . . 22		4.6.2.4. Incremental Deployment . . . . . . . . . . . . . 22
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 23		5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 23		6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 24
	6.2. CONDITIONS Flags . . . . . . . . . . . . . . . . . . . . 24		6.2. CONDITIONS Flags . . . . . . . . . . . . . . . . . . . . 24
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	9.1. Normative References . . . . . . . . . . . . . . . . . . 24		9.1. Normative References . . . . . . . . . . . . . . . . . . 24
	9.2. Informative References . . . . . . . . . . . . . . . . . 26		9.2. Informative References . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	/ \		/ \
	A ----- B ----- C ----- D		A ----- B ----- C ----- D
	\ /		\ /
	\ /		\ /
	\ /		\ /
	\ /		\ /
	\ /		\ /
	\ /		\ /
	F		F
	Figure 1: Example Topology		Figure 1: Example Topology
	In the topology in Figure 1, let us consider a large number of LSPs		In the topology in Figure 1, let us consider a large number of LSPs
	from A to D transiting B and C. Assume that refresh interval has		from A to D transiting B and C. Assume that refresh interval has
	been configured to be long of the order of minutes and refresh		been configured to be long of the order of minutes and refresh
	reduction extensions are enabled on all routers.		reduction extensions are enabled on all routers.
	Also let us assume that node protection has been configured for the		Also let us assume that node protection has been configured for the
	LSPs and 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;
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 43 ¶
	- 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 B-C link fails. The following is
	the sequence of events that is expected to occur for all protected		the sequence of events that is expected to occur for all protected
	LSPs under normal conditions.		LSPs under normal conditions.
	1. B performs local repair and re-directs LSP traffic over the bypass		1. B performs local repair and re-directs LSP traffic over the
	LSP B -> F -> D.		bypass LSP B -> F -> D.
	2. B also creates backup state for the LSP and triggers sending of		2. B also creates backup state for the LSP and triggers sending of
	backup LSP state to D over the bypass LSP B -> F -> D.		backup LSP state to D over the bypass LSP B -> F -> D.
	3. D receives backup LSP states and merges the backups with the		3. D receives backup LSP states and merges the backups with the
	protected LSPs.		protected LSPs.
	4. As the link on C, over which the LSP states are refreshed, has		4. As the link on C, over which the LSP states are refreshed, has
	failed, C will no longer receive state refreshes. Consequently		failed, C will no longer receive state refreshes. Consequently
	the protected LSP states on C will time out and C will send the		the protected LSP states on C will time out and C will send the
	tear down messages for all LSPs. As each router should consider		tear down messages for all LSPs. As each router should consider
	itself as an MP, C will time out the state only after waiting for		itself as an MP, C will time out the state only after waiting for
	an additional duration equal to refresh timeout.		an additional duration equal to refresh timeout.
	While the above sequence of events has been described in [RFC4090],		While the above sequence of events has been described in [RFC4090],
	there are a few problems for which no mechanism has been specified		there are a few problems for which no mechanism has been specified
	explicitly.		explicitly.
	skipping to change at page 14, line 23 ¶		skipping to change at page 14, line 36 ¶
	behavior is required for unprotected LSPs - Section 4.3.1). In the		behavior is required for unprotected LSPs - Section 4.3.1). In the
	data plane, that would require B to delete the label forwarding entry		data plane, that would require B to delete the label forwarding entry
	corresponding to the LSP. So if B's downstream nodes C and D		corresponding to the LSP. So if B's downstream nodes C and D
	continue to retain state, it would not be correct for D to continue		continue to retain state, it would not be correct for D to continue
	to assume itself as the NP-MP for the PLR B.		to assume itself as the NP-MP for the PLR B.
	The mechanism that enables D to stop considering itself as the NP-MP		The mechanism that enables D to stop considering itself as the NP-MP
	for B and delete the corresponding "remote" path state is given		for B and delete the corresponding "remote" path state is given
	below.		below.
	1. When C receives a Conditional PathTear from B, it decides to		1. When C receives a Conditional PathTear from B, it decides to
	retain LSP state as it is the NP-MP of the PLR A. C also MUST		retain LSP state as it is the NP-MP of the PLR A. C also MUST
	check whether Phop B had previously signaled availability of node		check whether Phop B had previously signaled availability of node
	protection. As B had previously signaled NP availability by		protection. As B had previously signaled NP availability by
	including B-SFRR-Ready Extended Association object, C MUST remove		including B-SFRR-Ready Extended Association object, C MUST remove
	the B-SFRR-Ready Extended Association object containing		the B-SFRR-Ready Extended Association object containing
	Association Source set to B from the Path message and trigger a		Association Source set to B from the Path message and trigger a
	Path to D.		Path to D.
	2. When D receives the Path message, it realizes that it is no longer		2. When D receives the Path message, it realizes that it is no
	the NP-MP for B and so it deletes the corresponding "remote" path		longer the NP-MP for B and so it deletes the corresponding
	state. D does not propagate the Path further down because the		"remote" path state. D does not propagate the Path further down
	only change is that the B-SFRR-Ready Extended Association object		because the only change is that the B-SFRR-Ready Extended
	corresponding to Association Source B is no longer present in the		Association object corresponding to Association Source B is no
	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 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 as well as the NP-MP for the
	Phop and the PPhop nodes respectively of an LSP. If the Phop link		Phop and the PPhop nodes respectively of an LSP. If the Phop link
	fails on such a node, the node MUST retain the PSB and RSB states		fails on such a node, the node MUST retain the PSB and RSB states
	corresponding to the LSP till the occurrence of any of the following		corresponding to the LSP till the occurrence of any of the following
	events.		events.
	- Both Node-ID signaling adjacencies with Phop and PPhop nodes go		- Both Node-ID signaling adjacencies with Phop and PPhop nodes go
	skipping to change at page 16, line 35 ¶		skipping to change at page 17, line 5 ¶
	The object has the following format:		The object has the following format:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class | C-type |		| Length | Class | C-type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |M|		| Reserved |M|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: CONDITIONS Object		Figure 2: CONDITIONS Object
	Length: This contains the size of the object in bytes and should		* Length: This contains the size of the object in bytes and should
	be set to eight.		be set to eight.
	Class: To be assigned		Class: To be assigned
	C-type: 1		C-type: 1
	Merge-point condition (M) bit: If the M bit is set to 1, then the		Merge-point condition (M) bit: If the M bit is set to 1, then the
	PathTear message MUST be processed according to the receiver		PathTear message MUST be processed according to the receiver
	router role, i.e. if the receiving router is an MP or not for the		router role, i.e. if the receiving router is an MP or not for the
	LSP.		LSP.
	If the M-bit is set to 0, then the PathTear message MUST be		If the M-bit is set to 0, then the PathTear message MUST be
	processed processed as a normal PathTear message for the LSP.		processed processed as a normal PathTear message for the LSP.
	4.5. Remote State Teardown		4.5. Remote State Teardown
	If the ingress wants to tear down the LSP because of a management		If the ingress wants to tear down the LSP because of a management
	skipping to change at page 17, line 19 ¶		skipping to change at page 17, line 30 ¶
	would not be desirable to wait till the completion of backup LSP		would not be desirable to wait till the completion of backup LSP
	signaling to perform state cleanup. To enable LSP state cleanup when		signaling to perform state cleanup. To enable LSP state cleanup when
	the LSP is being locally repaired, the PLR MUST send a "Remote"		the LSP is being locally repaired, the PLR MUST send a "Remote"
	PathTear message instructing the MP to delete the PSB and RSB states		PathTear message instructing the MP to delete the PSB and RSB states
	corresponding to the LSP. The TTL in the "Remote" PathTear message		corresponding to the LSP. The TTL in the "Remote" PathTear message
	MUST be set to 255.		MUST be set to 255.
	Let us consider that node C in the example topology (Figure 1) has		Let us consider that node C in the example topology (Figure 1) has
	gone down and node B locally repairs the LSP.		gone down and node B locally repairs the LSP.
	1. Ingress A receives a management event to tear down the LSP.		1. Ingress A receives a management event to tear down the LSP.
	2. A sends a normal PathTear 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 during		3. Assume B has not initiated the backup signaling for the LSP
	local repair. To enable LSP state cleanup, B MUST send a "Remote"		during local repair. To enable LSP state cleanup, B MUST send a
	PathTear with destination IP address set to that of the node D		"Remote" PathTear with destination IP address set to that of the
	used in the Node-ID signaling adjacency with D, and the RSVP_HOP		node D used in the Node-ID signaling adjacency with D, and the
	object containing local address used in the Node-ID signaling		RSVP_HOP object containing local address used in the Node-ID
	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 D
	MUST accept the "Remote" PathTear and delete the PSB and RSB		MUST accept the "Remote" PathTear and delete the PSB and RSB
	states corresponding to the LSP.		states corresponding to the LSP.
	4.5.1. PLR Behavior on Local Repair Failure		4.5.1. PLR Behavior on Local Repair Failure
	If local repair fails on the PLR after a failure, then this MUST be		If local repair fails on the PLR after a failure, then this MUST be
	considered as a case for cleaning up LSP state from the PLR to the		considered as a case for cleaning up LSP state from the PLR to the
	Egress. The PLR achieves state cleanup by sending "Remote" PathTear		Egress. The PLR achieves state cleanup by sending "Remote" PathTear
	to the MP. The MP MUST delete the states corresponding to the LSP		to the MP. The MP MUST delete the states corresponding to the LSP
	also also propagate the PathTear downstream thereby achieving state		also also propagate the PathTear downstream thereby achieving state
	skipping to change at page 19, line 5 ¶		skipping to change at page 19, line 20 ¶
	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 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 any more requiring
	the node to clean up LSP state.		the node to clean up LSP state.
	Let us consider that B-C link goes down on the same example topology		Let us consider that B-C link goes down on the same example topology
	(Figure 1). As C is the NP-MP for the PLR A, C will retain LSP		(Figure 1). As C is the NP-MP for the PLR A, C will retain LSP
	state.		state.
	1. The LSP is preempted on C.		1. The LSP is preempted on C.
	2. C will delete the RSB state corresponding to the LSP. But C		2. C will delete the RSB state corresponding to the LSP. But C
	cannot send a PathErr or a ResvTear to the PLR A because the		cannot send a PathErr or a ResvTear to the PLR A because the
	backup LSP has not been signaled yet.		backup LSP has not been signaled yet.
	3. As the only reason for C having retained state after Phop node		3. As the only reason for C having retained state after Phop node
	failure was that it was an NP-MP, C MUST send a normal PathTear to		failure was that it was an NP-MP, C MUST send a normal PathTear to
	D and delete its PSB state also. D would also delete the PSB and		D and delete its PSB state also. 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. But as D does not have the
	LSP state, it will reject the backup LSP Path and send a PathErr		LSP state, it will reject the backup LSP Path and send a PathErr
	to B.		to B.
	5. B will delete its reservation and send a ResvTear to A.		5. B will delete its reservation and send a ResvTear to A.
	4.6. Backward Compatibility Procedures		4.6. Backward Compatibility Procedures
	"Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set		"Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set
	of procedures defined in this document to elimiate the reliance of		of procedures defined in this document to elimiate the reliance of
	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" PathTear require support from
	one-hop and two-hop neighboring nodes along the LSP path. So		one-hop and two-hop neighboring nodes along the LSP path. So
	skipping to change at page 23, line 44 ¶		skipping to change at page 24, line 12 ¶
	based Hello sessions that can be established on a router supporting		based Hello sessions that can be established on a router supporting
	the extensions defined in this document.		the extensions defined in this document.
	6. IANA Considerations		6. IANA Considerations
	6.1. New Object - CONDITIONS		6.1. New Object - CONDITIONS
	RSVP Change Guidelines [RFC3936] defines the Class-Number name space		RSVP Change Guidelines [RFC3936] defines the Class-Number name space
	for RSVP objects. The name space is managed by IANA.		for RSVP objects. The name space is managed by IANA.
	IANA registry: RSVP Parameters		IANA registry: RSVP Parameters Subsection: Class Names, Class
	Subsection: Class Names, Class Numbers, and Class Types		Numbers, and Class Types
	A new RSVP object using a Class-Number from 128-183 range called the		A new RSVP object using a Class-Number from 128-183 range called the
	"CONDITIONS" object is defined in Section 4.4 of this document. The		"CONDITIONS" object is defined in Section 4.4 of this document. The
	Class-Number from 128-183 range will be allocated by IANA.		Class-Number from 128-183 range will be allocated by IANA.
	6.2. CONDITIONS Flags		6.2. CONDITIONS Flags
	Apart from allocating Class-Number for the CONDITIONS object, the		Apart from allocating Class-Number for the CONDITIONS object, the
	allocation of the Merge-point condition bit or M-bit Section 4.4 will		allocation of the Merge-point condition bit or M-bit Section 4.4 will
	also be done by IANA.		also be done by IANA.
	skipping to change at page 24, line 23 ¶		skipping to change at page 24, line 37 ¶
	7. Acknowledgements		7. Acknowledgements
	We are very grateful to Yakov Rekhter for his contributions to the		We are very grateful to Yakov Rekhter for his contributions to the
	development of the idea and thorough review of content of the draft.		development of the idea and thorough review of content of the draft.
	We are thankful to Raveendra Torvi and Yimin Shen for their comments		We are thankful to Raveendra Torvi and Yimin Shen for their comments
	and inputs on early versions of the draft. We also thank Alexander		and inputs on early versions of the draft. We also thank Alexander
	Okonnikov for his review and comments on the draft.		Okonnikov for his review and comments on the draft.
	8. Contributors		8. Contributors
	Markus Jork		Markus Jork Juniper Networks, Inc. Email: mjork@juniper.net Harish
	Juniper Networks, Inc.		Sitaraman Individual Contributor Email: harish.ietf@gmail.com Vishnu
	Email: mjork@juniper.net		Pavan Beeram Juniper Networks, Inc. Email: vbeeram@juniper.net Ebben
			Aries Arrcus, Inc. Email: exa@arrcus.com Mike Taillon Cisco Systems,
	Harish Sitaraman		Inc. Email: mtaillon@cisco.com
	Individual Contributor
	Email: harish.ietf@gmail.com
	Vishnu Pavan Beeram
	Juniper Networks, Inc.
	Email: vbeeram@juniper.net
	Ebben Aries
	Arrcus, Inc.
	Email: exa@arrcus.com
	Mike Taillon
	Cisco Systems, Inc.
	Email: mtaillon@cisco.com
	9. References		9. References
	9.1. Normative References		9.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>.
End of changes. 38 change blocks.
	80 lines changed or deleted		62 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/