< draft-ietf-rtgwg-rlfa-node-protection-06.txt		draft-ietf-rtgwg-rlfa-node-protection-07.txt >
	skipping to change at page 1, line 15 ¶		skipping to change at page 1, line 15 ¶
	Intended status: Standards Track S. Hegde		Intended status: Standards Track S. Hegde
	Expires: April 11, 2017 C. Bowers		Expires: April 11, 2017 C. Bowers
	Juniper Networks, Inc.		Juniper Networks, Inc.
	H. Gredler		H. Gredler
	RtBrick Inc.		RtBrick Inc.
	S. Litkowski		S. Litkowski
	Orange		Orange
	October 8, 2016		October 8, 2016
	Remote-LFA Node Protection and Manageability		Remote-LFA Node Protection and Manageability
	draft-ietf-rtgwg-rlfa-node-protection-06		draft-ietf-rtgwg-rlfa-node-protection-07
	Abstract		Abstract
	The loop-free alternates computed following the current Remote-LFA		The loop-free alternates computed following the current Remote-LFA
	specification guarantees only link-protection. The resulting Remote-		specification guarantees only link-protection. The resulting Remote-
	LFA nexthops (also called PQ-nodes), may not guarantee node-		LFA nexthops (also called PQ-nodes), may not guarantee node-
	protection for all destinations being protected by it.		protection for all destinations being protected by it.
	This document describes procedures for determining if a given PQ-node		This document describes procedures for determining if a given PQ-node
	provides node-protection for a specific destination or not. The		provides node-protection for a specific destination or not. The
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	1. Introduction		1. Introduction
	The Remote-LFA [RFC7490] specification provides loop-free alternates		The Remote-LFA [RFC7490] specification provides loop-free alternates
	that guarantee only link-protection. The resulting Remote-LFA		that guarantee only link-protection. The resulting Remote-LFA
	alternate nexthops (also referred to as the PQ-nodes) may not provide		alternate nexthops (also referred to as the PQ-nodes) may not provide
	node-protection for all destinations covered by the same, in case of		node-protection for all destinations covered by the same, in case of
	failure of the primary nexthop node. Neither does the specification		failure of the primary nexthop node. Neither does the specification
	provide a means to determine the same.		provide a means to determine the same.
	Also, the LFA Manageability [I-D.ietf-rtgwg-lfa-manageability]		Also, the LFA Manageability [RFC7916] document, requires a computing
	document, requires a computing router to find all possible (including		router to find all possible (including all possible Remote-LFA)
	all possible Remote-LFA) alternate nexthops, collect the complete set		alternate nexthops, collect the complete set of path characteristics
	of path characteristics for each alternate path, run a alternate-		for each alternate path, run a alternate-selection policy (configured
	selection policy (configured by the operator), and find the best		by the operator), and find the best alternate path. This will
	alternate path. This will require the Remote-LFA implementation to		require the Remote-LFA implementation to gather all the required path
	gather all the required path characteristics along each link on the		characteristics along each link on the entire Remote-LFA alternate
	entire Remote-LFA alternate path.		path.
	With current LFA [RFC5286] and Remote-LFA implementations, the		With current LFA [RFC5286] and Remote-LFA implementations, the
	forward SPF (and reverse SPF) is run on the computing router and its		forward SPF (and reverse SPF) is run on the computing router and its
	immediate 1-hop routers as the roots. While that enables computation		immediate 1-hop routers as the roots. While that enables computation
	of path attributes (e.g. SRLG, Admin-groups) for first alternate		of path attributes (e.g. SRLG, Admin-groups) for first alternate
	path segment from the computing router to the PQ-node, there is no		path segment from the computing router to the PQ-node, there is no
	means for the computing router to gather any path attributes for the		means for the computing router to gather any path attributes for the
	path segment from the PQ-node to destination. Consequently any		path segment from the PQ-node to destination. Consequently any
	policy-based selection of alternate paths will consider only the path		policy-based selection of alternate paths will consider only the path
	attributes from the computing router up until the PQ-node.		attributes from the computing router up until the PQ-node.
	skipping to change at page 4, line 49 ¶		skipping to change at page 4, line 49 ¶
	Table 1: Remote-LFA backup paths via PQ-node R2		Table 1: Remote-LFA backup paths via PQ-node R2
	A closer look at Table 1 shows that, while the PQ-node R2 provides		A closer look at Table 1 shows that, while the PQ-node R2 provides
	link-protection for all the destinations, it does not provide node-		link-protection for all the destinations, it does not provide node-
	protection for destinations E and D1. In the event of the node-		protection for destinations E and D1. In the event of the node-
	failure on primary nexthop E, the alternate path from Remote-LFA		failure on primary nexthop E, the alternate path from Remote-LFA
	nexthop R2 to E and D1 also becomes unavailable. So for a Remote-LFA		nexthop R2 to E and D1 also becomes unavailable. So for a Remote-LFA
	nexthop to provide node-protection for a given destination, it is		nexthop to provide node-protection for a given destination, it is
	mandatory that, the shortest path from the given PQ-node to the given		mandatory that, the shortest path from the given PQ-node to the given
	destination MUST not traverse the primary nexthop.		destination MUST NOT traverse the primary nexthop.
	In another extension of the topology in Figure 1 let us consider an		In another extension of the topology in Figure 1 let us consider an
	additional link between N and E with the same cost as the other		additional link between N and E with the same cost as the other
	links.		links.
	D1		D1
	/		/
	S-x-E		S-x-E
	/ / \		/ / \
	N---+ R3--D2		N---+ R3--D2
	skipping to change at page 5, line 47 ¶		skipping to change at page 5, line 47 ¶
	Again a closer look at Table 2 shows that, unlike Table 1, where the		Again a closer look at Table 2 shows that, unlike Table 1, where the
	single PQ-node R2 provided node-protection for destinations R3 and		single PQ-node R2 provided node-protection for destinations R3 and
	D2, if we choose R3 as the R-LFA nexthop, it does not provide node-		D2, if we choose R3 as the R-LFA nexthop, it does not provide node-
	protection for R3 and D2 anymore. If S chooses R3 as the R-LFA		protection for R3 and D2 anymore. If S chooses R3 as the R-LFA
	nexthop, in the event of the node-failure on primary nexthop E, on		nexthop, in the event of the node-failure on primary nexthop E, on
	the alternate path from S to R-LFA nexthop R3, one of parallel ECMP		the alternate path from S to R-LFA nexthop R3, one of parallel ECMP
	path between N and R3 also becomes unavailable. So for a Remote-LFA		path between N and R3 also becomes unavailable. So for a Remote-LFA
	nexthop to provide node-protection for a given destination, it is		nexthop to provide node-protection for a given destination, it is
	also mandatory that, the shortest path from S to the chosen PQ-node		also mandatory that, the shortest path from S to the chosen PQ-node
	MUST not traverse the primary nexthop node.		MUST NOT traverse the primary nexthop node.
	2.2. Additional Definitions		2.2. Additional Definitions
	This document adds and enhances the following definitions extending		This document adds and enhances the following definitions extending
	the ones mentioned in Remote-LFA [RFC7490] specification.		the ones mentioned in Remote-LFA [RFC7490] specification.
	2.2.1. Link-Protecting Extended P-Space		2.2.1. Link-Protecting Extended P-Space
	The Remote-LFA [RFC7490] specification already defines this. The		The Remote-LFA [RFC7490] specification already defines this. The
	link-protecting extended P-space for a link S-E being protected is		link-protecting extended P-space for a link S-E being protected is
	skipping to change at page 16, line 7 ¶		skipping to change at page 16, line 7 ¶
	7.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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-rtgwg-lfa-manageability]
	Litkowski, S., Decraene, B., Filsfils, C., Raza, K., and
	M. Horneffer, "Operational management of Loop Free
	Alternates", draft-ietf-rtgwg-lfa-manageability-11 (work
	in progress), June 2015.
	[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for		[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
	IP Fast Reroute: Loop-Free Alternates", RFC 5286,		IP Fast Reroute: Loop-Free Alternates", RFC 5286,
	DOI 10.17487/RFC5286, September 2008,		DOI 10.17487/RFC5286, September 2008,
	<http://www.rfc-editor.org/info/rfc5286>.		<http://www.rfc-editor.org/info/rfc5286>.
	[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.		[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
	So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",		So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
	RFC 7490, DOI 10.17487/RFC7490, April 2015,		RFC 7490, DOI 10.17487/RFC7490, April 2015,
	<http://www.rfc-editor.org/info/rfc7490>.		<http://www.rfc-editor.org/info/rfc7490>.
			[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K.,
			Horneffer, M., and P. Sarkar, "Operational Management of
			Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916,
			July 2016, <http://www.rfc-editor.org/info/rfc7916>.
	Authors' Addresses		Authors' Addresses
	Pushpasis Sarkar (editor)		Pushpasis Sarkar (editor)
	Individual Contributor		Individual Contributor
	Email: pushpasis.ietf@gmail.com		Email: pushpasis.ietf@gmail.com
	Shraddha Hegde		Shraddha Hegde
	Juniper Networks, Inc.		Juniper Networks, Inc.
	Electra, Exora Business Park		Electra, Exora Business Park
End of changes. 6 change blocks.
	17 lines changed or deleted		16 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/