rfc9705v3.txt		rfc9705.txt
	Internet Engineering Task Force (IETF) C. Ramachandran		Internet Engineering Task Force (IETF) C. Ramachandran
	Request for Comments: 9705 Juniper Networks, Inc.		Request for Comments: 9705 Juniper Networks, Inc.
	Updates: 4090 T. Saad		Updates: 4090 T. Saad
	Category: Standards Track Cisco Systems, Inc.		Category: Standards Track Cisco Systems, Inc.
	ISSN: 2070-1721 I. Minei		ISSN: 2070-1721 D. Pacella
	Google, Inc.
	D. Pacella
	Verizon, Inc.		Verizon, Inc.
	January 2025		March 2025
	Refresh-Interval Independent RSVP Fast Reroute Facility Protection		Refresh-Interval Independent RSVP Fast Reroute Facility Protection
	Abstract		Abstract
	The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090		The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090
	define two local repair techniques to reroute Label Switched Path		define two local repair techniques to reroute Label Switched Path
	(LSP) traffic over pre-established backup tunnels. Facility backup		(LSP) traffic over pre-established backup tunnels. Facility backup
	method allows one or more LSPs traversing a connected link or node to		method allows one or more LSPs traversing a connected link or node to
	be protected using a bypass tunnel. The many-to-one nature of local		be protected using a bypass tunnel. The many-to-one nature of local
	skipping to change at line 105 ¶		skipping to change at line 103 ¶
	4.4.1. Sending the Conditional PathTear		4.4.1. Sending the Conditional PathTear
	4.4.2. Processing the Conditional PathTear		4.4.2. Processing the Conditional PathTear
	4.4.3. CONDITIONS Object		4.4.3. CONDITIONS Object
	4.5. Remote State Teardown		4.5. Remote State Teardown
	4.5.1. PLR Behavior on Local Repair Failure		4.5.1. PLR Behavior on Local Repair Failure
	4.5.2. PLR Behavior on Resv RRO Change		4.5.2. PLR Behavior on Resv RRO Change
	4.5.3. LSP Preemption During Local Repair		4.5.3. LSP Preemption During Local Repair
	4.5.3.1. Preemption on LP-MP After PHOP Link Failure		4.5.3.1. Preemption on LP-MP After PHOP Link Failure
	4.5.3.2. Preemption on NP-MP After PHOP Link Failure		4.5.3.2. Preemption on NP-MP After PHOP Link Failure
	4.6. Backward Compatibility Procedures		4.6. Backward Compatibility Procedures
	4.6.1. Detecting Support for Refresh-Interval Independent		4.6.1. Detecting Support for Refresh-Interval Independent RSVP
	RSVP-TE FRR		FRR
	4.6.2. Procedures for Backward Compatibility		4.6.2. Procedures for Backward Compatibility
	4.6.2.1. Lack of Support on Downstream Nodes		4.6.2.1. Lack of Support on Downstream Nodes
	4.6.2.2. Lack of Support on Upstream Nodes		4.6.2.2. Lack of Support on Upstream Nodes
	4.6.2.3. Incremental Deployment		4.6.2.3. Incremental Deployment
	4.7. Consequences of Advertising RI-RSVP Without RI-RSVP-FRR		4.7. Consequences of Advertising RI-RSVP Without RI-RSVP-FRR
	5. Security Considerations		5. Security Considerations
	6. IANA Considerations		6. IANA Considerations
	6.1. CONDITIONS Object		6.1. CONDITIONS Object
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	skipping to change at line 915 ¶		skipping to change at line 913 ¶
	RSB states on receiving a PathTear from C.		RSB states on receiving a PathTear from C.
	4. B starts backup LSP signaling to D. However, as D does not have		4. B starts backup LSP signaling to D. However, as D does not have
	the LSP state, it will reject the backup LSP Path message and		the LSP state, it will reject the backup LSP Path message and
	send a PathErr to B.		send a 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 RSVP-TE FRR" and "RI-RSVP-FRR" refer to		"Refresh-Interval Independent RSVP FRR" and "RI-RSVP-FRR" refer to
	the set of procedures defined in this document to eliminate the		the set of procedures defined in this document to eliminate the
	reliance on periodic refreshes. The extensions proposed in RSVP-TE		reliance on periodic refreshes. The extensions proposed in RSVP-TE
	Summary FRR [RFC8796] may apply to implementations that do not		Summary FRR [RFC8796] may apply to implementations that do not
	support RI-RSVP-FRR. On the other hand, RI-RSVP-FRR extensions		support RI-RSVP-FRR. On the other hand, RI-RSVP-FRR extensions
	relating to LSP state cleanup, namely Conditional and "Remote"		relating to LSP state cleanup, namely Conditional and "Remote"
	PathTears, require support from one-hop and two-hop neighboring nodes		PathTears, require support from one-hop and two-hop neighboring nodes
	along the LSP. Thus, procedures that fall under the LSP state		along the LSP. Thus, procedures that fall under the LSP state
	cleanup category MUST NOT be turned on if any of the nodes involved		cleanup category MUST NOT be turned on if any of the nodes involved
	in the node protection FRR (i.e., the PLR, the MP, and the		in the node protection FRR (i.e., the PLR, the MP, and the
	intermediate node in the case of NP) do not support RI-RSVP-FRR		intermediate node in the case of NP) do not support RI-RSVP-FRR
	extensions. Note that for LSPs requesting link protection, only the		extensions. Note that for LSPs requesting link protection, only the
	PLR and the LP-MP MUST support the extensions.		PLR and the LP-MP MUST support the extensions.
	4.6.1. Detecting Support for Refresh-Interval Independent RSVP-TE FRR		4.6.1. Detecting Support for Refresh-Interval Independent RSVP FRR
	An implementation supporting RI-RSVP-FRR extensions MUST set the RI-		An implementation supporting RI-RSVP-FRR extensions MUST set the RI-
	RSVP Capable flag in the CAPABILITY object carried in Hello messages		RSVP Capable flag in the CAPABILITY object carried in Hello messages
	as specified in RSVP-TE Scaling Techniques [RFC8370]. If an		as specified in RSVP-TE Scaling Techniques [RFC8370]. If an
	implementation does not set the flag even if it supports RI-RSVP-FRR		implementation does not set the flag even if it supports RI-RSVP-FRR
	extensions, then its neighbors will view the node as any node that		extensions, then its neighbors will view the node as any node that
	does not support the extensions.		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
	skipping to change at line 1127 ¶		skipping to change at line 1125 ¶
	1. Implementations SHOULD also provide the option to specify a limit		1. Implementations SHOULD also provide the option to specify a limit
	on the number of Node-ID-based Hello sessions that can be established		on the number of Node-ID-based Hello sessions that can be established
	on a router supporting the extensions defined in this document.		on 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"
	registry in the "RSVP Parameters" registry group (see		registry in the "RSVP Parameters" registry group (see
	http://www.iana.org/assignments/rsvp-parameters/). IANA has extended		<http://www.iana.org/assignments/rsvp-parameters/>). IANA has
	these registries by adding a new Class Number (in the 10bbbbbb range)		extended these registries by adding a new Class Number (in the
	and assigning a new C-Type under this Class Number, as described		10bbbbbb range) and assigning a new C-Type under this Class Number,
	below (see Section 4.4.3):		as described below (see Section 4.4.3). New Class Type values for
			Class Name "CONDITIONS" can be added via "IETF Review" [RFC8126].
	+==============+============+===========+		+==============+============+===========+
	| Class Number | Class Name | Reference |		| Class Number | Class Name | Reference |
	+==============+============+===========+		+==============+============+===========+
	| 135 | CONDITIONS | RFC 9705 |		| 135 | CONDITIONS | RFC 9705 |
	+--------------+------------+-----------+		+--------------+------------+-----------+
	Table 1: Class Names, Class Numbers,		Table 1: Class Names, Class Numbers,
	and Class Types		and Class Types
	+=======+=============+===========+		+=======+=============+===========+
	| Value | Description | Reference |		| Value | Description | Reference |
	+=======+=============+===========+		+=======+=============+===========+
	| 1 | CONDITIONS | RFC 9705 |		| 1 | CONDITIONS | RFC 9705 |
	+-------+-------------+-----------+		+-------+-------------+-----------+
	Table 2: Class Type or C-Types		Table 2: Class Types or C-Types
	- 135 CONDITIONS		- 135 CONDITIONS
	IANA has added a subregistry called "CONDITIONS Object Flags" as		IANA has added a subregistry called "CONDITIONS Object Flags" as
	shown below. Assignments of additional Class Type values for Class		shown below. New registrations can be added via "IETF Review"
	Name "CONDITIONS" are to be performed via "IETF Review" [RFC8126].		[RFC8126].
	+============+==============+=============+===========+		+============+==============+=============+===========+
	| Bit Number | 32-Bit Value | Name | Reference |		| Bit Number | 32-Bit Value | Name | Reference |
	+============+==============+=============+===========+		+============+==============+=============+===========+
	| 0-30 | | Unassigned | |		| 0-30 | | Unassigned | |
	+------------+--------------+-------------+-----------+		+------------+--------------+-------------+-----------+
	| 31 | 0x0001 | Merge-point | RFC 9705 |		| 31 | 0x0001 | Merge-point | RFC 9705 |
	+------------+--------------+-------------+-----------+		+------------+--------------+-------------+-----------+
	Table 3: CONDITIONS Object Flags		Table 3: CONDITIONS Object Flags
	skipping to change at line 1266 ¶		skipping to change at line 1265 ¶
	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 the content of the		development of the idea and thorough review of the content of the
	document. We are thankful to Raveendra Torvi and Yimin Shen for		document. We are thankful to Raveendra Torvi and Yimin Shen for
	their comments and inputs on early versions of the document. We also		their comments and inputs on early versions of the document. We also
	thank Alexander Okonnikov for his review and comments on the		thank Alexander Okonnikov for his review and comments on the
	document.		document.
	Contributors		Contributors
			Ina Minei
			Google, Inc.
			Email: inaminei@google.com
	Markus Jork		Markus Jork
	Juniper Networks, Inc.		Juniper Networks, Inc.
	Email: mjork@juniper.net		Email: mjork@juniper.net
	Harish Sitaraman		Harish Sitaraman
	Individual Contributor		Individual Contributor
	Email: harish.ietf@gmail.com		Email: harish.ietf@gmail.com
	Vishnu Pavan Beeram		Vishnu Pavan Beeram
	Juniper Networks, Inc.		Juniper Networks, Inc.
	skipping to change at line 1296 ¶		skipping to change at line 1299 ¶
	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
	Google, Inc.
	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. 10 change blocks.
	19 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.48.