idnits 2.17.00 (12 Aug 2021) /tmp/idnits45893/draft-psarkar-rtgwg-rlfa-node-protection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-rtgwg-remote-lfa]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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-protection for destinations E and F. In the event of the node-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 to provide node-protection for a given destination, it is mandatory that, the shortest path from the given PQ-node to the given destination MUST not traverse the primary nexthop. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 G, 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 nexthop, in the event of the node-failure on primary nexthop E, the alternate path from S to R-LFA nexthop R3 also becomes unavailable. So for a Remote-LFA nexthop to provide node-protection for a given destination, it is also mandatory that, the shortest path from S to the chosen PQ-node MUST not traverse the primary nexthop node. -- The document date (November 18, 2013) is 3105 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.litkowski-rtgwg-node-protect-remote-lfa' is defined on line 631, but no explicit reference was found in the text == Outdated reference: draft-ietf-rtgwg-lfa-manageability has been published as RFC 7916 == Outdated reference: draft-ietf-rtgwg-remote-lfa has been published as RFC 7490 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group P. Sarkar, Ed. 3 Internet-Draft H. Gredler 4 Intended status: Standards Track S. Hegde 5 Expires: May 22, 2014 H. Raghuveer 6 C. Bowers 7 Juniper Networks, Inc. 8 S. Litkowski 9 Orange 10 November 18, 2013 12 Remote-LFA Node Protection and Manageability 13 draft-psarkar-rtgwg-rlfa-node-protection-02 15 Abstract 17 The loop-free alternates computed following the current Remote-LFA 18 [I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link- 19 protection. The resulting Remote-LFA nexthops (also called PQ- 20 nodes), may not gaurantee node-protection for all destinations being 21 protected by it. 23 This document describes procedures for determining if a given PQ-node 24 provides node-protection for a specific destination or not. The 25 document also shows how the same procedure can be utilised for 26 collection of complete characteristics for alternate paths. 27 Knowledge about the characteristics of all alternate path is 28 precursory to apply operator defined policy for eliminating paths not 29 fitting constraints. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 22, 2014. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 3 73 2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 74 2.2. Few Additional Definitions . . . . . . . . . . . . . . . 5 75 2.2.1. Link-Protecting Extended P-Space . . . . . . . . . . 5 76 2.2.2. Node-Protecting Extended P-Space . . . . . . . . . . 6 77 2.2.3. Q-Space . . . . . . . . . . . . . . . . . . . . . . . 7 78 2.2.4. Link-Protecting PQ Space . . . . . . . . . . . . . . 7 79 2.2.5. Candidate Node-Protecting PQ Space . . . . . . . . . 7 80 2.3. Computing Node-protecting R-LFA Path . . . . . . . . . . 7 81 2.3.1. Computing Candidate Node-protecting PQ-Nodes for 82 Primary nexthops . . . . . . . . . . . . . . . . . . 8 83 2.3.2. Computing node-protecting paths from PQ-nodes to 84 destinations . . . . . . . . . . . . . . . . . . . . 9 85 2.3.3. Limiting extra computational overhead . . . . . . . . 12 86 3. Manageabilty of Remote-LFA Alternate Paths . . . . . . . . . 12 87 3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 12 88 3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 13 89 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 94 7.2. Informative References . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] specification provides 100 loop-free alternates that gaurantees only link-protection. The 101 resulting Remote-LFA alternate nexthops (also referred to as the PQ- 102 nodes) may not provide node-protection for all destinations covered 103 by the same, in case of failure of the primary nexthop node. Neither 104 does the specification provide a means to determine the same. 106 Also, the LFA Manageability [I-D.ietf-rtgwg-lfa-manageability] 107 document, requires a computing router to find all possible (including 108 all possible Remote-LFA) alternate nexthops, collect the complete set 109 of path characteristics for each alternate path, run a alternate- 110 selection policy (configured by the operator), and find the best 111 alternate path. This will require the Remote-LFA implementation to 112 gather all the required path characteristics along each link on the 113 entire Remote-LFA alternate path. 115 With current LFA [RFC5286] and Remote-LFA implementations, the 116 forward SPF (and reverse SPF) is run on the computing router and its 117 immediate 1-hop routers as the roots. While that enables computation 118 of path attributes (e.g. SRLG, Admin-groups) for first alternate path 119 segment from the computing router to the PQ-node, there is no means 120 for the computing router to gather any path attributes for the path 121 segment from the PQ-node to destination. Consecutively any policy- 122 based selection of alternate paths will consider only the path 123 attributes from the computing router up until the PQ-node. 125 This document describes a procedure for determining node-protection 126 with Remote-LFA. The same procedure are also extended for collection 127 of complete set of path attributes, enabling more accurate policy- 128 based selection for alternate paths obtained with Remote-LFA. 130 2. Node Protection with Remote-LFA 132 2.1. The Problem 134 To better illustrate the problem and the solution proposed in this 135 document the following topology diagram from the Remote-LFA 136 [I-D.ietf-rtgwg-remote-lfa] draft is being re-used with slight 137 modification. 139 D1 140 / 141 S-x-E 142 / \ 143 N R3--D2 144 \ / 145 R1---R2 147 Figure 1: Topology 1 149 In the above topology, for all (non-ECMP) destinations reachable via 150 the S-E link there is no standard LFA alternate. As per the Remote- 151 LFA [I-D.ietf-rtgwg-remote-lfa] alternate specifications node R2 152 being the only PQ-node for the S-E link provides nexthop for all the 153 above destinations. Table 1 below, shows all possible primary and 154 Remote-LFA alternate paths for each destination. 156 +-------------+--------------+---------+-------------------------+ 157 | Destination | Primary Path | PQ-node | Remote-LFA Backup Path | 158 +-------------+--------------+---------+-------------------------+ 159 | R3 | S->E->R3 | R2 | S=>N=>R1=>R2->R3 | 160 | E | S->E | R2 | S=>N=>R1=>R2->R3->E | 161 | D1 | S->E->D1 | R2 | S=>N=>R1=>R2->R3->E->D1 | 162 | D2 | S->E->R3->D2 | R2 | S=>N=>R1=>R2->R3->D2 | 163 +-------------+--------------+---------+-------------------------+ 165 Table 1: Remote-LFA backup paths via PQ-node R2 167 A closer look at Table 1 shows that, while the PQ-node R2 provides 168 link-protection for all the destinations, it does not provide node- 169 protection for destinations E and F. In the event of the node-failure 170 on primary nexthop E, the alternate path from Remote-LFA nexthop R2 171 to E and D1 also becomes unavailable. So for a Remote-LFA nexthop to 172 provide node-protection for a given destination, it is mandatory 173 that, the shortest path from the given PQ-node to the given 174 destination MUST not traverse the primary nexthop. 176 In another extension of the topology in Figure 1 let us consider an 177 additional link between N and E. 179 D1 180 / 181 S-x-E 182 / / \ 183 N---+ R3--D2 184 \ / 185 R1---R2 187 Figure 2: Topology 2 189 In the above topology, the S-E link is no more on any of the shortest 190 paths from N to R3. Hence R3 is also included in both the Extended-P 191 space and PQ space of E (w.r.t S-E link). Table 2 below, shows all 192 possible primary and R-LFA alternate paths via PQ-node R3, for each 193 destination reachable through the S-E link in the above topology. 194 The R-LFA alternate paths via PQ-node R2 remains same as in Table 1. 196 +-------------+--------------+---------+------------------------+ 197 | Destination | Primary Path | PQ-node | Remote-LFA Backup Path | 198 +-------------+--------------+---------+------------------------+ 199 | R3 | S->E->R3 | R3 | S=>N=>E=>R3 | 200 | E | S->E | R3 | S=>N=>E=>R3->E | 201 | D1 | S->E->D1 | R3 | S=>N=>E=>R3->E->D1 | 202 | D2 | S->E->D1 | R3 | S=>N=>E=>R3->D2 | 203 +-------------+--------------+---------+------------------------+ 205 Table 2: Remote-LFA backup paths via PQ-node R3 207 Again a closer look at Table 2 shows that, unlike Table 1, where the 208 single PQ-node R2 provided node-protection, for destinations R3 and 209 G, if we choose R3 as the R-LFA nexthop, it does not provide node- 210 protection for R3 and D1 anymore. If S chooses R3 as the R-LFA 211 nexthop, in the event of the node-failure on primary nexthop E, the 212 alternate path from S to R-LFA nexthop R3 also becomes unavailable. 213 So for a Remote-LFA nexthop to provide node-protection for a given 214 destination, it is also mandatory that, the shortest path from S to 215 the chosen PQ-node MUST not traverse the primary nexthop node. 217 2.2. Few Additional Definitions 219 This document adds and enhances the following definitions extending 220 the ones mentioned in Remote-LFA [I-D.ietf-rtgwg-remote-lfa] draft. 222 2.2.1. Link-Protecting Extended P-Space 224 The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] draft already defines 225 this. The link-protecting extended P-space for a link S-E being 226 protected is the set of routers that are reachable from one or more 227 direct neighbors of S, except primary node E, without traversing the 228 S-E link on any of the shortest path from the direct neighbor to the 229 router. This MUST exclude any direct neighbor for which there is 230 atleast one ECMP path from the direct neighbor traversing the 231 link(S-E) being protected. 233 A node Y is in link-protecting extended P-space w.r.t to the link 234 (S-E) being protected, if and only if, there exists atleast one 235 direct neighbor of S, Ni, other than primary nexthop E, that 236 satisfies the following condition. 238 D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,E) + D_opt(E,Y) 240 Where, 241 D_opt(A,B) : Distance on most optimum path from A to B. 242 E : The primary nexthop on shortest path from S 243 to destination. 244 Ni : A direct neighbor of S other than primary 245 nexthop E. 246 Y : The node being evaluated for link-protecting 247 extended P-Space. 249 Figure 3: Link-Protecting Ext-P-Space Condition 251 2.2.2. Node-Protecting Extended P-Space 253 The node-protecting extended P-space for a primary nexthop node E 254 being protected, is the set of routers that are reachable from one or 255 more direct neighbors of S, except primary node E, without traversing 256 the node E. This MUST exclude any direct neighbors for which there is 257 atleast one ECMP path from the direct neighbor traversing the node E 258 being protected. 260 A node Y is in node-protecting extended P-space w.r.t to the node E 261 being protected, if and only if, there exists atleast one direct 262 neighbor of S, Ni, other than primary nexthop E, that satisfies the 263 following condition. 265 D_opt(Ni,Y) < D_opt(Ni,E) + D_opt(E,Y) 267 Where, 268 D_opt(A,B) : Distance on most optimum path from R1 to B. 269 E : The primary nexthop on shortest path from S 270 to destination. 271 Ni : A direct neighbor of S other than primary 272 nexthop E. 273 Y : The node being evaluated for node-protecting 274 extended P-Space. 276 Figure 4: Node-Protecting Ext-P-Space Condition 278 It must be noted that a node Y satisfying the condition in Figure 4 279 above only guarantees that the R-LFA alternate path segment from S 280 via direct neighbor Ni to the PQ-node Y is not affected in the event 281 of a node failure of E. It does not yet guarantee that the path 282 segment from PQ-node Y to the destination is also unaffected by the 283 same failure event. 285 2.2.3. Q-Space 287 The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] draft already defines 288 this. The Q-space for a link S-E being protected is the set of 289 routers that can reach primary node E, without traversing the S-E 290 link on any of the shortest path from the node Y to primary nexthop 291 E. This MUST exclude any destination for which there is atleast one 292 ECMP path from the node Y to the primary nexthop E traversing the 293 link(S-E) being protected. 295 A node Y is in Q-space w.r.t to the link (S-E) being protected, if 296 and only if, the following condition is satisfied. 298 D_opt(Y,E) < D_opt(S,E) + D_opt(Y,S) 300 Where, 301 D_opt(A,B) : Distance on most optimum path from R1 to B. 302 E : The primary nexthop on shortest path from S 303 to destination. 304 Y : The node being evaluated for Q-Space. 306 Figure 5: Q-Space Condition 308 2.2.4. Link-Protecting PQ Space 310 A node Y is in link-protecting PQ space w.r.t to the link (S-E) being 311 protected, if and only if, Y is present in both link-protecting 312 extended P-space and the Q-space for the link being protected. 314 2.2.5. Candidate Node-Protecting PQ Space 316 A node Y is in candidate node-protecting PQ space w.r.t to the node 317 (E) being protected, if and only if, Y is present in both node- 318 protecting extended P-space and the Q-space for the link being 319 protected. 321 Again it must be noted that a node Y being in candidate node- 322 protecting PQ-space does not guarantee that the R-LFA alternate path 323 via the same, in entirety, is unaffected in the event of a node 324 failure of primary nexthop node E. It only guarantees that the path 325 segment from S to PQ-node Y is unaffected by the same failure event. 326 The PQ-nodes in the candidate node-protecting PQ space may provide 327 node protection for only a subset of destinations that are reachable 328 through the corresponding primary link. 330 2.3. Computing Node-protecting R-LFA Path 331 The R-LFA alternate path through a given PQ-node to a given 332 destination comprises of two path segments as follows. 334 1. Path segment from the computing router to the PQ-node (Remote-LFA 335 alternate nexthop), and 337 2. Path segment from the PQ-node to the destination being protected. 339 So to ensure a R-LFA alternate path for a given destination provides 340 node-protection we need to ensure that none of the above path 341 segments are unaffected in the event of failure of the primary 342 nexthop node. Sections Section 2.3.1 and Section 2.3.2 shows how 343 this can be ensured. 345 2.3.1. Computing Candidate Node-protecting PQ-Nodes for Primary 346 nexthops 348 To choose a node-protecting R-LFA nexthop for a destination R3, 349 router S needs to consider a PQ-node from the candidate node- 350 protecting PQ-space for the primary nexthop E on shortest path from S 351 to R3. As mentioned in Section 2.2.2, to consider a PQ-node as 352 candidate node-protecting PQ-node, there must be atleast one direct 353 neighbor Ni of S, such that all shortest paths from Ni to the PQ-node 354 does not traverse primary nexthop node E. 356 Implementations should run the inequality in Section 2.2.2 Figure 4 357 for all direct neighbor, other than primary nexthop node E, to 358 determine whether a PQ-node Y is also a candidate node-protecting PQ- 359 node. All of the metrics needed by this inequality would have been 360 already collected from the forward SPFs rooted at each of direct 361 neighbor S, computed as part of standard LFA [RFC5286] 362 implementation. With reference to the topology in Figure 2, Table 3 363 below shows how the above condition can be used to determine the 364 candidate node-protecting PQ-space for S-E link (primary nexthop E) 366 +-----------+----------+----------+----------+---------+------------+ 367 | PQ-node | Direct | D_opt | D_opt | D_opt | Condition | 368 | (Y) | Nbr (Ni) | (Ni,Y) | (Ni,E) | (E,Y) | Met | 369 +-----------+----------+----------+----------+---------+------------+ 370 | R2 | N | 2 (N,R2) | 1 (N,E) | 2 | Yes | 371 | | | | | (E,R2) | | 372 | R3 | N | 2 (N,R3) | 1 (N,E) | 1 | No | 373 | | | | | (E,R3) | | 374 +-----------+----------+----------+----------+---------+------------+ 376 Table 3: Node-protection evaluation for R-LFA repair tunnel to PQ- 377 node 379 As seen in the above Table 3 , R3 does not meet the node-protecting 380 extended-p-space inequality And so, while R2 is in candidate node- 381 protecting PQ space, R3 is not. 383 Some SPF implementations may also produce a list of links and nodes 384 traversed on the shortest path(s) from a given root to others. In 385 such implementations, router S may have executed a forward SPF with 386 each of it's direct neighbors as the SPF root, executed as part of 387 the standard LFA [RFC5286] computations. So S may re-use the list of 388 links and nodes collected from the same SPF computations, to decide 389 whether a PQ-node Y is a candidate node-protecting PQ-node or not. A 390 PQ-node Y shall be considered as a node-protecting, if and only if, 391 there is atleast one direct neighbor of S, other than the primary 392 nexthop E, for which, the primary nexthop node E does not exist on 393 the list of nodes traversed on any of the shortest path(s) from the 394 direct neighbor to the PQ-node. Table 4 below is an illustration of 395 the mechanism with the topology in Figure 2. 397 +------------+------------------+-----------------+-----------------+ 398 | PQ-node | Repair Tunnel | Link-Protection | Node-Protection | 399 | | Path(Repairing | | | 400 | | router to PQ- | | | 401 | | node) | | | 402 +------------+------------------+-----------------+-----------------+ 403 | R2 | S->N->R1->R2 | Yes | Yes | 404 | R2 | S->E->R3->R2 | No | No | 405 | R3 | S->N->E->R3 | Yes | No | 406 +------------+------------------+-----------------+-----------------+ 408 Table 4: Protection of Remote-LFA tunnel to the PQ-node 410 As seen in the above Table 4 while R2 is candidate node-protecting 411 Remote-LFA nexthop for R3 and G, it is not so for E and F, since the 412 primary nexthop E is in the shortest path from R2 to E and F. 414 2.3.2. Computing node-protecting paths from PQ-nodes to destinations 416 Once a computing router finds all the candidate node-protecting PQ- 417 nodes for a given directly attached primary link, it shall follow the 418 procedure in proposed in this section, to choose one or more node- 419 protecting R-LFA paths, for destinations reachable through the same 420 primary link in the primary SPF graph. 422 To find a node-protecting R-LFA path for a given destination, the 423 computing router needs to pick a subset of PQ-nodes from the 424 candidate node-protecting PQ-space for the corresponding primary 425 nexthop, such that all the path(s) from the PQ-node(s) to the given 426 destination remain unaffected in the event of a node failure of 427 primary nexthop node. To ensure this, the computing router will need 428 to ensure that, the primary nexthop node should not be on any of the 429 shortest paths from the PQ-node to the given destination. 431 This document proposes an additional forward SPF computation for each 432 of the PQ-nodes, to discover all shortest paths from the PQ-nodes to 433 the destination. The additional forward SPF computation for each PQ- 434 node, shall help determine, if a given primary nexthop node is on the 435 shortest paths from the PQ-node to the given destination or not. To 436 determine if a given PQ-node provides node-protecting alternate for a 437 given destination, the primary nexthop node should not be on any of 438 the shortest paths from the PQ-node to the given destination. After 439 running the forward SPF on a PQ-node (from the node-protecting PQ- 440 space) the computing router shall run the inequality in Figure 6 441 below. PQ-nodes that does not qualify the condition for a given 442 destination, does not gaurantee node-protection for the path segment 443 from the PQ-node to the given destination. 445 D_opt(Y,D) < D_opt(Y,E) + Distance_opt(E,D) 447 Where, 448 D_opt(A,B) : Distance on most optimum path from R1 to B. 449 D : The destination node. 450 E : The primary nexthop on shortest path from S 451 to destination. 452 Y : The node-protecting PQ-node being evaluated 454 Figure 6: Node-Protecting Condition for PQ-node to Destination 456 All of the above metric costs except D_opt(Y, D), can be obtained 457 with forward and reverse SPFs with E(the primary nexthop) as the 458 root, run as part of the regular LFA and Remote-LFA implementation. 459 The Distance_opt(Y, D) metric can only be determined by the 460 additional forward SPF run with PQ-node Y as the root. With 461 reference to the topology in Figure 2, Table 5 below shows how the 462 above condition can be used to determine node-protection with node- 463 protecting PQ-node R2. 465 +-------------+------------+---------+---------+--------+-----------+ 466 | Destination | Primary-NH | D_opt | D_opt | D_opt | Condition | 467 | (D) | (E) | (Y, D) | (Y, E) | (E, D) | Met | 468 +-------------+------------+---------+---------+--------+-----------+ 469 | R3 | E | 1 (C,D) | 2 (C,E) | 1 | Yes | 470 | | | | | (E,D) | | 471 | E | E | 2 (C,E) | 2 (C,E) | 0 | No | 472 | | | | | (E,E) | | 473 | D1 | E | 3 (C,F) | 2 (C,E) | 1 | No | 474 | | | | | (E,F) | | 475 | D2 | E | 2 (C,G) | 2 (C,E) | 1 | Yes | 476 | | | | | (E,G) | | 477 +-------------+------------+---------+---------+--------+-----------+ 479 Table 5: Node-protection evaluation for R-LFA path segment between 480 PQ-node and destination 482 As seen in the above example above, R2 does not meet the node- 483 protecting inequality for destination E, and F. And so, once again, 484 while R2 is a node-protecting Remote-LFA nexthop for R3 and G, it is 485 not so for E and F. 487 In SPF implementations that also produce a list of links and nodes 488 traversed on the shortest path(s) from a given root to others, to 489 determine whether a PQ-node provides node-protection for a given 490 destination or not, the list of nodes computed from forward SPF run 491 on the PQ-node, for the given destination, should be inspected. In 492 case the list contains the primary nexthop node, the PQ-node does not 493 provide node-protection. Else, the PQ-node guarantees node- 494 protecting alternate for the given destination. Below is an 495 illustration of the mechanism with candidate node-protecting PQ-node 496 R2 in the topology in Figure 2. 498 +-------------+-----------------+-----------------+-----------------+ 499 | Destination | Shortest Path | Link-Protection | Node-Protection | 500 | | (Repairing | | | 501 | | router to PQ- | | | 502 | | node) | | | 503 +-------------+-----------------+-----------------+-----------------+ 504 | R3 | R2->R3 | Yes | Yes | 505 | E | R2->R3->E | Yes | No | 506 | D1 | R2->R3->E->D1 | Yes | No | 507 | D2 | R2->R3->D2 | Yes | Yes | 508 +-------------+-----------------+-----------------+-----------------+ 510 Table 6: Protection of Remote-LFA path between PQ-node and 511 destination 513 As seen in the above example while R2 is candidate node-protecting 514 R-LFA nexthop for R3 and G, it is not so for E and F, since the 515 primary nexthop E is in the shortest path from R2 to E and F. 517 The procedure described in this document helps no more than to 518 determine whether a given Remote-LFA alternate provides node- 519 protection for a given destination or not. It does not find out any 520 new Remote-LFA alternate nexthops, outside the ones already computed 521 by standard Remote-LFA procedure. However, in case of availability 522 of more than one PQ-node (Remote-LFA alternates) for a destination, 523 and node-protection is required for the given primary nexthop, this 524 procedure will eliminate the PQ-nodes that do not provide node- 525 protection and choose only the ones that does. 527 2.3.3. Limiting extra computational overhead 529 In addition to the extra reverse SPF computation, one per directly 530 connected neighbor, suggested by the Remote-LFA 531 [I-D.ietf-rtgwg-remote-lfa] draft, this document proposes a forward 532 SPF per PQ-node discovered in the network. Since the average number 533 of PQ-nodes found in any network is considerably more than the number 534 of direct neighbors of the computing router, the proposal of running 535 one forward SPF per PQ-node may add considerably to the overall SPF 536 computation time. 538 To limit the computational overhead of the approach proposed, this 539 document proposes that implementations MUST choose a subset from the 540 entire set of PQ-nodes computed in the network, with a finite limit 541 on the number of PQ-nodes in the subset. Implementations MUST choose 542 a default value for this limit and may provide user with a 543 configuration knob to override the default limit. Implementations 544 MUST also evaluate some default preference criteria while considering 545 a PQ-node in this subset. Finally, implementations MAY also allow 546 user to override the default preference criteria, by providing a 547 policy configuration for the same. 549 A suggested default criteria for PQ-node selection will be to put a 550 score on each PQ-node, proportional to the number of primary 551 interfaces and remote destination routers being protected by it, and 552 then pick PQ-nodes based on this score. A more appropriate 553 heuristsics can be devised, based on in-depth study of coverage 554 provided by R-LFA, in the networks where they are mostly deployed. 555 The same can then be used for PQ-node selection. 557 Once a subset of PQ-nodes is found, computing router shall run a 558 forward SPF on each of the PQ-nodes in the subset to continue with 559 procedures proposed in section Section 2.3.2. 561 3. Manageabilty of Remote-LFA Alternate Paths 563 3.1. The Problem 565 With the regular Remote-LFA [I-D.ietf-rtgwg-remote-lfa] functionality 566 the computing router may compute more than one PQ-node as usable 567 Remote-LFA alternate nexthops. Additionally an alternate selection 568 policy may be configured to enable the network operator to choose one 569 of them as the most appropriate Remote-LFA alternate. For such 570 policy-based alternate selection to run, all the relevant path 571 characteristics for each the alternate paths (one through each of the 572 PQ-nodes), needs to be collected. As mentioned befor in section 573 Section 2.3 the R-LFA alternate path through a given PQ-node to a 574 given destination comprises of two path segments. 576 The first path segment (i.e. from the computing router to the PQ- 577 node) can be calculated from the regular forward SPF done as part of 578 standard and remote LFA computations. However without the mechanism 579 proposed in section Section 2.3.2 of this document, there is no way 580 to determine the path characteristics for the second path segment 581 (i.e from the PQ-node to the destination). In the absence of the 582 path characteristics for the second path segment, two Remote-LFA 583 alternate path may be equally preferred based on the first path 584 segments characteristics only, although the second path segment 585 attributes may be different. 587 3.2. The Solution 589 The additional forward SPF computation proposed in section 590 Section 2.3.2 document shall also collect links, nodes and path 591 characteristics along the second path segment. This shall enable 592 collection of complete path characteristics for a given Remote-LFA 593 alternate path to a given destination. The complete alternate path 594 characteristics shall then facilitate more accurate alternate path 595 selection while running the alternate selection policy. 597 4. Acknowledgements 599 Many thanks to Bruno Decraene for his useful comments. 601 5. IANA Considerations 603 N/A. - No protocol changes are proposed in this document. 605 6. Security Considerations 607 This document does not introduce any change in any of the protocol 608 specifications. It simply proposes to run an extra SPF rooted on 609 each PQ-node discovered in the whole network. 611 7. References 613 7.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 7.2. Informative References 620 [I-D.ietf-rtgwg-lfa-manageability] 621 Litkowski, S., Decraene, B., Filsfils, C., and K. Raza, 622 "Operational management of Loop Free Alternates", draft- 623 ietf-rtgwg-lfa-manageability-00 (work in progress), May 624 2013. 626 [I-D.ietf-rtgwg-remote-lfa] 627 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 628 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02 629 (work in progress), May 2013. 631 [I-D.litkowski-rtgwg-node-protect-remote-lfa] 632 Litkowski, S., "Node protecting remote LFA", draft- 633 litkowski-rtgwg-node-protect-remote-lfa-00 (work in 634 progress), April 2013. 636 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 637 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 639 Authors' Addresses 641 Pushpasis Sarkar (editor) 642 Juniper Networks, Inc. 643 Electra, Exora Business Park 644 Bangalore, KA 560103 645 India 647 Email: psarkar@juniper.net 649 Hannes Gredler 650 Juniper Networks, Inc. 651 1194 N. Mathilda Ave. 652 Sunnyvale, CA 94089 653 US 655 Email: hannes@juniper.net 657 Shraddha Hegde 658 Juniper Networks, Inc. 659 Electra, Exora Business Park 660 Bangalore, KA 560103 661 India 663 Email: shraddha@juniper.net 664 Harish Raghuveer 665 Juniper Networks, Inc. 666 Electra, Exora Business Park 667 Bangalore, KA 560103 668 India 670 Email: hraghuveer@juniper.net 672 Chris Bowers 673 Juniper Networks, Inc. 674 1194 N. Mathilda Ave. 675 Sunnyvale, CA 94089 676 US 678 Email: cbowers@juniper.net 680 Stephane Litkowski 681 Orange 683 Email: stephane.litkowski@orange.com