draft-ietf-mpls-ri-rsvp-frr-07.txt		draft-ietf-mpls-ri-rsvp-frr-08.txt
	MPLS Working Group C. Ramachandran		MPLS Working Group C. Ramachandran
	Internet-Draft T. Saad		Internet-Draft T. 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. Minei
	Expires: March 6, 2020 Google, Inc.		Expires: May 21, 2021 Google, Inc.
	D. Pacella		D. Pacella
	Verizon, Inc.		Verizon, Inc.
	September 3, 2019		November 17, 2020
	Refresh-interval Independent FRR Facility Protection		Refresh-interval Independent FRR Facility Protection
	draft-ietf-mpls-ri-rsvp-frr-07		draft-ietf-mpls-ri-rsvp-frr-08
	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 7 ¶
	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 March 6, 2020.		This Internet-Draft will expire on May 21, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	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 . . . . . . . . . 8		4.2. Signaling Handshake between PLR and MP . . . . . . . . . 8
	4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9		4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 8
	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 . . . . . . . . . . . . . . . . 11
	4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12		4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12
	4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12		4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12
	4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13		4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 12
	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 . . 14
	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 . . . . . . . . . . . 15
	4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16		4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16
	4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 16		4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 16
	4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 17		4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 17
	4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 17		4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 17
	4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18		4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	4.6.1. Detecting Support for Refresh interval Independent		4.6.1. Detecting Support for Refresh interval Independent
	FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19		FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19
	4.6.2. Procedures for Backward Compatibility . . . . . . . . 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 . . . . . . . . 20		4.6.2.2. Lack of support on Upstream Node . . . . . . . . 20
	4.6.2.3. Incremental Deployment . . . . . . . . . . . . . 21		4.6.2.3. Incremental Deployment . . . . . . . . . . . . . 21
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 22		5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 22		6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 22
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	9.1. Normative References . . . . . . . . . . . . . . . . . . 23		9.1. Normative References . . . . . . . . . . . . . . . . . . 23
	9.2. Informative References . . . . . . . . . . . . . . . . . 24		9.2. Informative References . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	RSVP-TE relies on periodic refresh of RSVP messages to synchronize		RSVP-TE relies on periodic refresh of RSVP messages to synchronize
	and maintain the Label Switched Path (LSP) related states along the		and maintain the Label Switched Path (LSP) related states along the
	reserved path. In the absence of refresh messages, the LSP-related		reserved path. In the absence of refresh messages, the LSP-related
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 25 ¶
	NP-MP node: Merge Point router at the tail of Node-Protecting bypass		NP-MP node: Merge Point router at the tail of Node-Protecting bypass
	tunnel		tunnel
	TED: Traffic Engineering Database		TED: Traffic Engineering Database
	LSP state: The combination of "path state" maintained as Path State		LSP state: The combination of "path state" maintained as Path State
	Block (PSB) and "reservation state" maintained as Reservation State		Block (PSB) and "reservation state" maintained as Reservation State
	Block (RSB) forms an individual LSP state on an RSVP-TE speaker		Block (RSB) forms an individual LSP state on an RSVP-TE speaker
	B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object		B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object
	defined in Summary FRR extensions [I-D.ietf-mpls-summary-frr-rsvpte]		defined in Summary FRR extensions [RFC8796] and is added by the PLR
	and is added by the PLR for each protected LSP.		for each protected LSP.
	Conditional PathTear: A PathTear message containing a suggestion to a		Conditional PathTear: A PathTear message containing a suggestion to a
	receiving downstream router to retain the path state if the receiving		receiving downstream router to retain the path state if the receiving
	router is an NP-MP		router is an NP-MP
	Remote PathTear: A PathTear message sent from a Point of Local Repair		Remote PathTear: A PathTear message sent from a Point of Local Repair
	(PLR) to the MP to delete LSP state on the MP if PLR had not reliably		(PLR) to the MP to delete LSP state on the MP if PLR had not reliably
	sent the backup Path state before		sent the backup Path state before
	3. Problem Description		3. Problem Description
	skipping to change at page 7, line 51 ¶		skipping to change at page 7, line 51 ¶
	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		- Utilize MP determination mechanism specified in RSVP-TE Summary
	FRR [I-D.ietf-mpls-summary-frr-rsvpte] that enables the PLR to		FRR [RFC8796] that enables the PLR to signal the availability of
	signal the availability of local protection to the MP. In		local protection to the MP. In addition, introduce PLR and MP
	addition, introduce PLR and MP procedures to establish Node-ID		procedures to to establish Node-ID based hello session between the
	based hello session between the PLR and the MP to detect router		PLR and the MP to detect router failures and to determine
	failures and to determine capability. See section 4.2 for more		capability. See section 4.2 for more details. This part of the
	details. This part of the solution re-uses some of the extensions		solution re-uses some of the extensions defined in RSVP-TE Summary
	defined in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte]		FRR [RFC8796] and RSVP-TE Scaling Techniques [RFC8370], and the
	and RSVP-TE Scaling Techniques [RFC8370], and the subsequent sub-		subsequent sub-sections will list the extensions in these drafts
	sections will list the extensions in these drafts that are		that are utilized in this document.
	utilized in this document.
	- Handle upstream link or node failures by cleaning up LSP states if		- Handle upstream link or node failures by cleaning up LSP states if
	the node has not found itself as an MP through the MP		the node has not found itself as an MP through the MP
	determination mechanism. See section 4.3 for more details.		determination mechanism. See section 4.3 for more details.
	- Introduce extensions to enable a router to send a tear down		- Introduce extensions to enable a router to send a tear down
	message to the downstream router that enables the receiving router		message to the downstream router that enables the receiving router
	to conditionally delete its local LSP state. See section 4.4 for		to conditionally delete its local LSP state. See section 4.4 for
	more details.		more details.
	skipping to change at page 10, line 12 ¶		skipping to change at page 10, line 8 ¶
	set the I-bit in the CAPABILITY object [RFC8370] carried in Hello		set the I-bit in the CAPABILITY object [RFC8370] carried in Hello
	message corresponding to the Node-ID based Hello session, then the		message corresponding to the Node-ID based Hello session, then the
	PLR SHOULD conclude that the MP supports refresh-interval		PLR SHOULD conclude that the MP supports refresh-interval
	independent FRR procedures defined in this document. If the MP		independent FRR procedures defined in this document. If the MP
	has not sent Node-ID based Hello messages or has not set the I-bit		has not sent Node-ID based Hello messages or has not set the I-bit
	in CAPABILITY object [RFC8370], then the PLR MUST execute backward		in CAPABILITY object [RFC8370], then the PLR MUST execute backward
	compatibility procedures defined in Section 4.6.2.1 of this		compatibility procedures defined in Section 4.6.2.1 of this
	document.		document.
	- If the bypass LSP comes up and the PLR has made local protection		- If the bypass LSP comes up and the PLR has made local protection
	available for one or more LSPs, then [I-D.ietf-mpls-summary-frr-		available for one or more LSPs, then RSVP-TE Summary FRR [RFC8796]
	rsvpte] applies: the PLR MUST include B-SFRR-Ready Extended		applies: the PLR MUST include B-SFRR-Ready Extended Association
	Association object and trigger a Path message to be sent for those		object and trigger a Path message to be sent for those LSPs. If a
	LSPs. If a B-SFRR-Ready Extended Association object is included		B-SFRR-Ready Extended Association object is included in the Path
	in the Path message, then the encoding and object ordering rules		message, then the encoding and object ordering rules specified in
	specified in RSVP-TE Summary FRR		RSVP-TE Summary FRR [RFC8796] MUST be followed.
	[I-D.ietf-mpls-summary-frr-rsvpte] MUST be followed.
	4.2.2. Remote Signaling Adjacency		4.2.2. Remote Signaling Adjacency
	A Node-ID based RSVP-TE Hello session is one in which Node-ID is used		A Node-ID based RSVP-TE Hello session is one in which Node-ID is used
	in the source and the destination address fields of RSVP Hello		in the source and the destination address fields of RSVP Hello
	messages [RFC4558]. This document extends Node-ID based RSVP Hello		messages [RFC4558]. This document extends Node-ID based RSVP Hello
	session to track the state of any RSVP-TE neighbor that is not		session to track the state of any RSVP-TE neighbor that is not
	directly connected by at least one interface. In order to apply		directly connected by at least one interface. In order to apply
	Node-ID based RSVP-TE Hello session between any two routers that are		Node-ID based RSVP-TE Hello session between any two routers that are
	not immediate neighbors, the router that supports the extensions		not immediate neighbors, the router that supports the extensions
	skipping to change at page 10, line 40 ¶		skipping to change at page 10, line 35 ¶
	based Hello messages exchanged between the PLR and the MP. The		based Hello messages exchanged between the PLR and the MP. The
	default hello interval for this Node-ID hello session SHOULD be set		default hello interval for this Node-ID hello session SHOULD be set
	to the default specified in RSVP-TE Scaling Techniques [RFC8370].		to the default specified in RSVP-TE Scaling Techniques [RFC8370].
	In the rest of the document the term "signaling adjacency", or		In the rest of the document the term "signaling adjacency", or
	"remote signaling adjacency" refers specifically to the RSVP-TE		"remote signaling adjacency" refers specifically to the RSVP-TE
	signaling adjacency.		signaling adjacency.
	4.2.3. MP Behavior		4.2.3. MP Behavior
	With regard to the MP procedures that are defined in [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 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 LSPs. If the PLR		the RRO object carried in the Resv message of the LSPs. If the PLR
	has not included a Node-ID sub-object in the RRO object carried in		has not included a Node-ID sub-object in the RRO object carried in
	the Path message and if the PLR is in a different IGP area, then the		the Path message and if the PLR is in a different IGP area, then the
	router MUST NOT execute the MP procedures specified in this document		router MUST NOT execute the MP procedures specified in this document
	for those LSPs. Instead, the node MUST execute backward		for those LSPs. Instead, the node MUST execute backward
	skipping to change at page 11, line 24 ¶		skipping to change at page 11, line 19 ¶
	if the PLR has not advertised RI-RSVP capability in its Node-ID based		if the PLR has not advertised RI-RSVP capability in its Node-ID based
	Hello messages, then the node MUST execute backward compatibility		Hello messages, then the node MUST execute backward compatibility
	procedures defined in Section 4.6.2.2.		procedures defined in Section 4.6.2.2.
	If a matching B-SFRR-Ready Extended Association object is found in		If a matching B-SFRR-Ready Extended Association object is found in
	the Path message and if there is an operational remote signaling		the Path message and if there is an operational remote signaling
	adjacency with the PLR that has advertised RI-RSVP capability (I-bit)		adjacency with the PLR that has advertised RI-RSVP capability (I-bit)
	[RFC8370] in its Node-ID based Hello messages, then the node SHOULD		[RFC8370] in its Node-ID based Hello messages, then the node SHOULD
	consider itself as the MP for the corresponding PLR. The matching		consider itself as the MP for the corresponding PLR. The matching
	and ordering rules for Bypass Summary FRR Extended Association		and ordering rules for Bypass Summary FRR Extended Association
	specified in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte]		specified in RSVP-TE Summary FRR [RFC8796] MUST be followed by the
	MUST be followed by the implementations supporting this document.		implementations supporting this document.
	- If a matching Bypass Summary FRR Extended Association object is		- If a matching Bypass Summary FRR Extended Association object is
	included by the PPhop node of an LSP and if a corresponding Node-		included by the PPhop node of an LSP and if a corresponding Node-
	ID signaling adjacency exists with the PPhop node, then the router		ID signaling adjacency exists with the PPhop node, then the router
	SHOULD conclude it is the NP-MP.		SHOULD conclude it is the NP-MP.
	- If a matching Bypass Summary FRR Extended Association object is		- If a matching Bypass Summary FRR Extended Association object is
	included by the Phop node of an LSP and if a corresponding Node-ID		included by the Phop node of an LSP and if a corresponding Node-ID
	signaling adjacency exists with the Phop node, then the router		signaling adjacency exists with the Phop node, then the router
	SHOULD conclude it is the LP-MP.		SHOULD conclude it is the LP-MP.
	skipping to change at page 19, line 17 ¶		skipping to change at page 19, line 11 ¶
	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
	The "Refresh interval Independent FRR" or RI-RSVP-FRR referred below		The "Refresh interval Independent FRR" or RI-RSVP-FRR referred below
	in this section refers to the changes that have been defined in		in this section refers to the changes that have been defined in
	previous sections. Any implementation that does not support them has		previous sections. Any implementation that does not support them has
	been termed as "non-RI-RSVP-FRR implementation". The extensions		been termed as "non-RI-RSVP-FRR implementation". The extensions
	proposed in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte]		proposed in RSVP-TE Summary FRR [RFC8796] are applicable to
	are applicable to implementations that do not support RI-RSVP-FRR.		implementations that do not support RI-RSVP-FRR. On the other hand,
	On the other hand, changes proposed relating to LSP state cleanup		changes proposed relating to LSP state cleanup namely Conditional and
	namely Conditional and "Remote" PathTear require support from one-hop		"Remote" PathTear require support from one-hop and two-hop
	and two-hop neighboring nodes along the LSP path. So procedures that		neighboring nodes along the LSP path. So procedures that fall under
	fall under LSP state cleanup category SHOULD be turned on only if all		LSP state cleanup category SHOULD be turned on only if all nodes
	nodes involved in the node protection FRR i.e. the PLR, the MP and		involved in the node protection FRR i.e. the PLR, the MP and the
	the intermediate node in the case of NP, support the extensions.		intermediate node in the case of NP, support the extensions. Note
	Note that for LSPs requesting only link protection, the PLR and the		that for LSPs requesting only link protection, the PLR and the LP-MP
	LP-MP need to support the extensions.		need to support the extensions.
	4.6.1. Detecting Support for Refresh interval Independent FRR		4.6.1. Detecting Support for Refresh interval Independent FRR
	An implementation supporting the extensions specified in previous		An implementation supporting the extensions specified in previous
	sections (called RI-RSVP-FRR here after) SHOULD set the flag "Refresh		sections (called RI-RSVP-FRR here after) SHOULD set the flag "Refresh
	interval Independent RSVP" or RI-RSVP flag in the CAPABILITY object		interval Independent RSVP" or RI-RSVP flag in the CAPABILITY object
	carried in Hello messages. The RI-RSVP flag is specified in RSVP-TE		carried in Hello messages. The RI-RSVP flag is specified in RSVP-TE
	Scaling Techniques [RFC8370].		Scaling Techniques [RFC8370].
	- As nodes supporting the extensions SHOULD initiate Node Hellos		- As nodes supporting the extensions SHOULD initiate Node Hellos
	skipping to change at page 23, line 31 ¶		skipping to change at page 23, line 24 ¶
	Email: exa@arrcus.com		Email: exa@arrcus.com
	Mike Taillon		Mike Taillon
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: mtaillon@cisco.com		Email: mtaillon@cisco.com
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-mpls-summary-frr-rsvpte]
	Taillon, M., Saad, T., Gandhi, R., Deshmukh, A., Jork, M.,
	and V. Beeram, "RSVP-TE Summary Fast Reroute Extensions
	for LSP Tunnels", draft-ietf-mpls-summary-frr-rsvpte-05
	(work in progress), July 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, DOI 10.17487/RFC2205,		Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
	September 1997, <https://www.rfc-editor.org/info/rfc2205>.		September 1997, <https://www.rfc-editor.org/info/rfc2205>.
	skipping to change at page 24, line 42 ¶		skipping to change at page 24, line 31 ¶
	[RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to		[RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to
	GMPLS Resource Reservation Protocol (RSVP) Graceful		GMPLS Resource Reservation Protocol (RSVP) Graceful
	Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007,		Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007,
	<https://www.rfc-editor.org/info/rfc5063>.		<https://www.rfc-editor.org/info/rfc5063>.
	[RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and		[RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and
	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.,
			Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute
			Extensions for Label Switched Path (LSP) Tunnels",
			RFC 8796, DOI 10.17487/RFC8796, July 2020,
			<https://www.rfc-editor.org/info/rfc8796>.
	9.2. Informative References		9.2. Informative References
	[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS		[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
	Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,		Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
	<https://www.rfc-editor.org/info/rfc5920>.		<https://www.rfc-editor.org/info/rfc5920>.
	Authors' Addresses		Authors' Addresses
	Chandra Ramachandran		Chandra Ramachandran
	Juniper Networks, Inc.		Juniper Networks, Inc.
	Email: csekar@juniper.net		Email: csekar@juniper.net
	Tarek Saad		Tarek Saad
	Juniper Networks, Inc.		Juniper Networks, Inc.
	Email: tsaad@juniper.net		Email: tsaad@juniper.net
	Ina Minei		Ina Minei
	Google, Inc.		Google, Inc.
	Email: inaminei@google.com		Email: inaminei@google.com
End of changes. 18 change blocks.
	47 lines changed or deleted		45 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/