draft-ietf-rtgwg-rlfa-node-protection-13.txt | rfc8102.txt | |||
---|---|---|---|---|

Routing Area Working Group P. Sarkar, Ed. | Internet Engineering Task Force (IETF) P. Sarkar, Ed. | |||

Internet-Draft Individual Contributor | Request for Comments: 8102 Arrcus, Inc. | |||

Intended status: Standards Track S. Hegde | Category: Standards Track S. Hegde | |||

Expires: July 24, 2017 C. Bowers | ISSN: 2070-1721 C. Bowers | |||

Juniper Networks, Inc. | Juniper Networks, Inc. | |||

H. Gredler | H. Gredler | |||

RtBrick, Inc. | RtBrick, Inc. | |||

S. Litkowski | S. Litkowski | |||

Orange | Orange | |||

January 20, 2017 | March 2017 | |||

Remote-LFA Node Protection and Manageability | Remote-LFA Node Protection and Manageability | |||

draft-ietf-rtgwg-rlfa-node-protection-13 | ||||

Abstract | Abstract | |||

The loop-free alternates computed following the current Remote-LFA | The loop-free alternates (LFAs) computed following the current | |||

specification guarantees only link-protection. The resulting Remote- | remote-LFA specification guarantees only link protection. The | |||

LFA nexthops (also called PQ-nodes), may not guarantee node- | resulting remote-LFA next hops (also called "PQ-nodes") may not | |||

protection for all destinations being protected by it. | guarantee node protection for all destinations being protected by it. | |||

This document describes an extension to the Remote Loop-Free based IP | ||||

fast reroute mechanisms, that specifes procedures for determining if | ||||

a given PQ-node provides node-protection for a specific destination | ||||

or not. The document also shows how the same procedure can be | ||||

utilized for collection of complete characteristics for alternate | ||||

paths. Knowledge about the characteristics of all alternate path is | ||||

precursory to apply operator defined policy for eliminating paths not | ||||

fitting constraints. | ||||

Requirements Language | ||||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | This document describes an extension to the remote-loop-free-based IP | |||

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | fast reroute mechanisms that specifies procedures for determining | |||

document are to be interpreted as described in RFC2119 [RFC2119]. | whether or not a given PQ-node provides node protection for a | |||

specific destination. The document also shows how the same procedure | ||||

can be utilized for the collection of complete characteristics for | ||||

alternate paths. Knowledge about the characteristics of all | ||||

alternate paths is a precursor to applying the operator-defined | ||||

policy for eliminating paths not fitting the constraints. | ||||

Status of This Memo | Status of This Memo | |||

This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||

provisions of BCP 78 and BCP 79. | ||||

Internet-Drafts are working documents of the Internet Engineering | ||||

Task Force (IETF). Note that other groups may also distribute | ||||

working documents as Internet-Drafts. The list of current Internet- | ||||

Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||

Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||

and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||

time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||

material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||

Internet Standards is available in Section 2 of RFC 7841. | ||||

This Internet-Draft will expire on July 24, 2017. | Information about the current status of this document, any errata, | |||

and how to provide feedback on it may be obtained at | ||||

http://www.rfc-editor.org/info/rfc8102. | ||||

Copyright Notice | Copyright Notice | |||

Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 | |||

2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 4 | 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 | |||

2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 5 | |||

2.2. Additional Definitions . . . . . . . . . . . . . . . . . 6 | 2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 5 | |||

2.2.1. Link-Protecting Extended P-Space . . . . . . . . . . 6 | 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 7 | |||

2.2.2. Node-Protecting Extended P-Space . . . . . . . . . . 6 | 2.2.1. Link-Protecting Extended P-Space . . . . . . . . . . 7 | |||

2.2.3. Q-Space . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2.2. Node-Protecting Extended P-Space . . . . . . . . . . 7 | |||

2.2.4. Link-Protecting PQ Space . . . . . . . . . . . . . . 7 | 2.2.3. Q-Space . . . . . . . . . . . . . . . . . . . . . . . 8 | |||

2.2.5. Candidate Node-Protecting PQ Space . . . . . . . . . 7 | 2.2.4. Link-Protecting PQ-Space . . . . . . . . . . . . . . 8 | |||

2.2.6. Cost-Based Definitions . . . . . . . . . . . . . . . 7 | 2.2.5. Candidate Node-Protecting PQ-Space . . . . . . . . . 8 | |||

2.2.6.1. Link-Protecting Extended P-Space . . . . . . . . 7 | 2.2.6. Cost-Based Definitions . . . . . . . . . . . . . . . 8 | |||

2.2.6.2. Node-Protecting Extended P-Space . . . . . . . . 8 | 2.2.6.1. Link-Protecting Extended P-Space . . . . . . . . 9 | |||

2.2.6.3. Q-Space . . . . . . . . . . . . . . . . . . . . . 9 | 2.2.6.2. Node-Protecting Extended P-Space . . . . . . . . 9 | |||

2.3. Computing Node-protecting R-LFA Path . . . . . . . . . . 9 | 2.2.6.3. Q-Space . . . . . . . . . . . . . . . . . . . . . 10 | |||

2.3.1. Computing Candidate Node-protecting PQ-Nodes for | 2.3. Computing Node-Protecting R-LFA Path . . . . . . . . . . 10 | |||

Primary nexthops . . . . . . . . . . . . . . . . . . 9 | 2.3.1. Computing Candidate Node-Protecting PQ-Nodes for | |||

2.3.2. Computing node-protecting paths from PQ-nodes to | Primary Next Hops . . . . . . . . . . . . . . . . . . 10 | |||

destinations . . . . . . . . . . . . . . . . . . . . 11 | 2.3.2. Computing Node-Protecting Paths from PQ-Nodes to | |||

Destinations . . . . . . . . . . . . . . . . . . . . 12 | ||||

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 Multiple Primary Next-Hop Nodes . . 14 | |||

2.3.4. Limiting extra computational overhead . . . . . . . . 17 | 2.3.4. Limiting Extra Computational Overhead . . . . . . . . 18 | |||

3. Manageability of Remote-LFA Alternate Paths . . . . . . . . . 18 | 3. Manageability of Remote-LFA Alternate Paths . . . . . . . . . 19 | |||

3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 18 | 3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 19 | |||

3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 19 | 3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 20 | |||

4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||

5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||

6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||

7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 21 | |||

7.1. Normative References . . . . . . . . . . . . . . . . . . 20 | 6.2. Informative References . . . . . . . . . . . . . . . . . 21 | |||

7.2. Informative References . . . . . . . . . . . . . . . . . 20 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 | |||

1. Introduction | 1. Introduction | |||

The Remote-LFA [RFC7490] specification provides loop-free alternates | The Remote-LFA specification [RFC7490] 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 next hops (also referred to as the "PQ-nodes") may not | |||

node-protection for all destinations covered by the same Remote-LFA | provide node protection for all destinations covered by the same | |||

alternate, in case of failure of the primary nexthop node. Neither | remote-LFA alternate, in case of failure of the primary next-hop | |||

does the specification provide a means to determine the same. | node, and it does not provide a means to determine the same. | |||

Also, the LFA Manageability [RFC7916] document requires a computing | Also, the LFA Manageability document [RFC7916] requires a computing | |||

router to find all possible (including all possible Remote-LFA) | router to find all possible alternate next hops (including all | |||

alternate nexthops, collect the complete set of path characteristics | possible remote-LFA), collect the complete set of path | |||

for each alternate path, run an alternate-selection policy | characteristics for each alternate path, run an alternate-selection | |||

(configured by the operator) and find the best alternate path. This | policy (configured by the operator), and find the best alternate | |||

will require the Remote-LFA implementation to gather all the required | path. This will require that the remote-LFA implementation gathers | |||

path characteristics along each link on the entire Remote-LFA | all the required path characteristics along each link on the entire | |||

alternate path. | 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 with the computing router and | forward SPF (and reverse SPF) is run with the computing router and | |||

its immediate 1-hop routers as the roots. While that enables | its immediate one-hop routers as the roots. While that enables | |||

computation of path attributes (e.g. SRLG, Admin-groups) for first | computation of path attributes (e.g., Shared Risk Link Group (SRLG) | |||

alternate path segment from the computing router to the PQ-node, | and Admin-groups) for the first alternate path segment from the | |||

there is no means for the computing router to gather any path | computing router to the PQ-node, there is no means for the computing | |||

attributes for the path segment from the PQ-node to destination. | router to gather any path attributes for the path segment from the | |||

Consequently any policy-based selection of alternate paths will | PQ-node to the destination. Consequently, any policy-based selection | |||

consider only the path attributes from the computing router up until | of alternate paths will consider only the path attributes from the | |||

the PQ-node. | 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 is also extended for collection | with remote-LFA. The same procedure is also extended for the | |||

of a complete set of path attributes, enabling more accurate policy- | collection of a complete set of path attributes, enabling more | |||

based selection for alternate paths obtained with Remote-LFA. | accurate policy-based selection for alternate paths obtained with | |||

remote-LFA. | ||||

1.1. Abbreviations | 1.1. Abbreviations | |||

This document uses the following list of abbreviations. | This document uses the following list of abbreviations: | |||

LFA - Loop Free Alternates | LFA: Loop-Free Alternates | |||

RLFA or R-LFA - Remote Loop Free Alternates | ||||

ECMP - Equal Cost Multiple Path | RLFA or R-LFA: Remote Loop-Free Alternates | |||

SPF - Shortest Path First graph computations | ECMP: Equal-Cost Multiple Path | |||

NH - Next Hop node | SPF: Shortest Path First graph computations | |||

NH: Next-Hop node | ||||

1.2. Requirements Language | ||||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||

document are to be interpreted as described in RFC 2119 [RFC2119]. | ||||

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 computation and performance overheads it comes along with. | |||

cases node-protection is essential to guarantee un-interrupted flow | In such cases, node protection is essential to guarantee | |||

of traffic, even in the case of an entire forwarding node going down. | uninterrupted flow 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. | |||

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 document | |||

draft is being re-used with slight modification. | [RFC7490] is being re-used with slight modification. | |||

D1 | D1 | |||

/ | / | |||

S-x-E | S-x-E | |||

/ \ | / \ | |||

N R3--D2 | N R3--D2 | |||

\ / | \ / | |||

R1---R2 | R1---R2 | |||

Figure 1: Topology 1 | Figure 1: Topology 1 | |||

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 [RFC7490] alternate specifications node R2 being the only PQ-node | LFA [RFC7490] alternate specifications, node R2 being the only PQ- | |||

for the S-E link provides nexthop for all the above destinations. | node for the S-E link provides the next hop for all of the above | |||

Table 1 below, shows all possible primary and Remote-LFA alternate | destinations. Table 1 shows all possible primary and remote-LFA | |||

paths for each destination. | alternate paths for each destination. | |||

+-------------+--------------+---------+-------------------------+ | +-------------+--------------+---------+-------------------------+ | |||

| Destination | Primary Path | PQ-node | Remote-LFA Backup Path | | | Destination | Primary Path | PQ-node | Remote-LFA Backup Path | | |||

+-------------+--------------+---------+-------------------------+ | +-------------+--------------+---------+-------------------------+ | |||

| R3 | S->E->R3 | R2 | S=>N=>R1=>R2->R3 | | | R3 | S->E->R3 | R2 | S=>N=>R1=>R2->R3 | | |||

| E | S->E | R2 | S=>N=>R1=>R2->R3->E | | | E | S->E | R2 | S=>N=>R1=>R2->R3->E | | |||

| D1 | S->E->D1 | R2 | S=>N=>R1=>R2->R3->E->D1 | | | D1 | S->E->D1 | R2 | S=>N=>R1=>R2->R3->E->D1 | | |||

| D2 | S->E->R3->D2 | R2 | S=>N=>R1=>R2->R3->D2 | | | D2 | S->E->R3->D2 | R2 | S=>N=>R1=>R2->R3->D2 | | |||

+-------------+--------------+---------+-------------------------+ | +-------------+--------------+---------+-------------------------+ | |||

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 next hop E, the alternate path from the remote-LFA | |||

nexthop R2 to E and D1 also becomes unavailable. So for a Remote-LFA | next hop R2 to E and D1 also becomes unavailable. So, for a remote- | |||

nexthop to provide node-protection for a given destination, it is | LFA next hop to provide node protection for a given destination, the | |||

mandatory that, the shortest path from the given PQ-node to the given | shortest path from the given PQ-node to the given destination MUST | |||

destination MUST NOT traverse the primary nexthop. | NOT traverse the primary next hop. | |||

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 | |||

\ / | \ / | |||

R1---R2 | R1---R2 | |||

Figure 2: Topology 2 | Figure 2: Topology 2 | |||

In the above topology, the S-E link is no more on any of the shortest | In the above topology, the S-E link is no longer on any of the | |||

paths from N to R3, E and D1. Hence R3, E and D1 are also included | shortest paths from N to R3, E, and D1. Hence, R3, E, and D1 are | |||

in both the Extended-P space and Q space of E (w.r.t S-E link). | also included in both the extended P-space and the Q-space of E (with | |||

Table 2 below, shows all possible primary and R-LFA alternate paths | respect to the S-E link). Table 2 shows all possible primary and | |||

via PQ-node R3, for each destination reachable through the S-E link | R-LFA alternate paths via PQ-node R3 for each destination reachable | |||

in the above topology. The R-LFA alternate paths via PQ-node R2 | through the S-E link in the above topology. The R-LFA alternate | |||

remains same as in Table 1. | paths via PQ-node R2 remain the same as in Table 1. | |||

+-------------+--------------+---------+------------------------+ | +-------------+--------------+---------+------------------------+ | |||

| Destination | Primary Path | PQ-node | Remote-LFA Backup Path | | | Destination | Primary Path | PQ-node | Remote-LFA Backup Path | | |||

+-------------+--------------+---------+------------------------+ | +-------------+--------------+---------+------------------------+ | |||

| R3 | S->E->R3 | R3 | S=>N=>E=>R3 | | | R3 | S->E->R3 | R3 | S=>N=>E=>R3 | | |||

| E | S->E | R3 | S=>N=>E=>R3->E | | | E | S->E | R3 | S=>N=>E=>R3->E | | |||

| D1 | S->E->D1 | R3 | S=>N=>E=>R3->E->D1 | | | D1 | S->E->D1 | R3 | S=>N=>E=>R3->E->D1 | | |||

| D2 | S->E->R3->D2 | R3 | S=>N=>E=>R3->D2 | | | D2 | S->E->R3->D2 | R3 | S=>N=>E=>R3->D2 | | |||

+-------------+--------------+---------+------------------------+ | +-------------+--------------+---------+------------------------+ | |||

Table 2: Remote-LFA backup paths via PQ-node R3 | Table 2: Remote-LFA Backup Paths via PQ-Node R3 | |||

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 next hop, it no longer provides node | |||

protection for R3 and D2 anymore. If S chooses R3 as the R-LFA | protection for R3 and D2. If S chooses R3 as the R-LFA next hop and | |||

nexthop, in the event of the node-failure on primary nexthop E, on | if there is a node-failure on primary next hop E, then one of the | |||

the alternate path from S to R-LFA nexthop R3, one of parallel ECMP | parallel ECMP paths between N and R3 also becomes unavailable on the | |||

path between N and R3 also becomes unavailable. So for a Remote-LFA | alternate path from S to R-LFA next hop R3. So, for a remote-LFA | |||

nexthop to provide node-protection for a given destination, it is | next hop to provide node protection for a given destination, the | |||

also mandatory that, the shortest paths from S to the chosen PQ-node | shortest paths from S to the chosen PQ-node MUST NOT traverse the | |||

MUST NOT traverse the primary nexthop node. | primary next-hop 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 the Remote-LFA specification [RFC7490]. | |||

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 specification [RFC7490] 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 | |||

the set of routers that are reachable from one or more direct | the set of routers that are reachable from one or more direct | |||

neighbors of S, except primary node E, without traversing the S-E | neighbors of S, except primary node E, without traversing the S-E | |||

link on any of the shortest paths from the direct neighbor to the | link on any of the shortest paths from the direct neighbor to the | |||

router. This MUST exclude any direct neighbor for which there is at | router. This MUST exclude any direct neighbor for which there is at | |||

least one ECMP path from the direct neighbor traversing the link(S-E) | least one ECMP path from the direct neighbor traversing the link | |||

being protected. | (S-E) being protected. | |||

For a cost-based definition for Link-protecting Extended P-Space | For a cost-based definition for link-protecting extended P-space, | |||

refer to Section 2.2.6.1. | refer to Section 2.2.6.1. | |||

2.2.2. Node-Protecting Extended P-Space | 2.2.2. Node-Protecting Extended P-Space | |||

The node-protecting extended P-space for a primary nexthop node E | The node-protecting extended P-space for a primary next-hop node E | |||

being protected, is the set of routers that are reachable from one or | being protected is the set of routers that are reachable from one or | |||

more direct neighbors of S, except primary node E, without traversing | more direct neighbors of S, except primary node E, without traversing | |||

the node E. This MUST exclude any direct neighbors for which there | node E. This MUST exclude any direct neighbors for which there is at | |||

is at least one ECMP path from the direct neighbor traversing the | least one ECMP path from the direct neighbor traversing the node E | |||

node E being protected. | being protected. | |||

For a cost-based definition for Node-protecting Extended P-Space | For a cost-based definition for node-protecting extended P-space, | |||

refer to Section 2.2.6.2. | refer to Section 2.2.6.2. | |||

2.2.3. Q-Space | 2.2.3. Q-Space | |||

The Remote-LFA [RFC7490] draft already defines this. The Q-space for | The Remote-LFA document [RFC7490] already defines this. The Q-space | |||

a link S-E being protected is the set of nodes that can reach primary | for a link S-E being protected is the set of nodes that can reach | |||

node E, without traversing the S-E link on any of the shortest paths | primary node E, without traversing the S-E link on any of the | |||

from the node itself to primary nexthop E. This MUST exclude any | shortest paths from the node itself to primary next hop E. This MUST | |||

node for which there is at least one ECMP path from the node to the | exclude any node for which there is at least one ECMP path from the | |||

primary nexthop E traversing the link(S-E) being protected. | node to the primary next hop E traversing the link (S-E) being | |||

protected. | ||||

For a cost-based definition for Q-Space refer to Section 2.2.6.3. | For a cost-based definition for Q-Space, refer to Section 2.2.6.3. | |||

2.2.4. Link-Protecting PQ Space | 2.2.4. Link-Protecting PQ-Space | |||

A node Y is in link-protecting PQ space w.r.t the link (S-E) being | A node Y is in a link-protecting PQ-space with respect to the link | |||

protected, if and only if, Y is present in both link-protecting | (S-E) being protected if and only if Y is present in both link- | |||

extended P-space and the Q-space for the link being protected. | protecting extended P-space and the Q-space for the link being | |||

protected. | ||||

2.2.5. Candidate Node-Protecting PQ Space | 2.2.5. Candidate Node-Protecting PQ-Space | |||

A node Y is in candidate node-protecting PQ space w.r.t the node (E) | A node Y is in a candidate node-protecting PQ-space with respect to | |||

being protected, if and only if, Y is present in both node-protecting | the node (E) being protected if and only if Y is present in both the | |||

extended P-space and the Q-space for the link being protected. | node-protecting extended P-space and the Q-space for the link being | |||

protected. | ||||

Please note, that a node Y being in candidate node-protecting PQ- | Please note that a node Y being in a candidate node-protecting PQ- | |||

space, does not guarantee that the R-LFA alternate path via the same, | space does not guarantee that the R-LFA alternate path via the same, | |||

in entirety, is unaffected in the event of a node failure of primary | in entirety, is unaffected in the event of a node failure of primary | |||

nexthop node E. It only guarantees that the path segment from S to | next-hop node E. It only guarantees that the path segment from S to | |||

PQ-node Y is unaffected by the same failure event. The PQ-nodes in | PQ-node Y is unaffected by the same failure event. The PQ-nodes in | |||

the candidate node-protecting PQ space may provide node protection | the candidate node-protecting PQ-space may provide node protection | |||

for only a subset of destinations that are reachable through the | for only a subset of destinations that are reachable through the | |||

corresponding primary link. | corresponding primary link. | |||

2.2.6. Cost-Based Definitions | 2.2.6. Cost-Based Definitions | |||

This section provides cost-based definitions for some of the terms | This section provides cost-based definitions for some of the terms | |||

introduced in Section 2.2 of this document. | introduced in Section 2.2 of this document. | |||

2.2.6.1. Link-Protecting Extended P-Space | 2.2.6.1. Link-Protecting Extended P-Space | |||

Please refer to Section 2.2.1 for a formal definition for Link- | Please refer to Section 2.2.1 for a formal definition of link- | |||

protecting Extended P-Space. | protecting extended P-space. | |||

A node Y is in link-protecting extended P-space w.r.t the link (S-E) | A node Y is in a link-protecting extended P-space with respect to the | |||

being protected, if and only if, there exists at least one direct | link (S-E) being protected if and only if there exists at least one | |||

neighbor of S, Ni, other than primary nexthop E, that satisfies the | direct neighbor of S (Ni) other than primary next hop E that | |||

following condition. | satisfies the following condition. | |||

D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y) | D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y) | |||

Where, | Where, | |||

D_opt(A,B) : Distance on most optimum path from A to B. | D_opt(A,B) : Distance on the most optimum path from A to B. | |||

Ni : A direct neighbor of S other than primary | Ni : A direct neighbor of S other than primary | |||

nexthop E. | next hop E. | |||

Y : The node being evaluated for link-protecting | Y : The node being evaluated for link-protecting | |||

extended P-Space. | extended P-Space. | |||

Figure 3: Link-Protecting Ext-P-Space Condition | Figure 3: Link-Protecting Ext-P-Space Condition | |||

2.2.6.2. Node-Protecting Extended P-Space | 2.2.6.2. Node-Protecting Extended P-Space | |||

Please refer to Section 2.2.2 for a formal definition for Node- | Please refer to Section 2.2.2 for a formal definition of node- | |||

protecting Extended P-Space. | protecting extended P-space. | |||

A node Y is in node-protecting extended P-space w.r.t the node E | A node Y is in a node-protecting extended P-space with respect to the | |||

being protected, if and only if, there exists at least one direct | node E being protected if and only if there exists at least one | |||

neighbor of S, Ni, other than primary nexthop E, that satisfies the | direct neighbor of S (Ni) other than primary next hop E, that | |||

following condition. | satisfies the following condition. | |||

D_opt(Ni,Y) < D_opt(Ni,E) + D_opt(E,Y) | D_opt(Ni,Y) < D_opt(Ni,E) + D_opt(E,Y) | |||

Where, | Where, | |||

D_opt(A,B) : Distance on most optimum path from A to B. | D_opt(A,B) : Distance on the most optimum path from A to B. | |||

E : The primary nexthop on shortest path from S | E : The primary next hop on the shortest path from S | |||

to destination. | to destination. | |||

Ni : A direct neighbor of S other than primary | Ni : A direct neighbor of S other than primary | |||

nexthop E. | next hop E. | |||

Y : The node being evaluated for node-protecting | Y : The node being evaluated for node-protecting | |||

extended P-Space. | extended P-Space. | |||

Figure 4: Node-Protecting Ext-P-Space Condition | Figure 4: Node-Protecting Ext-P-Space Condition | |||

Please note, that a node Y satisfying the condition in Figure 4 above | Please note that a node Y satisfying the condition in Figure 4 above | |||

only guarantees that the R-LFA alternate path segment from S via | only guarantees that the R-LFA alternate path segment from S via | |||

direct neighbor Ni to the node Y is not affected in the event of a | direct neighbor Ni to the node Y is not affected in the event of a | |||

node failure of E. It does not yet guarantee that the path segment | node failure of E. It does not yet guarantee that the path segment | |||

from node Y to the destination is also unaffected by the same failure | from node Y to the destination is also unaffected by the same failure | |||

event. | event. | |||

2.2.6.3. Q-Space | 2.2.6.3. Q-Space | |||

Please refer to Section 2.2.3 for a formal definition for Q-Space. | Please refer to Section 2.2.3 for a formal definition of Q-Space. | |||

A node Y is in Q-space w.r.t the link (S-E) being protected, if and | A node Y is in Q-space with respect to the link (S-E) being protected | |||

only if, the following condition is satisfied. | if and only if the following condition is satisfied: | |||

D_opt(Y,E) < D_opt(S,E) + D_opt(Y,S) | D_opt(Y,E) < D_opt(S,E) + D_opt(Y,S) | |||

Where, | Where, | |||

D_opt(A,B) : Distance on most optimum path from A to B. | D_opt(A,B) : Distance on the most optimum path from A to B. | |||

E : The primary nexthop on shortest path from S | E : The primary next hop on the shortest path from S | |||

to destination. | to destination. | |||

Y : The node being evaluated for Q-Space. | Y : The node being evaluated for Q-Space. | |||

Figure 5: Q-Space Condition | Figure 5: Q-Space Condition | |||

2.3. Computing Node-protecting R-LFA Path | 2.3. Computing Node-Protecting R-LFA Path | |||

The R-LFA alternate path through a given PQ-node to a given | The R-LFA alternate path through a given PQ-node to a given | |||

destination is comprised of two path segments as follows. | destination is comprised of two path segments as follows: | |||

1. Path segment from the computing router to the PQ-node (Remote-LFA | 1. Path segment from the computing router to the PQ-node (Remote-LFA | |||

alternate nexthop), and | alternate next hop), and | |||

2. Path segment from the PQ-node to the destination being protected. | 2. Path segment from the PQ-node to the destination being protected. | |||

So to ensure a R-LFA alternate path for a given destination provides | So, to ensure that an R-LFA alternate path for a given destination | |||

node-protection we need to ensure that none of the above path | provides node protection, we need to ensure that none of the above | |||

segments are affected in the event of failure of the primary nexthop | path segments are affected in the event of failure of the primary | |||

node. Sections Section 2.3.1 and Section 2.3.2 show how this can be | next-hop node. Sections 2.3.1 and 2.3.2 show how this can be | |||

ensured. | ensured. | |||

2.3.1. Computing Candidate Node-protecting PQ-Nodes for Primary | 2.3.1. Computing Candidate Node-Protecting PQ-Nodes for Primary Next | |||

nexthops | Hops | |||

To choose a node-protecting R-LFA nexthop for a destination R3, | To choose a node-protecting R-LFA next hop for a destination R3, | |||

router S needs to consider a PQ-node from the candidate node- | router S needs to consider a PQ-node from the candidate node- | |||

protecting PQ-space for the primary nexthop E on shortest path from S | protecting PQ-space for the primary next hop E on the shortest path | |||

to R3. As mentioned in Section 2.2.2, to consider a PQ-node as | from S to R3. As mentioned in Section 2.2.2, to consider a PQ-node | |||

candidate node-protecting PQ-node, there must be at least one direct | as a candidate node-protecting PQ-node, there must be at least one | |||

neighbor Ni of S, such that all shortest paths from Ni to the PQ-node | direct neighbor Ni of S, such that all shortest paths from Ni to the | |||

does not traverse primary nexthop node E. | PQ-node do not traverse primary next-hop node E. | |||

Implementations SHOULD run the inequality in Section 2.2.2 Figure 4 | ||||

for all direct neighbors, other than primary nexthop node E, to | ||||

determine whether a node Y is a candidate node-protecting PQ-node. | ||||

All of the metrics needed by this inequality would have been already | Implementations SHOULD run the inequality in Section 2.2.6.2, | |||

collected from the forward SPFs rooted at each of direct neighbor S, | Figure 4 for all direct neighbors, other than primary next-hop node | |||

computed as part of standard LFA [RFC5286] implementation. With | E, to determine whether a node Y is a candidate node-protecting PQ- | |||

reference to the topology in Figure 2, Table 3 below shows how the | node. All of the metrics needed by this inequality would have been | |||

above condition can be used to determine the candidate node- | already collected from the forward SPFs rooted at each of direct | |||

protecting PQ-space for S-E link (primary nexthop E). | neighbor S, computed as part of standard LFA [RFC5286] | |||

implementation. With reference to the topology in Figure 2, Table 3 | ||||

shows how the above condition can be used to determine the candidate | ||||

node-protecting PQ-space for S-E link (primary next hop E). | ||||

+------------+----------+----------+----------+---------+-----------+ | +------------+----------+----------+----------+---------+-----------+ | |||

| Candidate | Direct | D_opt | D_opt | D_opt | Condition | | | Candidate | Direct | D_opt | D_opt | D_opt | Condition | | |||

| PQ-node | Nbr (Ni) | (Ni,Y) | (Ni,E) | (E,Y) | Met | | | PQ-node | Nbr (Ni) | (Ni,Y) | (Ni,E) | (E,Y) | Met | | |||

| (Y) | | | | | | | | (Y) | | | | | | | |||

+------------+----------+----------+----------+---------+-----------+ | +------------+----------+----------+----------+---------+-----------+ | |||

| R2 | N | 2 (N,R2) | 1 (N,E) | 2 | Yes | | | R2 | N | 2 (N,R2) | 1 (N,E) | 2 | Yes | | |||

| | | | | (E,R2) | | | | | | | | (E,R2) | | | |||

| R3 | N | 2 (N,R3) | 1 (N,E) | 1 | No | | | R3 | N | 2 (N,R3) | 1 (N,E) | 1 | No | | |||

| | | | | (E,R3) | | | | | | | | (E,R3) | | | |||

+------------+----------+----------+----------+---------+-----------+ | +------------+----------+----------+----------+---------+-----------+ | |||

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; 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 its direct neighbors as the SPF root, executed as part of the | each of its direct neighbors as the SPF root, executed as part of the | |||

standard LFA [RFC5286] computations. So S may re-use the list of | standard LFA computations [RFC5286]. 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 or not a node Y is a candidate node-protecting PQ-node. 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 | |||

primary nexthop E, for which, the primary nexthop node E does not | next hop E for which the primary next-hop node E does not exist on | |||

exist on the list of nodes traversed on any of the shortest paths | the list of nodes traversed on any of the shortest paths from the | |||

from the direct neighbor to the PQ-node. Table 4 below is an | direct neighbor to the PQ-node. Table 4 is an illustration of the | |||

illustration of the mechanism with the topology in Figure 2. | mechanism with the topology in Figure 2. | |||

+-----------+-------------------+-----------------+-----------------+ | +-------------+---------------------------+------------+------------+ | |||

| Candidate | Repair Tunnel | Link-Protection | Node-Protection | | | Candidate | Repair Tunnel Path | Link | Node | | |||

| PQ-node | Path(Repairing | | | | | PQ-node | (Repairing router to PQ- | Protection | Protection | | |||

| | router to PQ- | | | | | | node) | | | | |||

| | node) | | | | +-------------+---------------------------+------------+------------+ | |||

+-----------+-------------------+-----------------+-----------------+ | | R2 | S->N->R1->R2 | Yes | Yes | | |||

| R2 | S->N->R1->R2 | Yes | Yes | | | R2 | S->E->R3->R2 | No | No | | |||

| R2 | S->E->R3->R2 | No | No | | | R3 | S->N->E->R3 | Yes | No | | |||

| R3 | S->N->E->R3 | Yes | No | | +-------------+---------------------------+------------+------------+ | |||

+-----------+-------------------+-----------------+-----------------+ | ||||

Table 4: Protection of Remote-LFA tunnel to the PQ-node | Table 4: Protection of Remote-LFA Tunnel to the PQ-Node | |||

As seen in the above Table 4 while R2 is candidate node-protecting | As seen in the above Table 4, while R2 is a candidate node-protecting | |||

Remote-LFA nexthop for R3 and D2, it is not so for E and D1, since | remote-LFA next hop for R3 and D2, it is not so for E and D1, since | |||

the primary nexthop E is in the shortest path from R2 to E and D1. | the primary next hop E is on the shortest path from R2 to E and D1. | |||

2.3.2. Computing node-protecting paths from PQ-nodes to destinations | 2.3.2. Computing Node-Protecting Paths from PQ-Nodes to Destinations | |||

Once a computing router finds all the candidate node-protecting PQ- | Once a computing router finds all the candidate node-protecting PQ- | |||

nodes for a given directly attached primary link, it shall follow the | nodes for a given directly attached primary link, it shall follow the | |||

procedure as proposed in this section, to choose one or more node- | procedure as proposed in this section to choose one or more node- | |||

protecting R-LFA paths, for destinations reachable through the same | protecting R-LFA paths for destinations reachable through the same | |||

primary link in the primary SPF graph. | primary link in the primary SPF graph. | |||

To find a node-protecting R-LFA path for a given destination, the | To find a node-protecting R-LFA path for a given destination, the | |||

computing router needs to pick a subset of PQ-nodes from the | computing router needs to pick a subset of PQ-nodes from the | |||

candidate node-protecting PQ-space for the corresponding primary | candidate node-protecting PQ-space for the corresponding primary next | |||

nexthop, such that all the path(s) from the PQ-node(s) to the given | hop, such that all the path(s) from the PQ-node(s) to the given | |||

destination remain unaffected in the event of a node failure of the | destination remain unaffected in the event of a node failure of the | |||

primary nexthop node. To determine whether a given PQ-node belongs | primary next-hop node. To determine whether a given PQ-node belongs | |||

to such a subset of PQ-nodes, the computing router MUST ensure that | to such a subset of PQ-nodes, the computing router MUST ensure that | |||

none of the primary nexthop node are found on any of the shortest | none of the primary next-hop nodes are found on any of the shortest | |||

paths from the PQ-node to the given destination. | paths from the PQ-node to the given destination. | |||

This document proposes an additional forward SPF computation for each | This document proposes an additional forward SPF computation for each | |||

of the PQ-nodes, to discover all shortest paths from the PQ-nodes to | of the PQ-nodes to discover all shortest paths from the PQ-nodes to | |||

the destination. This will help determine, if a given primary | the destination. This will help determine whether or not a given | |||

nexthop node is on the shortest paths from the PQ-node to the given | primary next-hop node is on the shortest paths from the PQ-node to | |||

destination or not. To determine if a given candidate node- | the given destination. To determine whether or not a given candidate | |||

protecting PQ-node provides node-protecting alternate for a given | node-protecting PQ-node provides node-protecting alternate for a | |||

destination, or not, all the shortest paths from the PQ-node to the | given destination, all the shortest paths from the PQ-node to the | |||

given destination has to be inspected, to check if the primary | given destination have to be inspected to check if the primary next- | |||

nexthop node is found on any of these shortest paths. To compute all | hop node is found on any of these shortest paths. To compute all the | |||

the shortest paths from a candidate node-protecting PQ-node to one | shortest paths from a candidate node-protecting PQ-node to one or | |||

(or more) destination, the computing router MUST run the forward SPF | more destinations, the computing router MUST run the forward SPF on | |||

on the candidate node-protecting PQ-node. Soon after running the | the candidate node-protecting PQ-node. Soon after running the | |||

forward SPF, the computer router SHOULD run the inequality in | forward SPF, the computer router SHOULD run the inequality in | |||

Figure 6 below, once for each destination. A PQ-node that does not | Figure 6 below, once for each destination. A PQ-node that does not | |||

qualify the condition for a given destination, does not guarantee | qualify the condition for a given destination does not guarantee node | |||

node-protection for the path segment from the PQ-node to the specific | protection for the path segment from the PQ-node to the specific | |||

destination. | destination. | |||

D_opt(Y,D) < D_opt(Y,E) + Distance_opt(E,D) | D_opt(Y,D) < D_opt(Y,E) + Distance_opt(E,D) | |||

Where, | Where, | |||

D_opt(A,B) : Distance on most optimum path from A to B. | D_opt(A,B) : Distance on the most optimum path from A to B. | |||

D : The destination node. | D : The destination node. | |||

E : The primary nexthop on shortest path from S | E : The primary next hop on the shortest path from S | |||

to destination. | to destination. | |||

Y : The node-protecting PQ-node being evaluated | Y : The node-protecting PQ-node being evaluated | |||

Figure 6: Node-Protecting Condition for PQ-node to Destination | Figure 6: Node-Protecting Condition for PQ-Node to Destination | |||

All of the above metric costs except D_opt(Y, D), can be obtained | All of the above metric costs, except D_opt(Y, D), can be obtained | |||

with forward and reverse SPFs with E(the primary nexthop) as the | with forward and reverse SPFs with E (the primary next hop) 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(Y, D) metric can only be determined by the | The Distance_opt(Y, D) metric can only be determined by the | |||

additional forward SPF run with PQ-node Y as the root. With | additional forward SPF run with PQ-node Y as the root. With | |||

reference to the topology in Figure 2, Table 5 below shows how the | reference to the topology in Figure 2, Table 5 shows that the above | |||

above condition can be used to determine node-protection with node- | condition can be used to determine node protection with a node- | |||

protecting PQ-node R2. | protecting PQ-node R2. | |||

+-------------+------------+---------+--------+---------+-----------+ | +-------------+------------+---------+--------+---------+-----------+ | |||

| Destination | Primary-NH | D_opt | D_opt | D_opt | Condition | | | Destination | Primary-NH | D_opt | D_opt | D_opt | Condition | | |||

| (D) | (E) | (Y, D) | (Y, E) | (E, D) | Met | | | (D) | (E) | (Y, D) | (Y, E) | (E, D) | Met | | |||

+-------------+------------+---------+--------+---------+-----------+ | +-------------+------------+---------+--------+---------+-----------+ | |||

| R3 | E | 1 | 2 | 1 | Yes | | | R3 | E | 1 | 2 | 1 | Yes | | |||

| | | (R2,R3) | (R2,E) | (E,R3) | | | | | | (R2,R3) | (R2,E) | (E,R3) | | | |||

| E | E | 2 | 2 | 0 (E,E) | No | | | E | E | 2 | 2 | 0 (E,E) | No | | |||

| | | (R2,E) | (R2,E) | | | | | | | (R2,E) | (R2,E) | | | | |||

| D1 | E | 3 | 2 | 1 | No | | | D1 | E | 3 | 2 | 1 | No | | |||

| | | (R2,D1) | (R2,E) | (E,D1) | | | | | | (R2,D1) | (R2,E) | (E,D1) | | | |||

| D2 | E | 2 | 2 | 1 | Yes | | | D2 | E | 2 | 2 | 1 | Yes | | |||

| | | (R2,D2) | (R2,E) | (E,D2) | | | | | | (R2,D2) | (R2,E) | (E,D2) | | | |||

+-------------+------------+---------+--------+---------+-----------+ | +-------------+------------+---------+--------+---------+-----------+ | |||

Table 5: Node-protection evaluation for R-LFA path segment between | Table 5: Node-Protection Evaluation for R-LFA Path Segment between | |||

PQ-node and destination | PQ-Node and Destination | |||

As seen in the above example above, R2 does not meet the node- | As seen in the example above, R2 does not meet the node-protecting | |||

protecting inequality for destination E, and D1. And so, once again, | inequality for destination E and D1. And so, once again, while R2 is | |||

while R2 is a node-protecting Remote-LFA nexthop for R3 and D2, it is | a node-protecting remote-LFA next hop for R3 and D2, it is not so for | |||

not so for E and D1. | E and D1. | |||

In SPF implementations that also produce a list of links and nodes | In SPF implementations that also produce a list of links and nodes | |||

traversed on the shortest path(s) from a given root to others, the | traversed on the shortest path(s) from a given root to others, the | |||

inequality in Figure 6 above need not be evaluated. Instead, to | inequality in Figure 6 above need not be evaluated. Instead, to | |||

determine whether a PQ-node provides node-protection for a given | determine whether or not a PQ-node provides node protection for a | |||

destination or not, the list of nodes computed from forward SPF run | given destination, the list of nodes computed from forward SPF that | |||

on the PQ-node, for the given destination, SHOULD be inspected. In | run on the PQ-node for the given destination SHOULD be inspected. In | |||

case the list contains the primary nexthop node, the PQ-node does not | case the list contains the primary next-hop node, the PQ-node does | |||

provide node-protection. Else, the PQ-node guarantees node- | not provide node protection. Else, the PQ-node guarantees the node- | |||

protecting alternate for the given destination. Below is an | protecting alternate for the given destination. Below is an | |||

illustration of the mechanism with candidate node-protecting PQ-node | illustration of the mechanism with candidate node-protecting PQ-node | |||

R2 in the topology in Figure 2. | R2 in the topology in Figure 2. | |||

+-------------+-----------------+-----------------+-----------------+ | +-------------+---------------------------+------------+------------+ | |||

| Destination | Shortest Path | Link-Protection | Node-Protection | | | Destination | Shortest Path (Repairing | Link | Node | | |||

| | (Repairing | | | | | | router to PQ-node) | Protection | Protection | | |||

| | router to PQ- | | | | +-------------+---------------------------+------------+------------+ | |||

| | node) | | | | | R3 | R2->R3 | Yes | Yes | | |||

+-------------+-----------------+-----------------+-----------------+ | | E | R2->R3->E | Yes | No | | |||

| R3 | R2->R3 | Yes | Yes | | | D1 | R2->R3->E->D1 | Yes | No | | |||

| E | R2->R3->E | Yes | No | | | D2 | R2->R3->D2 | Yes | Yes | | |||

| D1 | R2->R3->E->D1 | Yes | No | | +-------------+---------------------------+------------+------------+ | |||

| D2 | R2->R3->D2 | Yes | Yes | | ||||

+-------------+-----------------+-----------------+-----------------+ | ||||

Table 6: Protection of Remote-LFA path between PQ-node and | Table 6: Protection of Remote-LFA Path between PQ-node and | |||

destination | Destination | |||

As seen in the above example while R2 is candidate node-protecting | As seen in the above example, while R2 is a candidate node-protecting | |||

R-LFA nexthop for R3 and D2, it is not so for E and D1, since the | R-LFA next hop for R3 and D2, it is not so for E and D1, since the | |||

primary nexthop E is in the shortest path from R2 to E and D1. | primary next hop E is on the shortest path from R2 to E and D1. | |||

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 or not a given remote-LFA alternate provides node | |||

protection for a given destination or not. It does not find out any | protection for a given destination. It does not find out any new | |||

new Remote-LFA alternate nexthops, outside the ones already computed | remote-LFA alternate next hops, outside the ones already computed by | |||

by standard Remote-LFA procedure. However, in case of availability | the standard remote-LFA procedure. However, in the case of | |||

of more than one PQ-node (Remote-LFA alternates) for a destination, | availability of more than one PQ-node (remote-LFA alternates) for a | |||

and node-protection is required for the given primary nexthop, this | destination where node protection is required for the given primary | |||

procedure will eliminate the PQ-nodes that do not provide node- | next hop, this procedure will eliminate the PQ-nodes that do not | |||

protection and choose only the ones that does. | provide node protection and choose only the ones that do. | |||

2.3.3. Computing Node-Protecting R-LFA Paths for Destinations with ECMP | 2.3.3. Computing Node-Protecting R-LFA Paths for Destinations with | |||

primary nexthop nodes | Multiple Primary Next-Hop Nodes | |||

In certain scenarios, when one or more destinations maybe reachable | In certain scenarios, when one or more destinations may be reachable | |||

via multiple ECMP (equal-cost-multi-path) nexthop nodes, and only | via multiple ECMP (equal-cost-multi-path) next-hop nodes and only | |||

link-protection is required, there is no need to compute any | link protection is required, there is no need to compute any | |||

alternate paths for such destinations. In the event of failure of | alternate paths for such destinations. In the event of failure of | |||

one of the nexthop links, the remaining primary nexthops shall always | one of the next-hop links, the remaining primary next hops shall | |||

provide link-protection. However, if node-protection is required, | always provide link protection. However, if node protection is | |||

the rest of the primary nexthops may not guarantee node-protection. | required, the rest of the primary next hops may not guarantee node | |||

Figure 7 below shows one such example topology. | protection. Figure 7 below shows one such example topology. | |||

D1 | D1 | |||

2 / | 2 / | |||

S---x---E1 | S---x---E1 | |||

/ \ / \ | / \ / \ | |||

/ x / \ | / x / \ | |||

/ \ / \ | / \ / \ | |||

N-------E2 R3--D2 | N-------E2 R3--D2 | |||

\ 2 / | \ 2 / | |||

\ / | \ / | |||

\ / | \ / | |||

R1-------R2 | R1-------R2 | |||

2 | 2 | |||

Primary Nexthops: | Primary Next hops: | |||

Destination D1 = [{ S-E1, E1}, {S-E2, E2}] | Destination D1 = [{ S-E1, E1}, {S-E2, E2}] | |||

Destination D2 = [{ S-E1, E1}, {S-E2, E2}] | Destination D2 = [{ S-E1, E1}, {S-E2, E2}] | |||

Figure 7: Topology with multiple ECMP primary nexthops | Figure 7: Topology with Multiple ECMP Primary Next Hops | |||

In the above example topology, costs of all links are 1, except the | In the above example topology, costs of all links are 1, except the | |||

following links: | following links: | |||

Link: S-E1, Cost: 2 | Link: S-E1, Cost: 2 | |||

Link: N-E2: Cost: 2 | Link: N-E2: Cost: 2 | |||

Link: R1-R2: Cost: 2 | Link: R1-R2: Cost: 2 | |||

In the above topology, on computing router S, destinations D1 and D2 | In the above topology, on computing router S, destinations D1 and D2 | |||

are reachable via two ECMP nexthop nodes E1 and E2. However the | are reachable via two ECMP next-hop nodes E1 and E2. However, the | |||

primary paths via nexthop node E2 also traverses via the nexthop node | primary paths via next-hop node E2 also traverse via the next-hop | |||

E1. So in the event of node failure of nexthop node E1, both primary | node E1. So, in the event of node failure of next-hop node E1, both | |||

paths (via E1 and E2) becomes unavailable. Hence if node-protection | primary paths (via E1 and E2) become unavailable. Hence, if node | |||

is desired for destinations D1 and D2, alternate paths that does not | protection is desired for destinations D1 and D2, alternate paths | |||

traverse any of the primary nexthop nodes E1 and E2, need to be | that do not traverse any of the primary next-hop nodes E1 and E2 need | |||

computed. In the above topology the only alternate neighbor N does | to be computed. In the above topology, the only alternate neighbor N | |||

not provide such a LFA alternate path. Hence one (or more) R-LFA | does not provide such an LFA alternate path. Hence, one or more | |||

node-protecting alternate paths for destinations D1 and D2, needs to | R-LFA node-protecting alternate paths for destinations D1 and D2, | |||

be computed. | needs to be computed. | |||

In the above topology, following are the link-protecting PQ-nodes. | In the above topology, the link-protecting PQ-nodes are as follows: | |||

Primary Nexthop: E1, Link-Protecting PQ-Node: { R2 } | Primary Next Hop: E1, Link-Protecting PQ-Node: { R2 } | |||

Primary Nexthop: E2, Link-Protecting PQ-Node: { R2 } | Primary Next Hop: E2, Link-Protecting PQ-Node: { R2 } | |||

To find one (or more) node-protecting R-LFA paths for destinations D1 | To find one (or more) node-protecting R-LFA paths for destinations D1 | |||

and D2, one (or more) node-protecting PQ-node(s) needs to be | and D2, one (or more) node-protecting PQ-node(s) need to be | |||

determined first. Inequalities specified in Section 2.2.6.2 and | determined first. Inequalities specified in Sections 2.2.6.2 and | |||

Section 2.2.6.3 can be evaluated to compute the node-protecting PQ- | 2.2.6.3 can be evaluated to compute the node-protecting PQ-space for | |||

space for each of the nexthop nodes E1 and E2, as shown in Table 7 | each of the next-hop nodes E1 and E2, as shown in Table 7 below. To | |||

below. To select a PQ-node as node-protecting PQ-node for a | select a PQ-node as a node-protecting PQ-node for a destination with | |||

destination with multiple primary nexthop nodes, the PQ-node MUST | multiple primary next-hop nodes, the PQ-node MUST satisfy the | |||

satisfy the inequality for all primary nexthop nodes. Any PQ-node | inequality for all primary next-hop nodes. Any PQ-node that is NOT a | |||

which is NOT node-protecting PQ-node for all the primary nexthop | node-protecting PQ-node for all the primary next-hop nodes MUST NOT | |||

nodes, MUST NOT be chosen as the node-protecting PQ-node for | be chosen as the node-protecting PQ-node for the destination. | |||

destination. | ||||

+--------+----------+-------+--------+--------+---------+-----------+ | +--------+----------+-------+--------+--------+---------+-----------+ | |||

| Primar | Candidat | Direc | D_opt | D_opt | D_opt | Condition | | | Primary| Candidate| Direct| D_opt | D_opt | D_opt | Condition | | |||

| y Next | e PQ- | t Nbr | (Ni,Y) | (Ni,E) | (E,Y) | Met | | | Next | PQ- | Nbr | (Ni,Y) | (Ni,E) | (E,Y) | Met | | |||

| hop | node (Y) | (Ni) | | | | | | | Hop | node (Y) | (Ni) | | | | | | |||

| (E) | | | | | | | | | (E) | | | | | | | | |||

+--------+----------+-------+--------+--------+---------+-----------+ | +--------+----------+-------+--------+--------+---------+-----------+ | |||

| E1 | R2 | N | 3 | 3 | 2 | Yes | | | E1 | R2 | N | 3 | 3 | 2 | Yes | | |||

| | | | (N,R2) | (N,E1) | (E1,R2) | | | | | | | (N,R2) | (N,E1) | (E1,R2) | | | |||

| E2 | R2 | N | 3 | 2 | 3 | Yes | | | E2 | R2 | N | 3 | 2 | 3 | Yes | | |||

| | | | (N,R2) | (N,E2) | (E2,R2) | | | | | | | (N,R2) | (N,E2) | (E2,R2) | | | |||

+--------+----------+-------+--------+--------+---------+-----------+ | +--------+----------+-------+--------+--------+---------+-----------+ | |||

Table 7: Computing Node-protected PQ-nodes for nexthop E1 and E2 | Table 7: Computing Node-Protected PQ-Nodes for Next Hop E1 and E2 | |||

In SPF implementations that also produce a list of links and nodes | In SPF implementations that also produce a list of links and nodes | |||

traversed on the shortest path(s) from a given root to others, the | traversed on the shortest path(s) from a given root to others, the | |||

tunnel-repair paths from the computing router to candidate PQ-node | tunnel-repair paths from the computing router to candidate PQ-node | |||

can be examined to ensure that none of the primary nexthop nodes is | can be examined to ensure that none of the primary next-hop nodes are | |||

traversed. PQ-nodes that provide one (or more) Tunnel-repair | traversed. PQ-nodes that provide one or more Tunnel-repair paths | |||

paths(s) that does not traverse any of the primary nexthop nodes, are | that do not traverse any of the primary next-hop nodes are to be | |||

to be considered as node-protecting PQ-nodes. Table 8 below shows | considered as node-protecting PQ-nodes. Table 8 below shows the | |||

the possible tunnel-repair paths to PQ-node R2. | possible tunnel-repair paths to PQ-node R2. | |||

+--------------+------------+-------------------+-------------------+ | +--------------+------------+-------------------+-------------------+ | |||

| Primary-NH | PQ-Node | Tunnel-Repair | Exclude All | | | Primary-NH | PQ-Node | Tunnel-Repair | Exclude All | | |||

| (E) | (Y) | Paths | Primary-NH | | | (E) | (Y) | Paths | Primary-NH | | |||

+--------------+------------+-------------------+-------------------+ | +--------------+------------+-------------------+-------------------+ | |||

| E1, E2 | R2 | S==>N==>R1==>R2 | Yes | | | E1, E2 | R2 | S==>N==>R1==>R2 | Yes | | |||

+--------------+------------+-------------------+-------------------+ | +--------------+------------+-------------------+-------------------+ | |||

Table 8: Tunnel-Repair paths to PQ-node R2 | Table 8: Tunnel-Repair Paths to PQ-Node R2 | |||

From Table 7 and Table 8, in the above example, R2 being node- | From Tables 7 and 8 in the example above, R2 is a node-protecting PQ- | |||

protecting PQ-node for both primary nexthops E1 and E2, should be | node for both primary next hops E1 and E2 and should be chosen as the | |||

chosen as the node-protecting PQ-node for destinations D1 and D2 that | node-protecting PQ-node for destinations D1 and D2 that are both | |||

are both reachable via primary nexthop nodes E1 and E2. | reachable via the primary next-hop nodes E1 and E2. | |||

Next, to find a node-protecting R-LFA path from node-protecting PQ- | Next, to find a node-protecting R-LFA path from a node-protecting PQ- | |||

node to destinations D1 and D2, inequalities specified in Figure 6 | node to destinations D1 and D2, inequalities specified in Figure 6 | |||

should be evaluated, to ensure if R2 provides a node-protecting R-LFA | should be evaluated to ensure that R2 provides a node-protecting | |||

path for each of these destinations, as shown below in Table 9. For | R-LFA path for each of these destinations, as shown below in Table 9. | |||

a R-LFA path to qualify as node-protecting R-LFA path for a | For an R-LFA path to qualify as a node-protecting R-LFA path for a | |||

destination with multiple ECMP primary nexthop nodes, the R-LFA path | destination with multiple ECMP primary next-hop nodes, the R-LFA path | |||

from the PQ-node to the destination MUST satisfy the inequality for | from the PQ-node to the destination MUST satisfy the inequality for | |||

all primary nexthop nodes. | all primary next-hop nodes. | |||

+----------+----------+-------+--------+--------+--------+----------+ | +----------+----------+-------+--------+--------+--------+----------+ | |||

| Destinat | Primary- | PQ- | D_opt | D_opt | D_opt | Conditio | | | Destinat | Primary- | PQ- | D_opt | D_opt | D_opt | Condition| | |||

| ion (D) | NH (E) | Node | (Y, D) | (Y, E) | (E, D) | n Met | | | ion (D) | NH (E) | Node | (Y, D) | (Y, E) | (E, D) | Met | | |||

| | | (Y) | | | | | | | | | (Y) | | | | | | |||

+----------+----------+-------+--------+--------+--------+----------+ | +----------+----------+-------+--------+--------+--------+----------+ | |||

| D1 | E1 | R2 | 3 (R2, | 2 (R2, | 1 (E1, | No | | | D1 | E1 | R2 | 3 (R2, | 2 (R2, | 1 (E1, | No | | |||

| | | | D1) | E1) | D1) | | | | | | | D1) | E1) | D1) | | | |||

| D1 | E2 | R2 | 3 (R2, | 3 (R2, | 2 (E2, | Yes | | | D1 | E2 | R2 | 3 (R2, | 3 (R2, | 2 (E2, | Yes | | |||

| | | | D1) | E2) | D1) | | | | | | | D1) | E2) | D1) | | | |||

| D2 | E1 | R2 | 2 (R2, | 2 (R2, | 2 (E1, | Yes | | | D2 | E1 | R2 | 2 (R2, | 2 (R2, | 2 (E1, | Yes | | |||

| | | | D2) | E1) | D2) | | | | | | | D2) | E1) | D2) | | | |||

| D2 | E2 | R2 | 2 (R2, | 2 (R2, | 3 (E2, | Yes | | | D2 | E2 | R2 | 2 (R2, | 2 (R2, | 3 (E2, | Yes | | |||

| | | | D2) | E2) | D2) | | | | | | | D2) | E2) | D2) | | | |||

+----------+----------+-------+--------+--------+--------+----------+ | +----------+----------+-------+--------+--------+--------+----------+ | |||

Table 9: Finding node-protecting R-LFA path for destinations D1 and | Table 9: Finding Node-Protecting R-LFA Path for | |||

D2 | Destinations D1 and D2 | |||

In SPF implementations that also produce a list of links and nodes | In SPF implementations that also produce a list of links and nodes | |||

traversed on the shortest path(s) from a given root to others, the | traversed on the shortest path(s) from a given root to others, the | |||

R-LFA paths via node-protecting PQ-node to final destination can be | R-LFA paths via a node-protecting PQ-node to the final destination | |||

examined to ensure that none of the primary nexthop nodes is | can be examined to ensure that none of the primary next-hop nodes are | |||

traversed. R-LFA path(s) that does not traverse any of the primary | traversed. One or more R-LFA paths that do not traverse any of the | |||

nexthop nodes, guarantees node-protection in the event of failure of | primary next-hop nodes guarantees node protection in the event of | |||

any of the primary nexthop nodes. Table 10 below shows the possible | failure of any of the primary next-hop nodes. Table 10 shows the | |||

R-LFA-paths for destinations D1 and D2 via the node-protecting PQ- | possible R-LFA-paths for destinations D1 and D2 via the node- | |||

node R2. | protecting PQ-node R2. | |||

+-------------+------------+---------+-----------------+------------+ | +-------------+------------+---------+-----------------+------------+ | |||

| Destination | Primary-NH | PQ-Node | R-LFA Paths | Exclude | | | Destination | Primary-NH | PQ-Node | R-LFA Paths | Exclude | | |||

| (D) | (E) | (Y) | | All | | | (D) | (E) | (Y) | | All | | |||

| | | | | Primary-NH | | | | | | | Primary-NH | | |||

+-------------+------------+---------+-----------------+------------+ | +-------------+------------+---------+-----------------+------------+ | |||

| D1 | E1, E2 | R2 | S==>N==>R1==>R2 | No | | | D1 | E1, E2 | R2 | S==>N==>R1==>R2 | No | | |||

| | | | -->R3-->E1-->D1 | | | | | | | -->R3-->E1-->D1 | | | |||

| | | | | | | | | | | | | | |||

| D2 | E1, E2 | R2 | S==>N==>R1==>R2 | Yes | | | D2 | E1, E2 | R2 | S==>N==>R1==>R2 | Yes | | |||

| | | | -->R3-->D2 | | | | | | | -->R3-->D2 | | | |||

+-------------+------------+---------+-----------------+------------+ | +-------------+------------+---------+-----------------+------------+ | |||

Table 10: R-LFA paths for destinations D1 and D2 | Table 10: R-LFA Paths for Destinations D1 and D2 | |||

From Table 9 and Table 10, in the example above, the R-LFA path from | From Tables 9 and 10 in the example above, the R-LFA path from R2 | |||

R2 does not meet the node-protecting inequality for destination D1, | does not meet the node-protecting inequality for destination D1, | |||

while it does meet the same inequality for destination D2. And so, | while it does meet the same inequality for destination D2. So, while | |||

while R2 provides node-protecting R-LFA alternate for D2, it fails to | R2 provides a node-protecting R-LFA alternate for D2, it fails to | |||

provide node-protection for destination D1. Finally, while it is | provide node protection for destination D1. Finally, while it is | |||

possible to get a node-protecting R-LFA path for D2, no such node- | possible to get a node-protecting R-LFA path for D2, no such node- | |||

protecting R-LFA path can be found for D1. | protecting R-LFA path can be found for D1. | |||

2.3.4. Limiting extra computational overhead | 2.3.4. Limiting Extra Computational Overhead | |||

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 document [RFC7490] (one reverse SPF for each of the | |||

connected neighbors), this document proposes a forward SPF | directly connected neighbors), this document proposes a forward SPF | |||

computations for each PQ-node discovered in the network. Since the | computation 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 specifies 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 the user with a | |||

configuration knob to override the default limit. This document | configuration knob to override the default limit. This document | |||

suggests 16 as a default value for this limit. Implementations MUST | suggests 16 as a default value for this limit. Implementations MUST | |||

also evaluate some default preference criteria while considering a | also evaluate some default preference criteria while considering a | |||

PQ-node in this subset. The exact default preference criteria to be | PQ-node in this subset. The exact default preference criteria to be | |||

used is outside the scope of this document, and is a matter of | used is outside the scope of this document and is a matter of | |||

implementation. Finally, implementations MAY also allow the user to | implementation. Finally, implementations MAY also allow the user to | |||

override the default preference criteria, by providing a policy | override the default preference criteria, by providing a policy | |||

configuration for the same. | 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 that 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 that are closer (based on | |||

on metric) to the computing router SHOULD be preferred over PQ-nodes | 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 computing | primary interfaces and are the same distance from 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. | |||

Once a subset of PQ-nodes is found, computing router shall run a | Once a subset of PQ-nodes is found, a computing router shall run a | |||

forward SPF on each of the PQ-nodes in the subset to continue with | forward SPF on each of the PQ-nodes in the subset to continue with | |||

procedures proposed in Section 2.3.2. | procedures proposed in Section 2.3.2. | |||

3. Manageability of Remote-LFA Alternate Paths | 3. Manageability of Remote-LFA Alternate Paths | |||

3.1. The Problem | 3.1. The Problem | |||

With the regular Remote-LFA [RFC7490] functionality the computing | With the regular remote-LFA [RFC7490] functionality, the computing | |||

router may compute more than one PQ-node as usable Remote-LFA | router may compute more than one PQ-node as usable remote-LFA | |||

alternate nexthops. Additionally [RFC7916] specifies a LFA (and | alternate next hops. Additionally, [RFC7916] specifies an LFA (and a | |||

Remote-LFA) manageability framework, in which an alternate selection | remote-LFA) manageability framework, in which an alternate selection | |||

policy may be configured to let the network operator choose one of | policy may be configured to let the network operator choose one of | |||

them as the most appropriate Remote-LFA alternate. For such policy- | them as the most appropriate remote-LFA alternates. For such a | |||

based alternate selection to run, the computing router needs to | policy-based alternate selection to run, the computing router needs | |||

collect all the relevant path characteristics (as specified in | to collect all the relevant path characteristics (as specified in | |||

section 6.2.4 of [RFC7916]) for each of the alternate paths (one | Section 6.2.4 of [RFC7916]) for each of the alternate paths (one | |||

through each of the PQ-nodes). As mentioned before in Section 2.3 | through each of the PQ-nodes). As mentioned before in Section 2.3, | |||

the R-LFA alternate path through a given PQ-node to a given | the R-LFA alternate path through a given PQ-node to a given | |||

destination is comprised of two path segments. Section 6.2.5.4 of | destination is comprised of two path segments. Section 6.2.4 of | |||

[RFC7916] specifies that any kind of alternate selection policy must | [RFC7916] specifies that any kind of alternate selection policy must | |||

consider path characteristics for both path segments while evaluating | consider path characteristics for both path segments while evaluating | |||

one or more RLFA alternate path(s). | one or more RLFA alternate paths. | |||

The first path segment (i.e. from the computing router to the PQ- | The first path segment (i.e., from the computing router to the PQ- | |||

node) can be calculated from the regular forward SPF done as part of | node) can be calculated from the regular forward SPF done as part of | |||

standard and remote LFA computations. However without the mechanism | standard and remote LFA computations. However, without the mechanism | |||

proposed in Section 2.3.2 of this document, there is no way to | proposed in Section 2.3.2 of this document, there is no way to | |||

determine the path characteristics for the second path segment (i.e. | determine the path characteristics for the second path segment (i.e., | |||

from the PQ-node to the destination). In the absence of the path | from the PQ-node to the destination). In the absence of the path | |||

characteristics for the second path segment, two Remote-LFA alternate | characteristics for the second path segment, two remote-LFA alternate | |||

paths may be equally preferred based on the first path segments | paths may be equally preferred based on the first path segment | |||

characteristics only, although the second path segment attributes may | characteristics only, although the second path segment attributes may | |||

be different. | be different. | |||

3.2. The Solution | 3.2. The Solution | |||

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 | shall also collect links, nodes, and path characteristics along the | |||

along the second path segment. This shall enable collection of | second path segment. This shall enable the collection of complete | |||

complete path characteristics for a given Remote-LFA alternate path | path characteristics for a given remote-LFA alternate path to a given | |||

to a given destination. The complete alternate path characteristics | destination. The complete alternate path characteristics shall then | |||

shall then facilitate more accurate alternate path selection while | facilitate more accurate alternate path selection while running the | |||

running the alternate selection policy. | 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 | |||

overhead. | overhead. | |||

The mechanism proposed in this section does not modify or invalidate | The mechanism proposed in this section does not modify or invalidate | |||

[RFC7916] or any parts of it. This document specifies a mechanism to | any part of [RFC7916]. This document specifies a mechanism to meet | |||

meet the requirements specified in section 6.5.2.4 in [RFC7916]. | the requirements specified in Section 6.2.5.4 of [RFC7916]. | |||

4. Acknowledgements | ||||

Many thanks to Bruno Decraene for providing his useful comments. We | ||||

would also like to thank Uma Chunduri for reviewing this document and | ||||

providing valuable feedback. Also, many thanks to Harish Raghuveer | ||||

for his review and comments on the initial versions of this document. | ||||

5. IANA Considerations | 4. IANA Considerations | |||

N/A. - No protocol changes are proposed in this document. | This document does not require any IANA actions. | |||

6. Security Considerations | 5. 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. | |||

7. References | 6. References | |||

7.1. Normative References | 6.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>. | |||

[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>. | |||

7.2. Informative References | 6.2. Informative References | |||

[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., | [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., | |||

Horneffer, M., and P. Sarkar, "Operational Management of | Horneffer, M., and P. Sarkar, "Operational Management of | |||

Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, | Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, | |||

July 2016, <http://www.rfc-editor.org/info/rfc7916>. | July 2016, <http://www.rfc-editor.org/info/rfc7916>. | |||

Acknowledgements | ||||

Many thanks to Bruno Decraene for providing his useful comments. We | ||||

would also like to thank Uma Chunduri for reviewing this document and | ||||

providing valuable feedback. Also, many thanks to Harish Raghuveer | ||||

for his review and comments on the initial draft versions of this | ||||

document. | ||||

Authors' Addresses | Authors' Addresses | |||

Pushpasis Sarkar (editor) | Pushpasis Sarkar (editor) | |||

Individual Contributor | Arrcus, Inc. | |||

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 | |||

Bangalore, KA 560103 | Bangalore, KA 560103 | |||

India | India | |||

Email: shraddha@juniper.net | Email: shraddha@juniper.net | |||

skipping to change at page 21, line 4 ¶ | skipping to change at page 22, line 19 ¶ | |||

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 | |||

Bangalore, KA 560103 | Bangalore, KA 560103 | |||

India | India | |||

Email: shraddha@juniper.net | Email: shraddha@juniper.net | |||

Chris Bowers | Chris Bowers | |||

Juniper Networks, Inc. | Juniper Networks, Inc. | |||

1194 N. Mathilda Ave. | 1194 N. Mathilda Ave. | |||

Sunnyvale, CA 94089 | Sunnyvale, CA 94089 | |||

US | United States of America | |||

Email: cbowers@juniper.net | Email: cbowers@juniper.net | |||

Hannes Gredler | Hannes Gredler | |||

RtBrick, Inc. | RtBrick, Inc. | |||

Email: hannes@rtbrick.com | Email: hannes@rtbrick.com | |||

Stephane Litkowski | Stephane Litkowski | |||

Orange | Orange | |||

End of changes. 146 change blocks. | ||||

432 lines changed or deleted | | 432 lines changed or added | ||

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |