< draft-ietf-rtgwg-rlfa-node-protection-03.txt		draft-ietf-rtgwg-rlfa-node-protection-04.txt >
	Routing Area Working Group P. Sarkar, Ed.		Routing Area Working Group P. Sarkar, Ed.
	Internet-Draft S. Hegde		Internet-Draft S. Hegde
	Intended status: Standards Track C. Bowers		Intended status: Standards Track C. Bowers
	Expires: April 8, 2016 Juniper Networks, Inc.		Expires: April 16, 2016 Juniper Networks, Inc.
	H. Gredler		H. Gredler
	Unaffiliated		Unaffiliated
	S. Litkowski		S. Litkowski
	Orange		Orange
	October 6, 2015		October 14, 2015
	Remote-LFA Node Protection and Manageability		Remote-LFA Node Protection and Manageability
	draft-ietf-rtgwg-rlfa-node-protection-03		draft-ietf-rtgwg-rlfa-node-protection-04
	Abstract		Abstract
	The loop-free alternates computed following the current Remote-LFA		The loop-free alternates computed following the current Remote-LFA
	[RFC7490] specification guarantees only link-protection. The		[RFC7490] specification guarantees only link-protection. The
	resulting Remote-LFA nexthops (also called PQ-nodes), may not		resulting Remote-LFA nexthops (also called PQ-nodes), may not
	guarantee node-protection for all destinations being protected by it.		guarantee node-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 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 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 April 8, 2016.		This Internet-Draft will expire on April 16, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	skipping to change at page 3, line 8 ¶		skipping to change at page 3, line 8 ¶
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7.1. Normative References . . . . . . . . . . . . . . . . . . 15		7.1. Normative References . . . . . . . . . . . . . . . . . . 15
	7.2. Informative References . . . . . . . . . . . . . . . . . 15		7.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The Remote-LFA [RFC7490] specification provides loop-free alternates		The Remote-LFA [RFC7490] specification provides loop-free alternates
	that guarantees 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 [I-D.ietf-rtgwg-lfa-manageability]
	document, requires a computing router to find all possible (including		document, requires a computing router to find all possible (including
	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
	skipping to change at page 3, line 34 ¶		skipping to change at page 3, line 34 ¶
	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.
	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 is also extended for collection
	of a complete set of path attributes, enabling more accurate policy-		of a 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
	Node-protection is required to provide protection of traffic on a		Node-protection is required to provide protection of traffic on a
	given forwarding node, against the failure of the first-hop node on		given forwarding node, against the failure of the first-hop node on
	the primary forwarding path. Such protection becomes more critical		the primary forwarding path. Such protection becomes more critical
	in the absence of mechanisms like non-stop-routing in the network.		in the absence of mechanisms like non-stop-routing in the network.
	Certain operators refrain from deploying non-stop-routing in their		Certain operators refrain from deploying non-stop-routing in their
	network, due to the significant additional performance complexities		network, due to the significant additional performance complexities
	it introduces. In such cases node-protection is a essential to		it introduces. In such cases node-protection is essential to
	guarantee un-interrupted flow of traffic, even in the case of an		guarantee un-interrupted flow of traffic, even in the case of an
	entire forwarding node going down.		entire forwarding node going down.
	The following sections discuss the node-protection problem in the		The following sections discuss the node-protection problem in the
	context of Remote-LFA and propose a solution.		context of Remote-LFA and propose a solution.
	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 [RFC7490]		document the following topology diagram from the Remote-LFA [RFC7490]
	skipping to change at page 9, line 36 ¶		skipping to change at page 9, line 36 ¶
	Table 3: Node-protection evaluation for R-LFA repair tunnel to PQ-		Table 3: Node-protection evaluation for R-LFA repair tunnel to PQ-
	node		node
	As seen in the above Table 3 , R3 does not meet the node-protecting		As seen in the above Table 3 , R3 does not meet the node-protecting
	extended-p-space inequality and so, while R2 is in candidate node-		extended-p-space inequality and so, while R2 is in candidate node-
	protecting PQ space, R3 is not.		protecting PQ space, R3 is not.
	Some SPF implementations may also produce a list of links and nodes		Some SPF implementations may also produce a list of links and nodes
	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, router S may have executed a forward SPF with		such implementations, router S may have executed a forward SPF with
	each of it's direct neighbors as the SPF root, executed as part of		each of its direct neighbors as the SPF root, executed as part of the
	the standard LFA [RFC5286] computations. So S may re-use the list of		standard LFA [RFC5286] computations. So S may re-use the list of
	links and nodes collected from the same SPF computations, to decide		links and nodes collected from the same SPF computations, to decide
	whether a node Y is a candidate node-protecting PQ-node or not. A		whether a node Y is a candidate node-protecting PQ-node or not. A
	node Y shall be considered as a node-protecting PQ-node, if and only		node Y shall be considered as a node-protecting PQ-node, if and only
	if, there is at least one direct neighbor of S, other than the		if, there is at least one direct neighbor of S, other than the
	primary nexthop E, for which, the primary nexthop node E does not		primary nexthop E, for which, the primary nexthop node E does not
	exist on the list of nodes traversed on any of the shortest path(s)		exist on the list of nodes traversed on any of the shortest path(s)
	from the direct neighbor to the PQ-node. Table 4 below is an		from the direct neighbor to the PQ-node. Table 4 below is an
	illustration of the mechanism with the topology in Figure 2.		illustration of the mechanism with the topology in Figure 2.
	+-----------+-------------------+-----------------+-----------------+		+-----------+-------------------+-----------------+-----------------+
	skipping to change at page 13, line 14 ¶		skipping to change at page 13, line 14 ¶
	a default value for this limit and may provide user with a		a default value for this limit and may provide user with a
	configuration knob to override the default limit. Implementations		configuration knob to override the default limit. Implementations
	MUST also evaluate some default preference criteria while considering		MUST also evaluate some default preference criteria while considering
	a PQ-node in this subset. Finally, implementations MAY also allow		a PQ-node in this subset. Finally, implementations MAY also allow
	user to override the default preference criteria, by providing a		user to override the default preference criteria, by providing a
	policy configuration for the same.		policy configuration for the same.
	This document proposes that implementations SHOULD use a default		This document proposes that implementations SHOULD use a default
	preference criteria for PQ-node selection which will put a score on		preference criteria for PQ-node selection which will put a score on
	each PQ-node, proportional to the number of primary interfaces for		each PQ-node, proportional to the number of primary interfaces for
	which it provides coverage, it's distance from the computing router,		which it provides coverage, its distance from the computing router,
	and its router-id (or system-id in case of IS-IS). PQ-nodes that		and its router-id (or system-id in case of IS-IS). PQ-nodes that
	cover more primary interfaces SHOULD be preferred over PQ-nodes that		cover more primary interfaces SHOULD be preferred over PQ-nodes that
	cover fewer primary interfaces. When two or more PQ-nodes cover the		cover fewer primary interfaces. When two or more PQ-nodes cover the
	same number of primary interfaces, PQ-nodes which are closer (based		same number of primary interfaces, PQ-nodes which are closer (based
	on metric) to the computing router SHOULD be preferred over PQ-nodes		on metric) to the computing router SHOULD be preferred over PQ-nodes
	farther away from it. For PQ-nodes that cover the same number of		farther away from it. For PQ-nodes that cover the same number of
	primary interfaces and are the same distance from the the computing		primary interfaces and are the same distance from the the computing
	router, the PQ-node with smaller router-id (or system-id in case of		router, the PQ-node with smaller router-id (or system-id in case of
	IS-IS) SHOULD be preferred.		IS-IS) SHOULD be preferred.
End of changes. 9 change blocks.
	10 lines changed or deleted		10 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/