idnits 2.17.1 draft-francois-sr-frr-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2013) is 3952 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) -- Looks like a reference, but probably isn't: 'Adjacency' on line 254 -- Looks like a reference, but probably isn't: 'Nodal' on line 254 == Outdated reference: A later version (-01) exists of draft-filsfils-rtgwg-segment-routing-00 ** Downref: Normative reference to an Informational RFC: RFC 5714 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 6571 (ref. '3') == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-02 ** Downref: Normative reference to an Historic draft: draft-bryant-ipfrr-tunnels (ref. '5') Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pierre Francois 3 Internet-Draft IMDEA Networks 4 Intended status: Standards Track Clarence Filsfils 5 Expires: January 2, 2014 Ahmed Bashandy 6 Stefano Previdi 7 Cisco Systems, Inc. 8 Bruno Decraene 9 Orange 10 July 1, 2013 12 Segment Routing Fast Reroute 13 draft-francois-sr-frr-00 15 Abstract 17 This document presents a Fast Reroute approach aimed at providing 18 link protection of nodal and adjacency segments to the Segment 19 Routing framework. This FRR behavior builds on proven IP-FRR 20 concepts being LFAs, remote LFAs (RLFA), and remote LFAs with 21 directed forwarding (DLFA). We describe their implementation using 22 SR segments. We then analyze the benefits brought by Segment Routing 23 to the scalability of such IP-FRR approaches. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 2, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Protection lists . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. LFA based protection list . . . . . . . . . . . . . . . . 4 62 2.2. RLFA based protection list . . . . . . . . . . . . . . . . 4 63 2.3. DLFA based protection list . . . . . . . . . . . . . . . . 5 64 3. Protecting segments . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. The active segment is a node segment . . . . . . . . . . . 5 66 3.2. The active segment is an adjacency segment . . . . . . . . 6 67 3.2.1. Protecting [Adjacency, Adjacency] segment lists . . . 6 68 3.2.2. Protecting [Adjacency, Nodal] segment lists . . . . . 6 69 4. SR FRR benefits in LDP environments . . . . . . . . . . . . . 7 70 4.1. Eliminating Directed LDP Sessions . . . . . . . . . . . . 9 71 4.2. Guaranteed FRR coverage . . . . . . . . . . . . . . . . . 9 72 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Segment Routing aims at supporting services with tight SLA guarantees 78 [1]. Acknowledging this fact, this document provides local repair 79 mechanisms capable of restoring end-to-end connectivity in case of a 80 sudden failure of a link. The FRR behavior builds on proven IP-FRR 81 concepts; we leverage LFAs, remote LFAs (RLFA), and remote LFAs with 82 directed forwarding (DLFA)[2]. 84 In the SR context, not all flows are being routed along the shortest 85 paths defined by the IGP, but also along explicit paths containing 86 Adjacency Segments. We thus accommodate the IP-FRR behavior for SR 87 Adjacency Segments. 89 Through the document, we will observe that performing FRR with SR has 90 the following benefits: 92 - The simplicity properties of LFA FRR [3] are preserved. 93 - The capacity planning properties are preserved [3]. Unlike SDH 94 and other FRR solutions, the repaired packet does not go back to 95 the next-hop or next-next-hop but uses shortest-path forwarding 96 from a much closer release point. 97 - The RLFA operation is simplified: dynamically established 98 directed LDP sessions to the repair nodes are no longer required. 99 - The scalable support for DLFA provides guaranteed coverage for 100 symmetric networks, i.e. networks configured with symmetric link 101 metrics: the repair tunnel in a symmetric network can be encoded 102 efficiently with only two segments. We will observe that only one 103 segment is needed in most cases. 105 A future version of this document will analyze the protection upon 106 node failure. 108 L ____ 109 S----------F--{____}--D 110 _|_ ___________ / 111 {___}--R--{___________} 113 Figure 1: Link Protection 115 We use Figure 1 to illustrate the three objectives that have to be 116 met when implementing SR FRR. 118 First, the protecting router S needs to find a detour path around the 119 protected link. Intuitively, the Point of Local Repair (PLR) needs 120 to find a node R (a repair node) that is capable of safely forwarding 121 the traffic affected by the failure of the protected link L. We 122 leverage the algorithms defined in the IP-FRR framework to achieve 123 this first goal, as explained in Section 2. 125 Second, S must ensure proper forwarding behavior once the packet 126 reaches the repair node R. We define the segment operations to be 127 applied by the protecting node to ensure consistency with the 128 forwarding state of the repair node in Section 3. 130 We will observe, in Section 4, that the MPLS instantiation of SR 131 improves the scalability and operation of the FRR solution by not 132 requiring multi-hop LDP sessions to distant repair nodes. 134 2. Protection lists 136 The protection list is the list of segments encoding a detour path 137 from the protecting node S to the repair node R, avoiding the 138 protected link L. In this section, we define how to encode the LFA, 139 RLFA, and DLFA repair paths with protection lists. These protection 140 lists contain at most two segments. 142 2.1. LFA based protection list 144 According to the LFA FRR approach, if a path to a destination D from 145 a neighbor N of S does not contain S (i.e. N is a loop-free 146 alternate of S for the failure of link S-F), then S can pre-install a 147 repair forwarding information, in order to deviate the packet to N 148 upon the failure of S-F. 150 In the case of LFA applicability, the SR protection list is thus 151 empty. All what a protecting router S needs to do is to send the 152 protected packet as is to its LFA neighbor N. 154 2.2. RLFA based protection list 156 If there is no such LFA neighbor, then S may be able to create a 157 virtual LFA by using a tunnel to carry the packet to a point in the 158 network that is not a direct neighbor of S, and from which the packet 159 will be delivered to the destination without looping back to S. The 160 Remote LFA proposal [4] calls such a tunnel a repair tunnel. The 161 tail-end of this tunnel (R in figure 1) is called a "remote LFA" or a 162 "PQ node". We refer to the RLFA document for the definitions of the 163 P and Q sets. 165 In the case of RLFA applicability for the protection of a segment, 166 the protection list is made of a nodal segment to the PQ node. It 167 thus matches [nodal(PQ), ...] 169 2.3. DLFA based protection list 171 There are some cases where there is no remote LFA coverage for some 172 links/destinations, due to topological properties in the neighborhood 173 of the protecting node. If there is no such RLFA PQ node, we propose 174 to use a Directed LFA (DLFA) repair tunnel to a Q node that is 175 adjacent to the P space [5]. 177 In the case of applicability of RLFA with directed forwarding (DLFA), 178 the protection list is made of a nodal segment to the P node followed 179 by an Adjacency segment to the Q node. It thus matches [nodal(P), 180 Adj(P-->Q), ...] 182 In networks with symmetric IGP metrics (the metric of a link AB is 183 the same as the metric of the reverse link BA), we can prove that 184 either the P and the Q sets intersect or there is at least one P node 185 that is adjacent to a Q node. Thanks to the DLFA extension, we thus 186 have a guaranteed LFA-based FRR technique for any network with 187 symmetric IGP metrics. 189 Future versions of the document will describe the solutions 190 leveraging SR capabilities to provide guaranteed FRR applicability in 191 any IGP topology. 193 3. Protecting segments 195 In this section, we explain how a protecting router S processes the 196 active segment of a packet upon the failure of the primary adjacency 197 along which the packet should be forwarded. The behavior depends on 198 the type of active segment to be protected. 200 3.1. The active segment is a node segment 202 The definition of the protection of a nodal segment is a direct 203 translation of IP-FRR behaviors into the SR terminology. That is, 204 traffic for nodal segment D will be rerouted to a safe node R whose 205 shortest paths for D do not contain the failed component. 207 As nodal segments semantics are known by all nodes of the domain, no 208 specific signaling needs to be done to let R correctly process the 209 detoured packet. A packet whose active segment matches 210 [nodal(D),...], arriving at a protecting node S will leave S with a 211 segment list matching [PS(R), nodal(D),...]. The actual value used 212 to encode nodal(D) is set by S based on the SRSB obtained from the 213 IGP [1]. 215 PS(R) is the computed Protection list to reach R, as discussed in 216 section 2, and depends on the available type of protection: per- 217 prefix LFA, Remote LFA or Directed LFA. The packet will follow the 218 detour path defined by PS(R), and will finally reach R. When reaching 219 R, the active segment of the packet is nodal(D), and the packet 220 resumes its course along the original segment list. 222 3.2. The active segment is an adjacency segment 224 The operator may forbid protection of an adjacency segment by policy 225 (?-Flag in [ISIS]/[OSPF]). For example, this is useful when the 226 operator prefers an end-to-end protection mechanism triggered by the 227 source of a multi-hop transport conduit. 229 We define hereafter the FRR behavior applied by S for any packet 230 received with an active segment L for which protection was enabled. 231 We distinguish the case where this active segment is followed by 232 another adjacency segment from the case where it is followed by a 233 nodal segment. 235 3.2.1. Protecting [Adjacency, Adjacency] segment lists 237 If the next segment in the list is an Adjacency Segment, then the 238 packet has to be conveyed to F. 240 To do so, S applies a "NEXT" operation on Adj(L) and then two 241 consecutive "PUSH" operations: first it pushes a nodal Segment for F, 242 and then it pushes a protection list allowing to reach F while 243 bypassing L. 245 Upon failure of L, a packet reaching S with a segment list matching 246 [adj(L),adj(M),...] will thus leave S with a segment list matching 247 [PS(F),nodal(F),adj(M)]. 249 The protection list PS(F) will define the course of the packet from S 250 to F, and F will resume the the course of the original segment list, 251 receiving it with an active segment list matching [nodal(F), 252 adj(M),...]. 254 3.2.2. Protecting [Adjacency, Nodal] segment lists 256 If the next segment in the stack is a nodal segment, say for node T, 257 the packet segment list matches [adj(L),nodal(T),...]. 259 A first solution would consist in steering the packet back to F while 260 avoiding L, similarly to the previous case. To do so, S applies a 261 "NEXT" operation on Adj(L) and then two consecutive "PUSH" 262 operations: first it pushes a nodal Segment for F, and then it pushes 263 a protection list allowing to reach F while bypassing L. 265 Upon failure of L, a packet reaching S with a segment list matching 266 [adj(L),nodal(T),...] will thus leave S with a segment list matching 267 [PS(F),nodal(F),nodal(T)]. 269 Another solution is to not steer the packet back via F. In this case, 270 S just needs to apply a "NEXT" operation on the Adjacency segment 271 related to L, and push a protection segment list redirecting the 272 traffic to a node R, capable of whose path to nodal segment T is not 273 affected by the failure. 275 Upon failure of L, packets reaching S with a segment list matching 276 [adj(L), nodal(T), ...], would leave S with a segment list matching 277 [PS(R),nodal(T), ...]. 279 4. SR FRR benefits in LDP environments 281 In this section, we describe the operational and scaling benefits of 282 SR when used to implement RLFA and DLFA protection for LDP-based 283 transport. We will also observe that a partial SR deployment, 284 limited to the network region where the SR benefits are most desired, 285 already provides the mentioned scaling benefits. 287 X 288 | 289 Y--A---B---E--Z 290 | | \ 291 D---C--F--G 292 30 294 Figure 2: Leveraging SR benefits for LDP-based traffic 296 In Figure 2, let us assume: 297 - All link costs are 10 except FG which is 30. 298 - All routers are LDP capable. 299 - X, Y and Z are PEs participating to an important service S. 300 - The operator requires 50msec link-based FRR for service S. 301 - A, B, C, D, E, F and G are SR capable. 303 - X, Y, Z are not SR capable. As part of a staged migration from 304 LDP to SR, the operator deploys SR first in a sub-part of the 305 network and then everywhere. 307 The operator would like to resolve the following issues: 308 - to protect the link BA along the shortest-path of the important 309 flow XY, B requires an RLFA repair tunnel to D and hence a 310 directed LDP session from B to D. The operator does not like these 311 dynamically established multi-hop LDP sessions and would seek to 312 eliminate them. 313 - there is no LFA/RLFA solution to protect the link BE along the 314 shortest path of the important flow XZ. The operator wants a 315 guaranteed link-based FRR solution. 317 The operator can meet these objectives by deploying SR only on A, B, 318 C, D, E and F: 319 - The operator configures A, B, C, D, E, F and G with SRGB [100, 320 200] and respective node segments 101, 102, 103, 104, 105, 106 and 321 107. 322 - The operator configures D as an SR Mapping Server with the 323 following policy mapping: (X, 201), (Y, 202), (Z, 203}. 324 - Each SR node automatically advertises local adjacency segment 325 for its IGP adjacencies. Specifically, F advertises adjacency 326 segment 9001 for its adjacency FG. 328 A, B, C, D, E, F and G keep their LDP capability and hence the flows 329 XY and XZ are transported over end-to-end LDP LSP's. 331 For example, LDP at B installs the following MPLS dataplane entries: 332 - Incoming label: local LDB label bound by B for FEC Y 333 o Outgoing label: LDP label bound by A for FEC Y 334 o Outgoing nhop: A 335 - Incoming label: local LDB label bound by B for FEC Z 336 o Outgoing label: LDP label bound by E for FEC Z 337 o Outgoing nhop: E 339 The novelty comes from how the backup chains are computed for these 340 LDP-based entries. While LDP labels are used for the primary nhop 341 and outgoing labels, SR information is used for the FRR construction. 342 In steady state, the traffic is transported over LDP LSP. In 343 transient FRR state, the traffic is backed up thanks to the SR 344 capabilities. 346 This helps meet the requirements of the operator: 347 - Eliminate directed LDP session 348 - Guaranteed FRR coverage 349 - Keep the traffic over LDP LSP in steady state 350 - Partial SR deployment only where needed 352 4.1. Eliminating Directed LDP Sessions 354 B's MPLS entry to Y becomes: 355 - Incoming label: local LDB label bound by B for FEC Y 356 o Outgoing label: LDP label bound by A for FEC Y 357 - Backup outgoing label: SR node segment for Y {202} 358 o Outgoing nhop: A 359 - Backup nhop: repair tunnel: node segment to D {104} with 360 outgoing nhop: C 362 In steady-state, X sends its Y-destined traffic to B with a top label 363 which is the LDP label bound by B for FEC Y. B swaps that top label 364 for the LDP label bound by A for FEC Y and forwards to A. A pops the 365 LDP label and forwards to Y. 367 Upon failure of the link BA, B swaps the incoming top-label with the 368 node segment for Y (202) and sends the packet onto a repair tunnel to 369 D (node segment 104). Thus, B sends the packet to C with the label 370 stack {104, 202}. C pops the node segment 104 and forwards to D. D 371 swaps 202 for 202 and forwards to A. A's nhop to Y is not SR capable 372 and hence A swaps the incoming node segment 202 to the LDP label 373 announced by its next-hop (in this case, implicit null). 375 After IGP convergence, B's MPLS entry to Y will become: 376 Incoming label: local LDB label bound by B for FEC Y 377 Outgoing label: LDP label bound by C for FEC Y 378 Outgoing nhop: C 380 And the traffic XY travels again over the LDP LSP. 382 The operator has eliminated its first problem: dynamically 383 established directed LDP sessions are no longer required and the 384 steady-state traffic is still transported over LDP. The SR 385 deployment is confined to the area where these benefits were 386 required. 388 4.2. Guaranteed FRR coverage 390 B's MPLS entry to Z becomes: 391 - Incoming label: local LDB label bound by B for FEC Z 392 - Outgoing label: LDP label bound by E for FEC Z 393 o Backup outgoing label: SR node segment for Z {203} 394 - Outgoing nhop: E 395 o Backup nhop: repair tunnel to G: {106, 9001} 396 - G is reachable from B via the combination of a node 397 segment to F {106} and an adjacency segment FG {9001} 398 - Note that {106, 107} would have equally work. Indeed, in 399 many case, P's shortest path to Q is over the link PQ. The 400 adjacency segment from P to Q is required only in very rare 401 topologies where the shortest-path from P to Q is not via 402 the link PQ. 404 In steady-state, X sends its Z-destined traffic to B with a top label 405 which is the LDP label bound by B for FEC Z. B swaps that top label 406 for the LDP label bound by E for FEC Z and forwards to E. E pops the 407 LDP label and forwards to Z. 409 Upon failure of the link BE, B swaps the incoming top-label with the 410 node segment for Z (203) and sends the packet onto a repair tunnel to 411 G (node segment 106 followed by adjacency segment 9001). Thus, B 412 sends the packet to C with the label stack {106, 9001, 203}. C pops 413 the node segment 106 and forwards to F. F pops the adjacency segment 414 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's 415 nhop to Z is not SR capable and hence E swaps the incoming node 416 segment 203 for the LDP label announced by its next-hop (in this 417 case, implicit null). 419 After IGP convergence, B's MPLS entry to Z will become: 420 - Incoming label: local LDB label bound by B for FEC Z 421 o Outgoing label: LDP label bound by C for FEC Z 422 o Outgoing nhop: C 424 And the traffic XZ travels again over the LDP LSP. 426 The operator has eliminated its second problem: guaranteed FRR 427 coverage is provided. The steady-state traffic is still transported 428 over LDP. The SR deployment is confined to the area where these 429 benefits are required. 431 5. References 433 [1] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 434 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, 435 S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment 436 Routing Architecture", draft-filsfils-rtgwg-segment-routing-00 437 (work in progress), June 2013. 439 [2] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, 440 January 2010. 442 [3] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, J., 443 Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) 444 Applicability in Service Provider (SP) Networks", RFC 6571, 445 June 2012. 447 [4] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. Ning, 448 "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02 (work in 449 progress), May 2013. 451 [5] Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Fast 452 Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 (work in 453 progress), November 2007. 455 Authors' Addresses 457 Pierre Francois 458 IMDEA Networks 459 Leganes 460 ES 462 Email: pierre.francois@imdea.org 464 Clarence Filsfils 465 Cisco Systems, Inc. 466 Brussels 467 BE 469 Email: cfilsfil@cisco.com 471 Ahmed Bashandy 472 Cisco Systems, Inc. 473 San Jose 474 US 476 Email: bashandy@cisco.com 478 Stefano Previdi 479 Cisco Systems, Inc. 480 Rome 481 IT 483 Email: sprevidi@cisco.com 484 Bruno Decraene 485 Orange 486 Issy-les-Moulineaux 487 FR 489 Email: bruno.decraene@orange.com