idnits 2.17.00 (12 Aug 2021) /tmp/idnits38651/draft-litkowski-rtgwg-node-protect-remote-lfa-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 (April 2, 2013) is 3329 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-remote-lfa has been published as RFC 7490 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group S. Litkowski 3 Internet-Draft Orange 4 Intended status: Standards Track April 2, 2013 5 Expires: October 4, 2013 7 Node protecting remote LFA 8 draft-litkowski-rtgwg-node-protect-remote-lfa-00 10 Abstract 12 This draft describes a simple extension to the remote LFA 13 specification that computes a guaranteed node protection. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in [RFC2119]. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 4, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Reference topology . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Current RLFA behavior . . . . . . . . . . . . . . . . . . . 4 59 2.3. Guaranteed node protection computation . . . . . . . . . . 4 60 2.3.1. Computing node protecting extended P-Space . . . . . . 5 61 2.3.2. Computing node protecting Q-Space . . . . . . . . . . . 5 62 2.3.3. Computing node protecting PQ-Spaces . . . . . . . . . . 5 63 3. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The current RLFA specification described in 73 [I-D.ietf-rtgwg-remote-lfa] is based on a per link computation (for 74 optimization) that prevents determination of guaranteed node 75 protection. This does not mean that the current solution is not able 76 to provide node protection for a specific destination, but as 77 computation is done from the link perspective, there is no guarantee 78 to have node protection. 80 S---E 81 / \ 82 A D 83 \ / 84 B---C 86 Figure 1 88 In the figure above, considering all metrics equal, primary path from 89 S to D is SED. S has no LFA to reach D. 91 Using RLFA specification, C is a PQ from E perspective and could be 92 used as a remote LFA in case of SE failure. In the diagram above, C 93 is a considered as a link protecting alternate (as from E 94 perspective, it is only link protecting), even if from a topological 95 point of view, C would be a node protecting RLFA. 97 There could be multiple reasons to ensure node protection in a 98 network : 100 o Presence of nodes with no high availability mechanism. 102 o Avoiding transient loops in case of node crash. 104 This draft describes a solution to compute a guaranteed node 105 protection using remote LFA solution. 107 2. Specification 108 2.1. Reference topology 110 3 111 N1 ---------- P1 112 | | 113 | 2 | 114 | N3 --- P3 | 115 |/ / | 116 S ---- E ---- R1 --- D1 --- D2 117 | \ | 118 | R2 ----- D3-------+ 119 | / 2 120 N2 ---- P2 121 3 123 Figure 2 125 2.2. Current RLFA behavior 127 The current remote LFA computation is based on computation of 128 extended P-Space and Q-Space and then intersect both to determine PQ 129 nodes that would be used for traffic tunneling. As Q-Space requires 130 rSPF computation (one per Q-Space), it would not be scalable to 131 compute Q-Space for each prefix. RLFA specification is proposing to 132 compute Q Space on a per link basis, PQ will so be used by all 133 prefixes using the link as primary nexthop. 135 Using figure 2 and considering protection of prefixes using E as 136 primary nexthop on S, there would be three nodes in PQ space : 137 P1,P2,P3. Using shortest path to PQ as tie breaker, P3 would be the 138 best PQ. 140 P3 is only providing link protection to D1, D2 and D3 while P1 was 141 providing node protection for D1 and D2, and P2 was providing node 142 protection for D3. 144 In this scenario, RLFA is providing a suboptimal protection because 145 of the approximation of using remote end of the link for computation. 147 2.3. Guaranteed node protection computation 149 To compute a guaranteed node protection using remote LFA, we just 150 introduce a small modification in the current algorithm. Rather than 151 computing link protecting PQs from nexthop perspective, we propose to 152 compute node protecting PQs from nextnexthop perspective. 154 Our proposal is working as follows : 156 o Compute node protecting PQ space for each nextnexthop. 158 o Compute link protecting PQ space for each nexthop (as already 159 done). 161 o Prefixes are inheriting protection type from nexthop or 162 nextnexthop based on defined policies. Choosing a PQ in node 163 protecting space provides guaranteed node protection. 165 2.3.1. Computing node protecting extended P-Space 167 We define the notion of node protecting extended P-Space of a node S 168 for a connected node E as the union of : 170 o Node protecting P-Space : the set of routers reachable from S 171 without traversing node E. 173 o The set of destinations using E as primary nexthop but having a 174 node protecting LFA. 176 2.3.2. Computing node protecting Q-Space 178 The set of routers from which a node N can be reached, by normal 179 forwarding, without traversing the node E is termed the node 180 protecting Q-space of N with respect to the node E. The Q-space can 181 be obtained by computing a reverse shortest path tree (rSPT) rooted 182 at N, with the sub-tree which traverses the failed node excised 183 (including those which are members of an ECMP). 185 2.3.3. Computing node protecting PQ-Spaces 187 Upon termination of regular SPT, node S has knowledge of nexthops and 188 nextnexthops to reach every destinations. For each nextnexthop on 189 the SPT, S will compute : 191 o Node protecting extended P-Space considering nexthop will fail. 193 o Node protecting extended Q-Space from nextnexthop considering 194 nexthop will fail. 196 Intersection of both will result in node protecting PQ-Spaces and 197 node S will have a node protecting PQ-Space for each nextnexthop. 199 In figure 2, considering link SE, S has two nextnexthops (R1 and R2). 200 S will compute node protecting PQ Space for R1 and for R2. 202 Node protecting extended P-Space : 204 o For R1 : P1,N1 206 o For R2 : P2,N2 208 Node protecting Q-Space : 210 o For R1 : P1,D1,D2 212 o For R2 : P2,D3,D2 214 Node protecting PQ-Space : 216 o For R1 : P1 218 o For R2 : P2 220 As a result, P1 is able to provide node protection for all 221 destinations using R1 as nextnexthop (D1,D2). P2 is able to provide 222 node protection for all destinations using R2 as nextnexthop (D3). 224 3. Scaling 226 Approximation introduced in remote LFA specification was done to 227 optimize computation. Our proposal is introducing more computation 228 but in a very acceptable degree. Computation time will be dependent 229 on number of nextnexthops rather than nexthops. 231 +----------+-----+---------+-----+-----------+-----+ 232 | Topology | Min | Average | Med | 95th perc | Max | 233 +----------+-----+---------+-----+-----------+-----+ 234 | T1 | 1 | 20,4 | 19 | 39 | 107 | 235 | T2 | 1 | 9,5 | 6 | 27 | 35 | 236 | T3 | 2 | 15,7 | 11 | 41 | 53 | 237 | T4 | 1 | 13,9 | 15 | 26,5 | 30 | 238 | T5 | 1 | 12 | 8 | 36 | 72 | 239 | T6 | 2 | 4,3 | 4 | 7 | 8 | 240 | T7 | 1 | 9 | 6 | 19 | 22 | 241 +----------+-----+---------+-----+-----------+-----+ 243 Table 1: Number of nextnexthop 245 The simulation results above (from real SP topologies) show that the 246 number of rSPF to compute is really acceptable : SPF takes today only 247 few msec to compute even on large topologies. Moreover installing 248 protection is not an urgent task, and it would be better to take more 249 time to compute a more optimal protection. 251 4. Security Considerations 253 This document does not introduce any change in security consideration 254 compared to [RFC5286] or [I-D.ietf-rtgwg-remote-lfa]. 256 5. Acknowledgements 258 6. IANA Considerations 260 This document has no action for IANA. 262 7. Normative References 264 [I-D.ietf-rtgwg-remote-lfa] 265 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 266 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01 267 (work in progress), December 2012. 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 273 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 275 Author's Address 277 Stephane Litkowski 278 Orange 280 Email: stephane.litkowski@orange.com