idnits 2.17.00 (12 Aug 2021) /tmp/idnits45990/draft-psarkar-rtgwg-rlfa-node-protection-01.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2013) is 3238 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) == 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 (~~), 4 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: January 9, 2014 H. Raghuveer 6 Juniper Networks, Inc. 7 July 8, 2013 9 Node Protecting R-LFA and Manageability 10 draft-psarkar-rtgwg-rlfa-node-protection-01 12 Abstract 14 The loop-free alternates computed following the current Remote-LFA 15 [I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link- 16 protection. The resulting Remote-LFA nexthops (also called PQ- 17 nodes), may not gaurantee node-protection for all destinations being 18 protected by it. 20 This document describes procedures for determining if a given PQ-node 21 provides node-protection for a specific destination or not. The 22 document also shows how the same procedure can be utilised for 23 collection of complete characteristics for alternate paths. 24 Knowledge about the characteristics of all alternate path is 25 precursory to apply operator defined policy for eliminating paths not 26 fitting constraints. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 4 69 2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. The Solution . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Manageabilty of Remote-LFA Alternate Paths . . . . . . . . . . 8 72 3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . . 8 74 4. Prior Solutions . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Advantage of this Proposal . . . . . . . . . . . . . . . . 9 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] specification provides 87 loop-free alternates that gaurantees only link-protection. The 88 resulting Remote-LFA alternate nexthops (also referred to as the PQ- 89 nodes) may not provide node-protection for all destinations covered 90 by the same, in case of failure of the primary nexthop node. Neither 91 does the specification provide a means to determine the same. 93 Also, the LFA Manageability [I-D.ietf-rtgwg-lfa-manageability] 94 document, requires a computing router to find all possible (including 95 all possible Remote-LFA) alternate nexthops, collect the complete set 96 of path characteristics for each alternate path, run a alternate- 97 selection policy (configured by the operator), and find the best 98 alternate path. This will require the Remote-LFA implementation to 99 gather all the required path characteristics along each link on the 100 entire Remote-LFA alternate path. 102 With current LFA [RFC5286] and Remote-LFA implementations, the 103 forward SPF (and reverse SPF) is run on the computing router and its 104 immediate 1-hop routers as the roots. While that enables computation 105 of path attributes (e.g. SRLG, Admin-groups) first alternate path 106 segment from the computing router PQ-node, there is no means for the 107 computing router to gather any path attributes for the path segment 108 from the PQ-node to destination. Consecutively any policy-based 109 selection of alternate paths will consider only the path attributes 110 from the computing router up until the PQ-node. 112 This document describes a procedure for determining node-protection 113 with Remote-LFA. The same procedure are also extended for collection 114 of complete set of path attributes, enabling more accurate policy- 115 based selection for alternate paths obtained with Remote-LFA. 117 2. Node Protection with Remote-LFA 119 2.1. The Problem 121 To better illustrate the problem and the solution proposed in this 122 document the following topology diagram from the Remote-LFA 123 [I-D.ietf-rtgwg-remote-lfa], draft is being re-used with slight 124 modification. 126 F 127 / 128 S-x-E 129 / \ 130 A D--G 131 \ / 132 B---C 134 Figure 1: Sample Ring Topology 136 In the above topology, for all (non-ECMP) destinations reachable via 137 the S-E link there is no standard LFA alternate. As per the Remote- 138 LFA [I-D.ietf-rtgwg-remote-lfa] alternate specifications node C being 139 the PQ-node for the S-E link provides nexthop for all the above 140 destinations. Table 1 below, shows all possible primary and Remote- 141 LFA alternate paths for each destination. 143 +-------------+--------------+------------------------+ 144 | Destination | Primary Path | Remote-LFA Backup Path | 145 +-------------+--------------+------------------------+ 146 | D | S->E->D | S=>A=>B=>C->D | 147 | E | S->E | S=>A=>B=>C->D->E | 148 | F | S->E->F | S=>A=>B=>C->D->E->F | 149 | G | S->E->D->G | S=>A=>B=>C->D->G | 150 +-------------+--------------+------------------------+ 152 Table 1: Backup paths with Remote-LFA 154 A closer look at Table 1 shows that, while the PQ-node C provides 155 link-protection for all the destinations, it does not provide node- 156 protection for destinations E and F. In the event of the node-failure 157 on primary nexthop E, the alternate path from Remote-LFA nexthop C to 158 E and F also becomes unavailable. So for a Remote-LFA nexthop to 159 provide node-protection for a given destination, it is mandatory 160 that, the shortest path from the given PQ-node to the given 161 destination must not traverse the primary nexthop. 163 2.2. The Solution 165 This document proposes an additional forward SPF computation for each 166 of the PQ-nodes, as a mechanism to provide node-protection with 167 remote LFA. In case, a alternate selection policy has been 168 configured, the mechanism proposed, shall also provide a means to 169 collect complete path attributes for the alternate path via a Remote- 170 LFA nexthop to a given destination. 172 The additional forward SPF computation for each PQ-node, shall help 173 determine, if a given primary nexthop node is on shortest paths from 174 a given PQ-node to any given destination or not. To determine if a 175 given PQ-node provides node-protecting alternate for a given 176 destination, the primary nexthop node should not be on any of the 177 shortest paths from the given PQ-node to the given destination. 179 Some SPF implementations may produce a list of links and nodes 180 traversed on the shortest path(s) from a given root to others. In 181 such implementations, running a forward SPF rooted at a given PQ-node 182 will produce a list of nodes (one per each destination), on one or 183 more shortest path(s) from the PQ-node to other destinations in the 184 network. To determine whether a PQ-node provides node-protection for 185 a given destination or not, the list of nodes computed from forward 186 SPF run on the PQ-node, for the given destination, should be 187 inspected. In case the list contains the primary nexthop node, the 188 PQ-node does not provide node-protection. Else, the PQ-node 189 guarantees node-protecting alternate for the given destination. 190 Below is an illustration of the mechanism with the topology in 191 Figure 1. 193 +-----------+--------+------------+----------------+----------------+ 194 | Destinati | PQ-nod | Shortest | Link-Protectio | Node-Protectio | 195 | on | e | Path(PQ-no | n | n | 196 | | | de to | | | 197 | | | Dest) | | | 198 +-----------+--------+------------+----------------+----------------+ 199 | D | C | C->D | Yes | Yes | 200 | E | C | C->D->E | Yes | No | 201 | F | C | C->D->E->F | Yes | No | 202 | G | C | C->D->G | Yes | Yes | 203 +-----------+--------+------------+----------------+----------------+ 205 Table 2: Types of protection with Remote-LFA 207 As seen in the above example while C is node-protecting Remote-LFA 208 nexthop for D and G, it is not so for E and F, since the primary 209 nexthop E is in the shortest path from C to E and F. 211 Alternatively, an implementation may also run the node-protection 212 condition from the LFA [RFC5286] specification with slight 213 modification as shown in Figure 2 below. PQ-nodes that does not 214 qualify the condition for a given destination, does not gaurantee 215 node-protection for the same. 217 D_opt(Npq, Dst) < D_opt(Npq, Np) + Distance_opt(Np, Dst) 219 - D_opt(X, Y) : Distance on most optimum path from X to Y. 220 - Npq : The PQ-node being considered. 221 - Dst : The destination being protected. 222 - Np : The primary nexthop node on shortest path 223 from computing router to destination. 225 Figure 2: Node-Protection Condition for Remote-LFA 227 All of the above metric costs except D_opt(Npq, Dst), can be obtained 228 with forward and reverse SPFs with Np(the primary nexthop) as the 229 root, run as part of the regular LFA and Remote-LFA implementation. 230 The Distance_opt(Npq, Dst) metric can only be determined by the 231 additional forward SPF run with Npq(PQ-node) as the root. With 232 reference to the topology in Figure 1, Table 3 below shows how the 233 above condition can be used to determine node-protection with a PQ- 234 node. 236 +-----------+----------+--------+-------+-------+-------+-----------+ 237 | Destinati | Primary- | PQ-nod | D_opt | D_opt | D_opt | Condition | 238 | on (Dst) | NH (Np) | e | (Npq, | (Npq, | (Np, | Met | 239 | | | (Npq) | Dst) | Np) | Dst) | | 240 +-----------+----------+--------+-------+-------+-------+-----------+ 241 | D | E | C | 1 | 1 | 1 | Yes | 242 | E | E | C | 2 | 2 | 0 | No | 243 | F | E | C | 3 | 2 | 1 | No | 244 | G | E | C | 2 | 2 | 1 | Yes | 245 +-----------+----------+--------+-------+-------+-------+-----------+ 247 Table 3: Using Node-protecting condition for Remote-LFA 249 As seen in the above example above, C does not meet the node- 250 protecting inequality for destination E, and F. And so, once again, 251 while C is a node-protecting Remote-LFA nexthop for D and G, it is 252 not so for E and F. 254 The procedure described in this document helps no more than to 255 determine whether a given Remote-LFA alternate provides node- 256 protection for a given destination or not. It does not find out any 257 new Remote-LFA alternate nexthops, outside the ones already computed 258 by standard Remote-LFA procedure. However, in case of availability 259 of more than one PQ-node (Remote-LFA alternates) for a destination, 260 and node-protection is required for the given primary nexthop, this 261 procedure will eliminate the PQ-nodes that do not provide node- 262 protection and choose only the ones that does. 264 3. Manageabilty of Remote-LFA Alternate Paths 266 3.1. The Problem 268 With the regular Remote-LFA functionality the computing router may 269 compute more than one PQ-node as usable Remote-LFA alternate 270 nexthops. Additionally a alternate selection policy may be 271 configured to enable the network operator to choose one of them as 272 the most appropriate Remote-LFA alternate. For such policy-based 273 alternate selection to run, all the relevant path characteristics for 274 each the alternate paths (one through each of the PQ-nodes), needs to 275 be collected. The Remote-LFA alternate path through a given PQ-node 276 to a given destination comprises of two path segments as follows. 278 1. Path segment from the computing router to the PQ-node (Remote-LFA 279 alternate nexthop), and 281 2. Path segment from the PQ-node to the destination being protected. 283 The first Path segment can be calculated from the regular forward SPF 284 done as part of standard and remote LFA computations. However 285 without the mechanism proposed in this document, there is no way to 286 determine the path characteristics for the second path segment. In 287 the absence of the path characteristics for the second path segment, 288 two Remote-LFA alternate path may be equally preferred based on the 289 first path segments characteristics only, although the second path 290 segment attributes may be different. 292 3.2. The Solution 294 The additional forward SPF computation being proposed in this 295 document shall also collect links, nodes and path characteristics 296 along the second path segment. This shall enable collection of 297 complete path characteristics for a given Remote-LFA alternate path 298 to a given destination. The complete alternate path characteristics 299 shall then facilitate more accurate alternate path selection while 300 running the alternate selection policy. 302 4. Prior Solutions 304 A recent Node Protecting Remote-LFA 305 [I-D.litkowski-rtgwg-node-protect-remote-lfa] draft proposes a 306 solution for providing node-protection with Remote-LFA. It requires 307 the computing router to additionally run reverse SPFs rooted at the 308 nextnexthop routers (i.e. all the 2-hop neighborhood) as well. A 309 simple study of standard IGP network topologies in real-life 310 deployments shall reveal that, the increase in the number of required 311 SPF computations is exponential, and can be a substantial computation 312 overhead. 314 4.1. Advantage of this Proposal 316 Following are the advantages of the mechanism proposed in this 317 document. 319 o The recent Remote-LFA node-protection document 320 [I-D.litkowski-rtgwg-node-protect-remote-lfa] proposes an extra 321 reverse SPF computation for each nextnexthop of the computing 322 router. The mechanism in this document proposes an extra forward 323 SPF for each of the PQ-nodes. Considering some of the standard 324 IGP network topologies in real-life service-provider deployments, 325 the number of nextnexthops will be substantially higher than the 326 number of PQ-nodes discovered in those topologies. Hence the 327 number of additional SPFs required in the proposed mechanism in 328 this document will be considerably less compared to the procedures 329 outlined in [I-D.litkowski-rtgwg-node-protect-remote-lfa], and 330 imply less computational overhead. 332 o Also the extra reverse SPF proposed per nextnexthop in Remote-LFA 333 node-protection [I-D.litkowski-rtgwg-node-protect-remote-lfa] 334 specification does not provide a means to collect the path 335 characteristics for the alternate path segment from the PQ-node to 336 the destination. The additional forward SPF for each PQ-node, as 337 proposed in this document facilitates the same. 339 5. Acknowledgements 341 Many thanks to Bruno Decraene and Stephane Litkowski for their useful 342 comments. 344 6. IANA Considerations 346 N/A. - No protocol changes are proposed in this document. 348 7. Security Considerations 350 This document does not introduce any change in any of the protocol 351 specifications. It simply proposes to run an extra SPF rooted on 352 each PQ-node discovered in the whole network. 354 8. References 355 8.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 8.2. Informative References 362 [I-D.ietf-rtgwg-lfa-manageability] 363 Litkowski, S., Decraene, B., Filsfils, C., and K. Raza, 364 "Operational management of Loop Free Alternates", 365 draft-ietf-rtgwg-lfa-manageability-00 (work in progress), 366 May 2013. 368 [I-D.ietf-rtgwg-remote-lfa] 369 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 370 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02 371 (work in progress), May 2013. 373 [I-D.litkowski-rtgwg-node-protect-remote-lfa] 374 Litkowski, S., "Node protecting remote LFA", 375 draft-litkowski-rtgwg-node-protect-remote-lfa-00 (work in 376 progress), April 2013. 378 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 379 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 381 Authors' Addresses 383 Pushpasis Sarkar (editor) 384 Juniper Networks, Inc. 385 Electra, Exora Business Park 386 Bangalore, KA 560103 387 India 389 Email: psarkar@juniper.net 391 Hannes Gredler 392 Juniper Networks, Inc. 393 1194 N. Mathilda Ave. 394 Sunnyvale, CA 94089 395 US 397 Email: hannes@juniper.net 398 Shraddha Hegde 399 Juniper Networks, Inc. 400 Electra, Exora Business Park 401 Bangalore, KA 560103 402 India 404 Email: shraddha@juniper.net 406 Harish Raghuveer 407 Juniper Networks, Inc. 408 Electra, Exora Business Park 409 Bangalore, KA 560103 410 India 412 Email: hraghuveer@juniper.net