< draft-ietf-rtgwg-rlfa-node-protection-10.txt   draft-ietf-rtgwg-rlfa-node-protection-11.txt >
Routing Area Working Group P. Sarkar, Ed. Routing Area Working Group P. Sarkar, Ed.
Internet-Draft Individual Contributor Internet-Draft Individual Contributor
Intended status: Standards Track S. Hegde Intended status: Standards Track S. Hegde
Expires: July 3, 2017 C. Bowers Expires: July 24, 2017 C. Bowers
Juniper Networks, Inc. Juniper Networks, Inc.
H. Gredler H. Gredler
RtBrick, Inc. RtBrick, Inc.
S. Litkowski S. Litkowski
Orange Orange
December 30, 2016 January 20, 2017
Remote-LFA Node Protection and Manageability Remote-LFA Node Protection and Manageability
draft-ietf-rtgwg-rlfa-node-protection-10 draft-ietf-rtgwg-rlfa-node-protection-11
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 an extension to the Remote Loop-Free based IP This document describes an extension to the Remote Loop-Free based IP
fast reroute mechanisms described in [RFC7490], that describes fast reroute mechanisms described in [RFC7490], that describes
procedures for determining if a given PQ-node provides node- procedures for determining if a given PQ-node provides node-
protection for a specific destination or not. The document also protection for a specific destination or not. The document also
shows how the same procedure can be uitilized for collection of shows how the same procedure can be utilized for collection of
complete characteristics for alternate paths. Knowledge about the complete characteristics for alternate paths. Knowledge about the
characteristics of all alternate path is precursory to apply operator characteristics of all alternate path is precursory to apply operator
defined policy for eliminating paths not fitting constraints. defined policy for eliminating paths not 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].
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 July 3, 2017. This Internet-Draft will expire on July 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 3 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 4
2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Additional Definitions . . . . . . . . . . . . . . . . . 6 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 6
2.2.1. Link-Protecting Extended P-Space . . . . . . . . . . 6 2.2.1. Link-Protecting Extended P-Space . . . . . . . . . . 6
2.2.2. Node-Protecting Extended P-Space . . . . . . . . . . 6 2.2.2. Node-Protecting Extended P-Space . . . . . . . . . . 6
2.2.3. Q-Space . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Q-Space . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4. Link-Protecting PQ Space . . . . . . . . . . . . . . 6 2.2.4. Link-Protecting PQ Space . . . . . . . . . . . . . . 7
2.2.5. Candidate Node-Protecting PQ Space . . . . . . . . . 7 2.2.5. Candidate Node-Protecting PQ Space . . . . . . . . . 7
2.2.6. Cost-Based Definitions . . . . . . . . . . . . . . . 7 2.2.6. Cost-Based Definitions . . . . . . . . . . . . . . . 7
2.2.6.1. Link-Protecting Extended P-Space . . . . . . . . 7 2.2.6.1. Link-Protecting Extended P-Space . . . . . . . . 7
2.2.6.2. Node-Protecting Extended P-Space . . . . . . . . 7 2.2.6.2. Node-Protecting Extended P-Space . . . . . . . . 8
2.2.6.3. Q-Space . . . . . . . . . . . . . . . . . . . . . 8 2.2.6.3. Q-Space . . . . . . . . . . . . . . . . . . . . . 9
2.3. Computing Node-protecting R-LFA Path . . . . . . . . . . 9 2.3. Computing Node-protecting R-LFA Path . . . . . . . . . . 9
2.3.1. Computing Candidate Node-protecting PQ-Nodes for 2.3.1. Computing Candidate Node-protecting PQ-Nodes for
Primary nexthops . . . . . . . . . . . . . . . . . . 9 Primary nexthops . . . . . . . . . . . . . . . . . . 9
2.3.2. Computing node-protecting paths from PQ-nodes to 2.3.2. Computing node-protecting paths from PQ-nodes to
destinations . . . . . . . . . . . . . . . . . . . . 11 destinations . . . . . . . . . . . . . . . . . . . . 11
2.3.3. Computing Node-Protecting R-LFA Paths for 2.3.3. Computing Node-Protecting R-LFA Paths for
Destinations with ECMP primary nexthop nodes . . . . 13 Destinations with ECMP primary nexthop nodes . . . . 13
2.3.4. Limiting extra computational overhead . . . . . . . . 17 2.3.4. Limiting extra computational overhead . . . . . . . . 17
3. Manageability of Remote-LFA Alternate Paths . . . . . . . . . 18 3. Manageability of Remote-LFA Alternate Paths . . . . . . . . . 18
3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 18 3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 18 3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 19
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
skipping to change at page 3, line 47 skipping to change at page 3, line 47
attributes for the path segment from the PQ-node to destination. attributes for the path segment from the PQ-node to destination.
Consequently any policy-based selection of alternate paths will Consequently any policy-based selection of alternate paths will
consider only the path attributes from the computing router up until consider only the path attributes from the computing router up until
the PQ-node. 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 is 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.
1.1. Abbreviations
This document uses the following list of abbreviations.
LFA - Loop Free Alternates
RLFA or R-LFA - Remote Loop Free Alternates
ECMP - Equal Cost Multiple Path
SPF - Shortest Path First graph computations
NH - Next Hop node
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 required complex state synchronization between network, due to the required complex state synchronization between
redundant control plane hardwares it requires, and the significant redundant control plane hardwares it requires, and the significant
additional performance complexities it hence introduces. In such additional performance complexities it hence introduces. In such
cases node-protection is essential to guarantee un-interrupted flow cases node-protection is essential to guarantee un-interrupted flow
of traffic, even in the case of an entire forwarding node going down. of traffic, even in the case of an 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.
skipping to change at page 17, line 39 skipping to change at page 17, line 39
In addition to the extra reverse SPF computations suggested by the In addition to the extra reverse SPF computations suggested by the
Remote-LFA [RFC7490] draft (one reverse SPF for each of the directly Remote-LFA [RFC7490] draft (one reverse SPF for each of the directly
connected neighbors), this document proposes a forward SPF connected neighbors), this document proposes a forward SPF
computations for each PQ-node discovered in the network. Since the computations for each PQ-node discovered in the network. Since the
average number of PQ-nodes found in any network is considerably more average number of PQ-nodes found in any network is considerably more
than the number of direct neighbors of the computing router, the than the number of direct neighbors of the computing router, the
proposal of running one forward SPF per PQ-node may add considerably proposal of running one forward SPF per PQ-node may add considerably
to the overall SPF computation time. to the overall SPF computation time.
To limit the computational overhead of the approach proposed, this To limit the computational overhead of the approach proposed, this
document proposes that implementations MUST choose a subset from the document specifies that implementations MUST choose a subset from the
entire set of PQ-nodes computed in the network, with a finite limit entire set of PQ-nodes computed in the network, with a finite limit
on the number of PQ-nodes in the subset. Implementations MUST choose on the number of PQ-nodes in the subset. Implementations MUST choose
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. This document
MUST also evaluate some default preference criteria while considering suggests 16 as a default value for this limit. Implementations MUST
a PQ-node in this subset. Finally, implementations MAY also allow also evaluate some default preference criteria while considering a
the user to override the default preference criteria, by providing a PQ-node in this subset. The exact default preference criteria to be
policy configuration for the same. used is outside the scope of this document, and is a matter of
implementation. Finally, implementations MAY also allow the user to
override the default preference criteria, by providing a 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, its 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
skipping to change at page 19, line 8 skipping to change at page 19, line 16
The additional forward SPF computation proposed in Section 2.3.2 The additional forward SPF computation proposed in Section 2.3.2
document shall also collect links, nodes and path characteristics document shall also collect links, nodes and path characteristics
along the second path segment. This shall enable collection of along the second path segment. This shall enable collection of
complete path characteristics for a given Remote-LFA alternate path complete path characteristics for a given Remote-LFA alternate path
to a given destination. The complete alternate path characteristics to a given destination. The complete alternate path characteristics
shall then facilitate more accurate alternate path selection while shall then facilitate more accurate alternate path selection while
running the alternate selection policy. running the alternate selection policy.
As already specified in Section 2.3.4 to limit the computational As already specified in Section 2.3.4 to limit the computational
overhead of the proposed approach, forward SPF computations MUST be overhead of the proposed approach, forward SPF computations must be
run on a selected subset from the entire set of PQ-nodes computed in run on a selected subset from the entire set of PQ-nodes computed in
the network, with a finite limit on the number of PQ-nodes in the the network, with a finite limit on the number of PQ-nodes in the
subset. The detailed suggestion on how to select this subset is subset. The detailed suggestion on how to select this subset is
specified in the same section. While this limits the number of specified in the same section. While this limits the number of
possible alternate paths provided to the alternate-selection policy, possible alternate paths provided to the alternate-selection policy,
this is needed to keep the computational complexity within affordable this is needed to keep the computational complexity within affordable
limits. However if the alternate-selection policy is very limits. However if the alternate-selection policy is very
restrictive this may leave few destinations in the entire topology restrictive this may leave few destinations in the entire topology
without protection. Yet this limitation provides a necessary without protection. Yet this limitation provides a necessary
tradeoff between extensive coverage and immense computational tradeoff between extensive coverage and immense computational
 End of changes. 15 change blocks. 
21 lines changed or deleted 36 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/