draft-ietf-rtgwg-rlfa-node-protection-02.txt | draft-ietf-rtgwg-rlfa-node-protection-03.txt | |||
---|---|---|---|---|

Routing Area Working Group P. Sarkar, Ed. | Routing Area Working Group P. Sarkar, Ed. | |||

Internet-Draft H. Gredler | Internet-Draft S. Hegde | |||

Intended status: Standards Track S. Hegde | Intended status: Standards Track C. Bowers | |||

Expires: December 17, 2015 C. Bowers | Expires: April 8, 2016 Juniper Networks, Inc. | |||

Juniper Networks, Inc. | H. Gredler | |||

Unaffiliated | ||||

S. Litkowski | S. Litkowski | |||

Orange | Orange | |||

H. Raghuveer | October 6, 2015 | |||

June 15, 2015 | ||||

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

draft-ietf-rtgwg-rlfa-node-protection-02 | draft-ietf-rtgwg-rlfa-node-protection-03 | |||

Abstract | Abstract | |||

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

[I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link- | [RFC7490] specification guarantees only link-protection. The | |||

protection. The resulting Remote-LFA nexthops (also called PQ- | resulting Remote-LFA nexthops (also called PQ-nodes), may not | |||

nodes), may not gaurantee node-protection for all destinations being | guarantee node-protection for all destinations being protected by it. | |||

protected by it. | ||||

This document describes procedures for determining if a given PQ-node | This document describes procedures for determining if a given PQ-node | |||

provides node-protection for a specific destination or not. The | provides node-protection for a specific destination or not. The | |||

document also shows how the same procedure can be utilised for | document also shows how the same procedure can be utilised for | |||

collection of complete characteristics for alternate paths. | collection of complete characteristics for alternate paths. | |||

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

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

fitting constraints. | fitting constraints. | |||

Requirements Language | Requirements Language | |||

skipping to change at page 2, line 7 | skipping to change at page 2, line 7 | |||

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

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

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

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

Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||

and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||

time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||

material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||

This Internet-Draft will expire on December 17, 2015. | This Internet-Draft will expire on April 8, 2016. | |||

Copyright Notice | Copyright Notice | |||

Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||

document authors. All rights reserved. | document authors. All rights reserved. | |||

This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||

Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||

(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||

publication of this document. Please review these documents | publication of this document. Please review these documents | |||

skipping to change at page 2, line 30 | skipping to change at page 2, line 30 | |||

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 | 2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 3 | |||

2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

2.2. Few Additional Definitions . . . . . . . . . . . . . . . 5 | 2.2. Few Additional Definitions . . . . . . . . . . . . . . . 5 | |||

2.2.1. Link-Protecting Extended P-Space . . . . . . . . . . 5 | 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 . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2.3. Q-Space . . . . . . . . . . . . . . . . . . . . . . . 7 | |||

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

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

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

2.3.1. Computing Candidate Node-protecting PQ-Nodes for | 2.3.1. Computing Candidate Node-protecting PQ-Nodes for | |||

Primary nexthops . . . . . . . . . . . . . . . . . . 8 | Primary nexthops . . . . . . . . . . . . . . . . . . 8 | |||

2.3.2. Computing node-protecting paths from PQ-nodes to | 2.3.2. Computing node-protecting paths from PQ-nodes to | |||

destinations . . . . . . . . . . . . . . . . . . . . 10 | destinations . . . . . . . . . . . . . . . . . . . . 10 | |||

2.3.3. Limiting extra computational overhead . . . . . . . . 12 | 2.3.3. Limiting extra computational overhead . . . . . . . . 12 | |||

skipping to change at page 3, line 7 | skipping to change at page 3, line 7 | |||

4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | |||

5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||

6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||

7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||

7.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||

7.2. Informative References . . . . . . . . . . . . . . . . . 15 | 7.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | |||

1. Introduction | 1. Introduction | |||

The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] specification provides | The Remote-LFA [RFC7490] specification provides loop-free alternates | |||

loop-free alternates that gaurantees only link-protection. The | that guarantees only link-protection. The resulting Remote-LFA | |||

resulting Remote-LFA alternate nexthops (also referred to as the PQ- | alternate nexthops (also referred to as the PQ-nodes) may not provide | |||

nodes) may not provide node-protection for all destinations covered | node-protection for all destinations covered by the same, in case of | |||

by the same, in case of failure of the primary nexthop node. Neither | failure of the primary nexthop node. Neither does the specification | |||

does the specification provide a means to determine the same. | provide a means to determine the same. | |||

Also, the LFA Manageability [I-D.ietf-rtgwg-lfa-manageability] | Also, the LFA Manageability [I-D.ietf-rtgwg-lfa-manageability] | |||

document, requires a computing router to find all possible (including | document, requires a computing router to find all possible (including | |||

all possible Remote-LFA) alternate nexthops, collect the complete set | all possible Remote-LFA) alternate nexthops, collect the complete set | |||

of path characteristics for each alternate path, run a alternate- | of path characteristics for each alternate path, run a alternate- | |||

selection policy (configured by the operator), and find the best | selection policy (configured by the operator), and find the best | |||

alternate path. This will require the Remote-LFA implementation to | alternate path. This will require the Remote-LFA implementation to | |||

gather all the required path characteristics along each link on the | gather all the required path characteristics along each link on the | |||

entire Remote-LFA alternate path. | entire Remote-LFA alternate path. | |||

With current LFA [RFC5286] and Remote-LFA implementations, the | With current LFA [RFC5286] and Remote-LFA implementations, the | |||

forward SPF (and reverse SPF) is run on the computing router and its | forward SPF (and reverse SPF) is run on the computing router and its | |||

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

of path attributes (e.g. SRLG, Admin-groups) for first alternate | of path attributes (e.g. SRLG, Admin-groups) for first alternate | |||

path segment from the computing router to the PQ-node, there is no | path segment from the computing router to the PQ-node, there is no | |||

means for the computing router to gather any path attributes for the | means for the computing router to gather any path attributes for the | |||

path segment from the PQ-node to destination. Consecutively any | path segment from the PQ-node to destination. Consequently any | |||

policy-based selection of alternate paths will consider only the path | policy-based selection of alternate paths will consider only the path | |||

attributes from the computing router up until the PQ-node. | attributes from the computing router up until the PQ-node. | |||

This document describes a procedure for determining node-protection | This document describes a procedure for determining node-protection | |||

with Remote-LFA. The same procedure are also extended for collection | with Remote-LFA. The same procedure are also extended for collection | |||

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

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

2. Node Protection with Remote-LFA | 2. Node Protection with Remote-LFA | |||

Node-protection is required to provide protection of traffic on a | Node-protection is required to provide protection of traffic on a | |||

given forwarding node, against the failure of the first-hop node on | given forwarding node, against the failure of the first-hop node on | |||

the primary forwarding path. Such protection becomes more critical | the primary forwarding path. Such protection becomes more critical | |||

in the absence of mechanisms like non-stop-routing in the network. | in the absence of mechanisms like non-stop-routing in the network. | |||

Certain operators refrains from deploying non-stop-routing in their | Certain operators refrain from deploying non-stop-routing in their | |||

network, due to the significant additional performance complexities | network, due to the significant additional performance complexities | |||

it comes along with. In such cases node-protection is a must to | it introduces. In such cases node-protection is a essential to | |||

gaurantee un-interrupted flow of traffic, even in the case of an | guarantee un-interrupted flow of traffic, even in the case of an | |||

entire forwarding node going down. | entire forwarding node going down. | |||

The following sections discusses the node-protection problem in the | The following sections discuss the node-protection problem in the | |||

context of Remote-LFA and proposes a solution for solving the same. | 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 | document the following topology diagram from the Remote-LFA [RFC7490] | |||

[I-D.ietf-rtgwg-remote-lfa] draft is being re-used with slight | draft is being re-used with slight modification. | |||

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 [I-D.ietf-rtgwg-remote-lfa] alternate specifications node R2 | LFA [RFC7490] alternate specifications node R2 being the only PQ-node | |||

being the only PQ-node for the S-E link provides nexthop for all the | for the S-E link provides nexthop for all the above destinations. | |||

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

Remote-LFA alternate paths for each destination. | 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 | | |||

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

skipping to change at page 4, line 50 | skipping to change at page 4, line 49 | |||

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 nexthop E, the alternate path from Remote-LFA | |||

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

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

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

destination MUST not traverse the primary nexthop. | destination MUST not traverse the primary nexthop. | |||

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. | additional link between N and E with the same cost as the other | |||

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 more on any of the shortest | |||

paths from N to R3. Hence R3 is also included in both the Extended-P | paths from N to R3, E and D1. Hence R3, E and D1 are also included | |||

space and PQ space of E (w.r.t S-E link). Table 2 below, shows all | in both the Extended-P space and Q space of E (w.r.t S-E link). | |||

possible primary and R-LFA alternate paths via PQ-node R3, for each | Table 2 below, shows all possible primary and R-LFA alternate paths | |||

destination reachable through the S-E link in the above topology. | via PQ-node R3, for each destination reachable through the S-E link | |||

The R-LFA alternate paths via PQ-node R2 remains same as in Table 1. | in the above topology. The R-LFA alternate paths via PQ-node R2 | |||

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

D1, if we choose R3 as the R-LFA nexthop, it does not provide node- | D2, if we choose R3 as the R-LFA nexthop, it does not provide node- | |||

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

nexthop, in the event of the node-failure on primary nexthop E, the | nexthop, in the event of the node-failure on primary nexthop E, on | |||

alternate path from S to R-LFA nexthop R3 also becomes unavailable. | the alternate path from S to R-LFA nexthop R3, one of parallel ECMP | |||

So for a Remote-LFA nexthop to provide node-protection for a given | path between N and R3 also becomes unavailable. So for a Remote-LFA | |||

destination, it is also mandatory that, the shortest path from S to | nexthop to provide node-protection for a given destination, it is | |||

the chosen PQ-node MUST not traverse the primary nexthop node. | also mandatory that, the shortest path from S to the chosen PQ-node | |||

MUST not traverse the primary nexthop node. | ||||

2.2. Few Additional Definitions | 2.2. Few 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 [I-D.ietf-rtgwg-remote-lfa] draft. | the ones mentioned in Remote-LFA [RFC7490] draft. | |||

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

The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] draft already defines | The Remote-LFA [RFC7490] draft already defines this. The link- | |||

this. The link-protecting extended P-space for a link S-E being | protecting extended P-space for a link S-E being protected is the set | |||

protected is the set of routers that are reachable from one or more | of routers that are reachable from one or more direct neighbors of S, | |||

direct neighbors of S, except primary node E, without traversing the | except primary node E, without traversing the S-E link on any of the | |||

S-E link on any of the shortest path from the direct neighbor to the | shortest path from the direct neighbor to the router. This MUST | |||

router. This MUST exclude any direct neighbor for which there is | exclude any direct neighbor for which there is at least one ECMP path | |||

atleast one ECMP path from the direct neighbor traversing the | from the direct neighbor traversing the link(S-E) being protected. | |||

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

A node Y is in link-protecting extended P-space w.r.t to the link | A node Y is in link-protecting extended P-space w.r.t to the link | |||

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

direct neighbor of S, Ni, other than primary nexthop E, that | direct neighbor of S, Ni, other than primary nexthop E, that | |||

satisfies the 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 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. | nexthop 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.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 nexthop 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 | the node E. This MUST exclude any direct neighbors for which there | |||

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

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

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

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

neighbor of S, Ni, other than primary nexthop E, that satisfies the | neighbor of S, Ni, other than primary nexthop E, that satisfies the | |||

following condition. | 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 most optimum path from A to B. | |||

E : The primary nexthop on shortest path from S | E : The primary nexthop on 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 | |||

skipping to change at page 7, line 27 | skipping to change at page 7, line 27 | |||

It must be noted that a node Y satisfying the condition in Figure 4 | It must be noted that a node Y satisfying the condition in Figure 4 | |||

above only guarantees that the R-LFA alternate path segment from S | above 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 | via 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 | a 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.3. Q-Space | 2.2.3. Q-Space | |||

The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] draft already defines | The Remote-LFA [RFC7490] draft already defines this. The Q-space for | |||

this. The Q-space for a link S-E being protected is the set of | a link S-E being protected is the set of routers that can reach | |||

routers that can reach primary node E, without traversing the S-E | primary node E, without traversing the S-E link on any of the | |||

link on any of the shortest path from the node Y to primary nexthop | shortest path from the node Y to primary nexthop E. This MUST | |||

E. This MUST exclude any destination for which there is atleast one | exclude any destination for which there is at least one ECMP path | |||

ECMP path from the node Y to the primary nexthop E traversing the | from the node Y to the primary nexthop E traversing the link(S-E) | |||

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

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

and only if, the following condition is satisfied. | 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 most optimum path from A to B. | |||

E : The primary nexthop on shortest path from S | E : The primary nexthop on shortest path from S | |||

to destination. | to destination. | |||

skipping to change at page 8, line 30 | skipping to change at page 8, line 30 | |||

via the same, in entirety, is unaffected in the event of a node | via the same, in entirety, is unaffected in the event of a node | |||

failure of primary nexthop node E. It only guarantees that the path | failure of primary nexthop node E. It only guarantees that the path | |||

segment from S to PQ-node Y is unaffected by the same failure event. | segment from S to PQ-node Y is unaffected by the same failure event. | |||

The PQ-nodes in the candidate node-protecting PQ space may provide | The PQ-nodes in the candidate node-protecting PQ space may provide | |||

node protection for only a subset of destinations that are reachable | node protection for only a subset of destinations that are reachable | |||

through the corresponding primary link. | through the corresponding primary link. | |||

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 comprises 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 nexthop), 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 a R-LFA alternate path for a given destination provides | |||

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

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

nexthop node. Sections Section 2.3.1 and Section 2.3.2 shows how | node. Sections Section 2.3.1 and Section 2.3.2 shows how this can be | |||

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

nexthops | nexthops | |||

To choose a node-protecting R-LFA nexthop for a destination R3, | To choose a node-protecting R-LFA nexthop 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 nexthop E on shortest path from S | |||

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

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

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

does not traverse primary nexthop node E. | does not traverse primary nexthop node E. | |||

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

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

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

All of the metrics needed by this inequality would have been already | All of the metrics needed by this inequality would have been already | |||

collected from the forward SPFs rooted at each of direct neighbor S, | collected from the forward SPFs rooted at each of direct neighbor S, | |||

computed as part of standard LFA [RFC5286] implementation. With | computed as part of standard LFA [RFC5286] implementation. With | |||

reference to the topology in Figure 2, Table 3 below shows how the | reference to the topology in Figure 2, Table 3 below shows how the | |||

skipping to change at page 9, line 30 | skipping to change at page 9, line 30 | |||

| 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 and so, while R2 is in candidate node- | |||

protecting PQ space, R3 is not. | protecting PQ space, R3 is not. | |||

Some SPF implementations may also produce a list of links and nodes | Some SPF implementations may also produce a list of links and nodes | |||

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

such implementations, router S may have executed a forward SPF with | such implementations, router S may have executed a forward SPF with | |||

each of it's direct neighbors as the SPF root, executed as part of | each of it's direct neighbors as the SPF root, executed as part of | |||

the standard LFA [RFC5286] computations. So S may re-use the list of | the standard LFA [RFC5286] computations. So S may re-use the list of | |||

links and nodes collected from the same SPF computations, to decide | links and nodes collected from the same SPF computations, to decide | |||

whether a node Y is a candidate node-protecting PQ-node or not. A | whether a node Y is a candidate node-protecting PQ-node or not. A | |||

node Y shall be considered as a node-protecting PQ-node, if and only | node Y shall be considered as a node-protecting PQ-node, if and only | |||

if, there is atleast one direct neighbor of S, other than the primary | if, there is at least one direct neighbor of S, other than the | |||

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

the list of nodes traversed on any of the shortest path(s) from the | exist on the list of nodes traversed on any of the shortest path(s) | |||

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

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

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

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

| PQ-node | Path(Repairing | | | | | PQ-node | Path(Repairing | | | | |||

| | router to PQ- | | | | | | 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 candidate node-protecting | |||

Remote-LFA nexthop for R3 and D2, it is not so for E and D1, since | Remote-LFA nexthop 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 F. | the primary nexthop E is in 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 in 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 | |||

nexthop, such that all the path(s) from the PQ-node(s) to the given | nexthop, 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 | destination remain unaffected in the event of a node failure of the | |||

primary nexthop node. To ensure this, the computing router will need | primary nexthop node. To ensure this, the computing router will need | |||

to ensure that, the primary nexthop node should not be on any of the | to ensure that, the primary nexthop node should not be on any of the | |||

shortest paths from the PQ-node to the given destination. | shortest 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. The additional forward SPF computation for each PQ- | the destination. The additional forward SPF computation for each PQ- | |||

node, shall help determine, if a given primary nexthop node is on the | node, shall help determine, if a given primary nexthop node is on the | |||

shortest paths from the PQ-node to the given destination or not. To | shortest paths from the PQ-node to the given destination or not. To | |||

determine if a given candidate node-protecting PQ-node provides node- | determine if a given candidate node-protecting PQ-node provides node- | |||

protecting alternate for a given destination, the primary nexthop | protecting alternate for a given destination, the primary nexthop | |||

node should not be on any of the shortest paths from the PQ-node to | node should not be on any of the shortest paths from the PQ-node to | |||

the given destination. On running the forward SPF on a candidate | the given destination. On running the forward SPF on a candidate | |||

node-protecting PQ-node the computing router shall run the inequality | node-protecting PQ-node the computing router shall run the inequality | |||

in Figure 6 below. PQ-nodes that does not qualify the condition for | in Figure 6 below. A PQ-node that does not qualify the condition for | |||

a given destination, does not gaurantee node-protection for the path | a given destination, does not guarantee node-protection for the path | |||

segment from the PQ-node to the given destination. | segment from the PQ-node to the given 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 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 nexthop on shortest path from S | |||

to destination. | to destination. | |||

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

skipping to change at page 11, line 43 | skipping to change at page 11, line 43 | |||

| 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 above example above, R2 does not meet the node- | |||

protecting inequality for destination E, and F. And so, once again, | protecting inequality for destination E, and D1. And so, once again, | |||

while R2 is a node-protecting Remote-LFA nexthop for R3 and G, it is | while R2 is a node-protecting Remote-LFA nexthop for R3 and D2, it is | |||

not so for E and F. | not so for 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, to | traversed on the shortest path(s) from a given root to others, to | |||

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

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

on the PQ-node, for the given destination, should be inspected. In | 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 nexthop node, the PQ-node does not | |||

provide node-protection. Else, the PQ-node guarantees node- | provide node-protection. Else, the PQ-node guarantees 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 | |||

skipping to change at page 12, line 25 | skipping to change at page 12, line 25 | |||

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

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

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

| D2 | R2->R3->D2 | Yes | Yes | | | 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 candidate node-protecting | |||

R-LFA nexthop for R3 and G, it is not so for E and F, since the | R-LFA nexthop 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 F. | primary nexthop E is in 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 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 or not. It does not find out any | |||

new Remote-LFA alternate nexthops, outside the ones already computed | new Remote-LFA alternate nexthops, outside the ones already computed | |||

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

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

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

procedure will eliminate the PQ-nodes that do not provide node- | procedure will eliminate the PQ-nodes that do not provide node- | |||

protection and choose only the ones that does. | protection and choose only the ones that does. | |||

2.3.3. Limiting extra computational overhead | 2.3.3. Limiting extra computational overhead | |||

In addition to the extra reverse SPF computation, one per directly | In addition to the extra reverse SPF computation, one per directly | |||

connected neighbor, suggested by the Remote-LFA | connected neighbor, suggested by the Remote-LFA [RFC7490] draft, this | |||

[I-D.ietf-rtgwg-remote-lfa] draft, this document proposes a forward | document proposes a forward SPF per PQ-node discovered in the | |||

SPF per PQ-node discovered in the network. Since the average number | network. Since the average number of PQ-nodes found in any network | |||

of PQ-nodes found in any network is considerably more than the number | is considerably more than the number of direct neighbors of the | |||

of direct neighbors of the computing router, the proposal of running | computing router, the proposal of running one forward SPF per PQ-node | |||

one forward SPF per PQ-node may add considerably to the overall SPF | may add considerably to the overall SPF computation time. | |||

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 proposes 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. Implementations | |||

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

a PQ-node in this subset. Finally, implementations MAY also allow | a PQ-node in this subset. Finally, implementations MAY also allow | |||

user to override the default preference criteria, by providing a | user to override the default preference criteria, by providing a | |||

policy configuration for the same. | policy configuration for the same. | |||

This document proposes that implementations SHOULD use a default | This document proposes that implementations SHOULD use a default | |||

preference criteria for PQ-node selection which will put a score on | preference criteria for PQ-node selection which will put a score on | |||

each PQ-node, proportional to the number of primary interfaces for | each PQ-node, proportional to the number of primary interfaces for | |||

which it provides coverage, its distance from the computing router, | which it provides coverage, it's distance from the computing router, | |||

and its router-id (or system-id in case of IS-IS). PQ-nodes that | and its router-id (or system-id in case of IS-IS). PQ-nodes that | |||

cover more primary interfaces SHOULD be preferred over PQ-nodes that | cover more primary interfaces SHOULD be preferred over PQ-nodes that | |||

cover fewer primary interfaces. When two or more PQ-nodes cover the | cover fewer primary interfaces. When two or more PQ-nodes cover the | |||

same number of primary interfaces, PQ-nodes which are closer (based | same number of primary interfaces, PQ-nodes which are closer (based | |||

on metric) to the computing router SHOULD be preferred over PQ-nodes | on metric) to the computing router SHOULD be preferred over PQ-nodes | |||

farther away from it. For PQ-nodes that cover the same number of | farther away from it. For PQ-nodes that cover the same number of | |||

primary interfaces and are the same distance from the the computing | primary interfaces and are the same distance from the the computing | |||

router, the PQ-node with smaller router-id (or system-id in case of | router, the PQ-node with smaller router-id (or system-id in case of | |||

IS-IS) SHOULD be preferred. | IS-IS) SHOULD be preferred. | |||

Once a subset of PQ-nodes is found, computing router shall run a | Once a subset of PQ-nodes is found, 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 Section 2.3.2. | procedures proposed in section Section 2.3.2. | |||

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

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

With the regular Remote-LFA [I-D.ietf-rtgwg-remote-lfa] functionality | With the regular Remote-LFA [RFC7490] functionality the computing | |||

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

Remote-LFA alternate nexthops. Additionally an alternate selection | alternate nexthops. Additionally an alternate selection policy may | |||

policy may be configured to enable the network operator to choose one | be configured to enable the network operator to choose one of them as | |||

of them as the most appropriate Remote-LFA alternate. For such | the most appropriate Remote-LFA alternate. For such policy-based | |||

policy-based alternate selection to run, all the relevant path | alternate selection to run, all the relevant path characteristics for | |||

characteristics for each the alternate paths (one through each of the | each the alternate paths (one through each of the PQ-nodes), needs to | |||

PQ-nodes), needs to be collected. As mentioned befor in section | be collected. As mentioned before in section Section 2.3 the R-LFA | |||

Section 2.3 the R-LFA alternate path through a given PQ-node to a | alternate path through a given PQ-node to a given destination is | |||

given destination comprises of two path segments. | comprised of two path segments. | |||

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 Section 2.3.2 of this document, there is no way | proposed in section Section 2.3.2 of this document, there is no way | |||

to determine the path characteristics for the second path segment | to determine the path characteristics for the second path segment | |||

(i.e from the PQ-node to the destination). In the absence of the | (i.e from the PQ-node to the destination). In the absence of the | |||

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

alternate path may be equally preferred based on the first path | alternate path may be equally preferred based on the first path | |||

segments characteristics only, although the second path segment | segments characteristics only, although the second path segment | |||

skipping to change at page 14, line 35 | skipping to change at page 14, line 34 | |||

the computational complexity within affordable limits. However if | the computational complexity within affordable limits. However if | |||

the alternate-selection policy is very restrictive this may leave few | the alternate-selection policy is very restrictive this may leave few | |||

destinations in the entire toplogy without protection. Yet this | destinations in the entire toplogy without protection. Yet this | |||

limitation provides a necessary tradeoff between extensive coverage | limitation provides a necessary tradeoff between extensive coverage | |||

and immense computational overhead. | and immense computational overhead. | |||

4. Acknowledgements | 4. Acknowledgements | |||

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

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

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

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

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

N/A. - No protocol changes are proposed in this document. | N/A. - No protocol changes are proposed in this document. | |||

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

7.1. Normative References | 7.1. Normative References | |||

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||

Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, | |||

DOI 10.17487/RFC2119, March 1997, | ||||

<http://www.rfc-editor.org/info/rfc2119>. | ||||

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

[I-D.ietf-rtgwg-lfa-manageability] | [I-D.ietf-rtgwg-lfa-manageability] | |||

Litkowski, S., Decraene, B., Filsfils, C., Raza, K., | Litkowski, S., Decraene, B., Filsfils, C., Raza, K., | |||

Horneffer, M., and p. psarkar@juniper.net, "Operational | Horneffer, M., and P. Sarkar, "Operational management of | |||

management of Loop Free Alternates", draft-ietf-rtgwg-lfa- | Loop Free Alternates", draft-ietf-rtgwg-lfa- | |||

manageability-03 (work in progress), February 2014. | manageability-11 (work in progress), June 2015. | |||

[I-D.ietf-rtgwg-remote-lfa] | [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for | |||

Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. | IP Fast Reroute: Loop-Free Alternates", RFC 5286, | |||

Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-06 | DOI 10.17487/RFC5286, September 2008, | |||

(work in progress), May 2014. | <http://www.rfc-editor.org/info/rfc5286>. | |||

[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast | [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. | |||

Reroute: Loop-Free Alternates", RFC 5286, September 2008. | So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", | |||

RFC 7490, DOI 10.17487/RFC7490, April 2015, | ||||

<http://www.rfc-editor.org/info/rfc7490>. | ||||

Authors' Addresses | Authors' Addresses | |||

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

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

Electra, Exora Business Park | Electra, Exora Business Park | |||

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

India | India | |||

Email: psarkar@juniper.net | Email: pushpasis.ietf@gmail.com; psarkar@juniper.net | |||

Hannes Gredler | ||||

Juniper Networks, Inc. | ||||

1194 N. Mathilda Ave. | ||||

Sunnyvale, CA 94089 | ||||

US | ||||

Email: hannes@juniper.net | ||||

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

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

Hannes Gredler | ||||

Unaffiliated | ||||

Email: hannes@gredler.at | ||||

Stephane Litkowski | Stephane Litkowski | |||

Orange | Orange | |||

Email: stephane.litkowski@orange.com | Email: stephane.litkowski@orange.com | |||

Harish Raghuveer | ||||

Email: harish.r.prabhu@gmail.com | ||||

End of changes. 45 change blocks. | ||||

126 lines changed or deleted | | 127 lines changed or added | ||

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