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.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/