< draft-psarkar-rtgwg-rlfa-node-protection-00.txt		draft-psarkar-rtgwg-rlfa-node-protection-01.txt >
	Routing Area Working Group P. Sarkar, Ed.		Routing Area Working Group P. Sarkar, Ed.
	Internet-Draft H. Gredler		Internet-Draft H. Gredler
	Intended status: Standards Track S. Hegde		Intended status: Standards Track S. Hegde
	Expires: January 10, 2014 H. Raghuveer		Expires: January 9, 2014 H. Raghuveer
	Juniper Networks, Inc.		Juniper Networks, Inc.
	July 09, 2013		July 8, 2013
	Node Protecting Remote-LFA and Manageability		Node Protecting R-LFA and Manageability
	draft-psarkar-rtgwg-rlfa-node-protection-00		draft-psarkar-rtgwg-rlfa-node-protection-01
	Abstract		Abstract
	The loop-free alternates computed following the current Remote-LFA		The loop-free alternates computed following the current Remote-LFA
	[I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link-		[I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link-
	protection. The resulting Remote-LFA nexthops (also called PQ-		protection. The resulting Remote-LFA nexthops (also called PQ-
	nodes), may not gaurantee node-protection for all destinations being		nodes), may not gaurantee node-protection for all destinations being
	protected by it.		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
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	Knowledge about the characteristics of all alternate path is		Knowledge about the characteristics of all alternate path is
	precursory to apply operator defined policy for eliminating paths not		precursory to apply operator defined policy for eliminating paths not
	fitting constraints.		fitting constraints.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	Status of This Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 January 10, 2014.		This Internet-Draft will expire on January 9, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 3		2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 4
	2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4		2.2. The Solution . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Manageabilty of Remote-LFA Alternate Paths . . . . . . . . . 6		3. Manageabilty of Remote-LFA Alternate Paths . . . . . . . . . . 8
	3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 7		3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Prior Solutions . . . . . . . . . . . . . . . . . . . . . . . 7		4. Prior Solutions . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Advantage of this Proposal . . . . . . . . . . . . . . . 7		4.1. Advantage of this Proposal . . . . . . . . . . . . . . . . 9
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] specification provides		The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] specification provides
	loop-free alternates that gaurantees only link-protection. The		loop-free alternates that gaurantees only link-protection. The
	resulting Remote-LFA alternate nexthops (also referred to as the PQ-		resulting Remote-LFA alternate nexthops (also referred to as the PQ-
	nodes) may not provide node-protection for all destinations covered		nodes) may not provide node-protection for all destinations covered
	by the same, in case of failure of the primary nexthop node. Neither		by the same, in case of failure of the primary nexthop node. Neither
	does the specification provide a means to determine the same.		does the specification provide a means to determine the same.
	skipping to change at page 3, line 13 ¶		skipping to change at page 4, line 26 ¶
	all possible Remote-LFA) alternate nexthops, collect the complete set		all possible Remote-LFA) alternate nexthops, collect the complete set
	of path characteristics for each alternate path, run a alternate-		of path characteristics for each alternate path, run a alternate-
	selection policy (configured by the operator), and find the best		selection policy (configured by the operator), and find the best
	alternate path. This will require the Remote-LFA implementation to		alternate path. This will require the Remote-LFA implementation to
	gather all the required path characteristics along each link on the		gather all the required path characteristics along each link on the
	entire Remote-LFA alternate path.		entire Remote-LFA alternate 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) first alternate path		of path attributes (e.g. SRLG, Admin-groups) first alternate path
	segment from the computing router PQ-node, there is no means for the		segment from the computing router PQ-node, there is no means for the
	computing router to gather any path attributes for the path segment		computing router to gather any path attributes for the path segment
	from the PQ-node to destination. Consecutively any policy-based		from the PQ-node to destination. Consecutively any policy-based
	selection of alternate paths will consider only the path attributes		selection of alternate paths will consider only the path attributes
	from the computing router up until the PQ-node.		from the computing router up until the PQ-node.
	This document describes a procedure for determining node-protection		This document describes a procedure for determining node-protection
	with Remote-LFA. The same procedure are also extended for collection		with Remote-LFA. The same procedure are also extended for collection
	of complete set of path attributes, enabling more accurate policy-		of complete set of path attributes, enabling more accurate policy-
	based selection for alternate paths obtained with Remote-LFA.		based selection for alternate paths obtained with Remote-LFA.
	2. Node Protection with Remote-LFA		2. Node Protection with Remote-LFA
	2.1. The Problem		2.1. The Problem
	To better illustrate the problem and the solution proposed in this		To better illustrate the problem and the solution proposed in this
	document the following topology diagram from the Remote-LFA		document the following topology diagram from the Remote-LFA
	[I-D.ietf-rtgwg-remote-lfa], draft is being re-used with slight		[I-D.ietf-rtgwg-remote-lfa], draft is being re-used with slight
	modification.		modification.
	F		F
	/		/
	S-x-E		S-x-E
	/ \		/ \
	A D--G		A D--G
	\ /		\ /
	B---C		B---C
	Figure 1: Sample Ring Topology		Figure 1: Sample Ring Topology
	In the above topology, for all (non-ECMP) destinations reachable via		In the above topology, for all (non-ECMP) destinations reachable via
	the S-E link there is no standard LFA alternate. As per the Remote-		the S-E link there is no standard LFA alternate. As per the Remote-
	LFA [I-D.ietf-rtgwg-remote-lfa] alternate specifications node C being		LFA [I-D.ietf-rtgwg-remote-lfa] alternate specifications node C being
	the PQ-node for the S-E link provides nexthop for all the above		the PQ-node for the S-E link provides nexthop for all the above
	destinations. Table 1 below, shows all possible primary and Remote-		destinations. Table 1 below, shows all possible primary and Remote-
	LFA alternate paths for each destination.		LFA alternate paths for each destination.
	skipping to change at page 5, line 16 ¶		skipping to change at page 6, line 20 ¶
	traversed on the shortest path(s) from a given root to others. In		traversed on the shortest path(s) from a given root to others. In
	such implementations, running a forward SPF rooted at a given PQ-node		such implementations, running a forward SPF rooted at a given PQ-node
	will produce a list of nodes (one per each destination), on one or		will produce a list of nodes (one per each destination), on one or
	more shortest path(s) from the PQ-node to other destinations in the		more shortest path(s) from the PQ-node to other destinations in the
	network. To determine whether a PQ-node provides node-protection for		network. To determine whether a PQ-node provides node-protection for
	a given destination or not, the list of nodes computed from forward		a given destination or not, the list of nodes computed from forward
	SPF run on the PQ-node, for the given destination, should be		SPF run on the PQ-node, for the given destination, should be
	inspected. In case the list contains the primary nexthop node, the		inspected. In case the list contains the primary nexthop node, the
	PQ-node does not provide node-protection. Else, the PQ-node		PQ-node does not provide node-protection. Else, the PQ-node
	guarantees node-protecting alternate for the given destination.		guarantees node-protecting alternate for the given destination.
	Below is an illustration of the mechanism with the topology in Figure		Below is an illustration of the mechanism with the topology in
	1.		Figure 1.
	+-----------+----------+------------+---------------+---------------+		+-----------+--------+------------+----------------+----------------+
	| Destinati | PQ-node | Shortest | Link- | Node- |		| Destinati | PQ-nod | Shortest | Link-Protectio | Node-Protectio |
	| on | | Path(PQ- | Protection | Protection |		| on | e | Path(PQ-no | n | n |
	| | | node to | | |		| | | de to | | |
	| | | Dest) | | |		| | | Dest) | | |
	+-----------+----------+------------+---------------+---------------+		+-----------+--------+------------+----------------+----------------+
	| D | C | C->D | Yes | Yes |		| D | C | C->D | Yes | Yes |
	| E | C | C->D->E | Yes | No |		| E | C | C->D->E | Yes | No |
	| F | C | C->D->E->F | Yes | No |		| F | C | C->D->E->F | Yes | No |
	| G | C | C->D->G | Yes | Yes |		| G | C | C->D->G | Yes | Yes |
	+-----------+----------+------------+---------------+---------------+		+-----------+--------+------------+----------------+----------------+
	Table 2: Types of protection with Remote-LFA		Table 2: Types of protection with Remote-LFA
	As seen in the above example while C is node-protecting Remote-LFA		As seen in the above example while C is node-protecting Remote-LFA
	nexthop for D and G, it is not so for E and F, since the primary		nexthop for D and G, it is not so for E and F, since the primary
	nexthop E is in the shortest path from C to E and F.		nexthop E is in the shortest path from C to E and F.
	Alternatively, an implementation may also run the node-protection		Alternatively, an implementation may also run the node-protection
	condition from the LFA [RFC5286] specification with slight		condition from the LFA [RFC5286] specification with slight
	modification as shown in Figure 2 below. PQ-nodes that does not		modification as shown in Figure 2 below. PQ-nodes that does not
	skipping to change at page 6, line 14 ¶		skipping to change at page 7, line 24 ¶
	All of the above metric costs except D_opt(Npq, Dst), can be obtained		All of the above metric costs except D_opt(Npq, Dst), can be obtained
	with forward and reverse SPFs with Np(the primary nexthop) as the		with forward and reverse SPFs with Np(the primary nexthop) as the
	root, run as part of the regular LFA and Remote-LFA implementation.		root, run as part of the regular LFA and Remote-LFA implementation.
	The Distance_opt(Npq, Dst) metric can only be determined by the		The Distance_opt(Npq, Dst) metric can only be determined by the
	additional forward SPF run with Npq(PQ-node) as the root. With		additional forward SPF run with Npq(PQ-node) as the root. With
	reference to the topology in Figure 1, Table 3 below shows how the		reference to the topology in Figure 1, Table 3 below shows how the
	above condition can be used to determine node-protection with a PQ-		above condition can be used to determine node-protection with a PQ-
	node.		node.
	+-----------+------------+---------+-------+------+------+----------+		+-----------+----------+--------+-------+-------+-------+-----------+
	| Destinati | Primary-NH | PQ-node | D_opt | D_op | D_op | Conditio |		| Destinati | Primary- | PQ-nod | D_opt | D_opt | D_opt | Condition |
	| on (Dst) | (Np) | (Npq) | (Npq, | t (N | t | n Met |		| on (Dst) | NH (Np) | e | (Npq, | (Npq, | (Np, | Met |
	| | | | Dst) | pq, | (Np, | |		| | | (Npq) | Dst) | Np) | Dst) | |
	| | | | | Np) | Dst) | |		+-----------+----------+--------+-------+-------+-------+-----------+
	+-----------+------------+---------+-------+------+------+----------+		| D | E | C | 1 | 1 | 1 | Yes |
	| D | E | C | 1 | 1 | 1 | Yes |		| E | E | C | 2 | 2 | 0 | No |
	| E | E | C | 2 | 2 | 0 | No |		| F | E | C | 3 | 2 | 1 | No |
	| F | E | C | 3 | 2 | 1 | No |		| G | E | C | 2 | 2 | 1 | Yes |
	| G | E | C | 2 | 2 | 1 | Yes |		+-----------+----------+--------+-------+-------+-------+-----------+
	+-----------+------------+---------+-------+------+------+----------+
	Table 3: Using Node-protecting condition for Remote-LFA		Table 3: Using Node-protecting condition for Remote-LFA
	As seen in the above example above, C does not meet the node-		As seen in the above example above, C does not meet the node-
	protecting inequality for destination E, and F. And so, once again,		protecting inequality for destination E, and F. And so, once again,
	while C is a node-protecting Remote-LFA nexthop for D and G, it is		while C is a node-protecting Remote-LFA nexthop for D and G, it is
	not so for E and F.		not so for E and F.
	The procedure described in this document helps no more than to		The procedure described in this document helps no more than to
	determine whether a given Remote-LFA alternate provides node-		determine whether a given Remote-LFA alternate provides node-
	skipping to change at page 8, line 23 ¶		skipping to change at page 9, line 34 ¶
	o Also the extra reverse SPF proposed per nextnexthop in Remote-LFA		o Also the extra reverse SPF proposed per nextnexthop in Remote-LFA
	node-protection [I-D.litkowski-rtgwg-node-protect-remote-lfa]		node-protection [I-D.litkowski-rtgwg-node-protect-remote-lfa]
	specification does not provide a means to collect the path		specification does not provide a means to collect the path
	characteristics for the alternate path segment from the PQ-node to		characteristics for the alternate path segment from the PQ-node to
	the destination. The additional forward SPF for each PQ-node, as		the destination. The additional forward SPF for each PQ-node, as
	proposed in this document facilitates the same.		proposed in this document facilitates the same.
	5. Acknowledgements		5. Acknowledgements
			Many thanks to Bruno Decraene and Stephane Litkowski for their useful
			comments.
	6. IANA Considerations		6. IANA Considerations
	N/A. - No protocol changes are proposed in this document.		N/A. - No protocol changes are proposed in this document.
	7. Security Considerations		7. Security Considerations
	This document does not introduce any change in any of the protocol		This document does not introduce any change in any of the protocol
	specifications. It simply proposes to run an extra SPF rooted on		specifications. It simply proposes to run an extra SPF rooted on
	each PQ-node discovered in the whole network.		each PQ-node discovered in the whole network.
	skipping to change at page 8, line 34 ¶		skipping to change at page 10, line 4 ¶
	N/A. - No protocol changes are proposed in this document.		N/A. - No protocol changes are proposed in this document.
	7. Security Considerations		7. Security Considerations
	This document does not introduce any change in any of the protocol		This document does not introduce any change in any of the protocol
	specifications. It simply proposes to run an extra SPF rooted on		specifications. It simply proposes to run an extra SPF rooted on
	each PQ-node discovered in the whole network.		each PQ-node discovered in the whole network.
	8. References		8. References
	8.1. Normative References		8.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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-rtgwg-lfa-manageability]		[I-D.ietf-rtgwg-lfa-manageability]
	Litkowski, S., Decraene, B., Filsfils, C., and K. Raza,		Litkowski, S., Decraene, B., Filsfils, C., and K. Raza,
	"Operational management of Loop Free Alternates", draft-		"Operational management of Loop Free Alternates",
	ietf-rtgwg-lfa-manageability-00 (work in progress), May		draft-ietf-rtgwg-lfa-manageability-00 (work in progress),
	2013.		May 2013.
	[I-D.ietf-rtgwg-remote-lfa]		[I-D.ietf-rtgwg-remote-lfa]
	Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.		Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
	Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02		Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02
	(work in progress), May 2013.		(work in progress), May 2013.
	[I-D.litkowski-rtgwg-node-protect-remote-lfa]		[I-D.litkowski-rtgwg-node-protect-remote-lfa]
	Litkowski, S., "Node protecting remote LFA", draft-		Litkowski, S., "Node protecting remote LFA",
	litkowski-rtgwg-node-protect-remote-lfa-00 (work in		draft-litkowski-rtgwg-node-protect-remote-lfa-00 (work in
	progress), April 2013.		progress), April 2013.
	[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast		[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
	Reroute: Loop-Free Alternates", RFC 5286, September 2008.		Reroute: Loop-Free Alternates", RFC 5286, September 2008.
	Authors' Addresses		Authors' Addresses
	Pushpasis Sarkar (editor)		Pushpasis Sarkar (editor)
	Juniper Networks, Inc.		Juniper Networks, Inc.
	Electra, Exora Business Park		Electra, Exora Business Park
End of changes. 15 change blocks.
	60 lines changed or deleted		61 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/