rfc9705v2.txt		rfc9705.txt
	skipping to change at line 12 ¶		skipping to change at line 12 ¶
	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 I. Minei
	Google, Inc.		Google, Inc.
	D. Pacella		D. Pacella
	Verizon, Inc.		Verizon, Inc.
	January 2025		January 2025
	Refresh-Interval Independent RSVP-TE 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 allow 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
	repair technique is attractive from a scalability point of view.		repair technique is attractive from a scalability point of view.
	This document enumerates facility backup procedures in RFC 4090 that		This document enumerates facility backup procedures in RFC 4090 that
	rely on refresh timeout, hence, making facility backup method		rely on refresh timeout, hence, making facility backup method
	refresh-interval dependent. The RSVP-TE extensions defined in this		refresh-interval dependent. The RSVP-TE extensions defined in this
	document will enhance the facility backup protection mechanism by		document will enhance the facility backup protection mechanism by
	making the corresponding procedures refresh-interval independent, and		making the corresponding procedures refresh-interval independent, and
	hence, compatible with the Refresh-Interval Independent RSVP (RI-		hence, compatible with the Refresh-Interval Independent RSVP (RI-
	RSVP) capability specified in RFC 8370. Hence, this document updates		RSVP) capability specified in RFC 8370. Hence, this document updates
	RFC 4090 in order to support the RI-RSVP capability specified in RFC		RFC 4090 in order to support the RI-RSVP capability specified in RFC
	skipping to change at line 1101 ¶		skipping to change at line 1101 ¶
	on node B for an LSP that has only requested link protection, that		on node B for an LSP that has only requested link protection, that
	is, B has not initiated the backup LSP signaling for the LSP. If		is, B has not initiated the backup LSP signaling for the LSP. If
	node B receives a normal PathTear at this time from ingress A		node B receives a normal PathTear at this time from ingress A
	because of a management event initiated on A, then B simply		because of a management event initiated on A, then B simply
	deletes the LSP state without sending a Remote PathTear to the LP-		deletes the LSP state without sending a Remote PathTear to the LP-
	MP C, so C may end up holding on to the stale state until the		MP C, so C may end up holding on to the stale state until the
	(long) refresh timeout.		(long) refresh timeout.
	5. Security Considerations		5. Security Considerations
	The security considerations pertaining to the original RSVP protocols		The security considerations pertaining to the original RSVP protocol
	([RFC2205], [RFC3209], and [RFC5920]) remain relevant. When using		([RFC2205], [RFC3209], and [RFC5920]) remain relevant. When using
	RSVP cryptographic authentication [RFC2747], more robust algorithms		RSVP cryptographic authentication [RFC2747], more robust algorithms
	such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 [RFC2104]		such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 [RFC2104]
	[FIPS-180-4] SHOULD be used when computing the keyed message digest		[FIPS-180-4] SHOULD be used when computing the keyed message digest
	where possible.		where possible.
	This document extends the applicability of Node-ID-based Hello		This document extends the applicability of Node-ID-based Hello
	sessions between immediate neighbors. The Node-ID-based Hello		sessions between immediate neighbors. The Node-ID-based Hello
	session between the PLR and the NP-MP may require the two routers to		session between the PLR and the NP-MP may require the two routers to
	exchange Hello messages with a non-immediate neighbor. Therefore,		exchange Hello messages with a non-immediate neighbor. Therefore,
End of changes. 3 change blocks.
	3 lines changed or deleted		3 lines changed or added
This html diff was produced by rfcdiff 1.48.