idnits 2.17.1 draft-hegde-spring-node-protection-for-sr-te-paths-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2342 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '1000-2000' is mentioned on line 231, but not defined == Missing Reference: '3000-4000' is mentioned on line 231, but not defined -- Looks like a reference, but probably isn't: '1100' on line 186 -- Looks like a reference, but probably isn't: '1005' on line 482 -- Looks like a reference, but probably isn't: '1002' on line 451 -- Looks like a reference, but probably isn't: '8014' on line 453 -- Looks like a reference, but probably isn't: '70099' on line 547 -- Looks like a reference, but probably isn't: '1201' on line 546 -- Looks like a reference, but probably isn't: '8002' on line 547 == Unused Reference: 'RFC7490' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'I-D.francois-rtgwg-segment-routing-ti-lfa' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'I-D.minto-rsvp-lsp-egress-fast-protection' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'ISO10589' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 629, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing area S. Hegde 3 Internet-Draft C. Bowers 4 Intended status: Informational Juniper Networks, Inc. 5 Expires: May 3, 2018 S. Litkowski 6 Orange 7 October 30, 2017 9 Node Protection for SR-TE Paths 10 draft-hegde-spring-node-protection-for-sr-te-paths-02 12 Abstract 14 Segment routing supports the creation of explicit paths using 15 adjacency-sids, node-sids, and binding-sids. It is important to 16 provide fast reroute (FRR) mechanisms to respond to failures of links 17 and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A 18 point of local repair (PLR) can provide FRR protection against the 19 failure of a link in an SR-TE path by examining only the first (top) 20 label in the SR label stack. In order to protect against the failure 21 of a node, a PLR may need to examine the second label in the stack as 22 well in order to determine SR-TE path beyond the failed node. This 23 document specifies how a PLR can use the first and second label in 24 the label stack describing an SR-TE path to provide protection 25 against node failures. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 3, 2018. 50 Copyright Notice 52 Copyright (c) 2017 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Node Failures Along SR-TE Paths . . . . . . . . . . . . . . . 3 69 2.1. Node protection for node-sid explicit paths . . . . . . . 3 70 2.2. Node-Protection for Anycast-SIDs . . . . . . . . . . . . 4 71 2.3. Node-protection for adj-sid explicit paths . . . . . . . 5 72 2.4. Node-protection of binding-sid explicit paths . . . . . . 6 73 3. Detailed Solution using Context Tables . . . . . . . . . . . 6 74 3.1. Building Context Tables . . . . . . . . . . . . . . . . . 6 75 3.2. Node protection for node SIDs . . . . . . . . . . . . . . 7 76 3.3. Node protection for ajacency SIDs . . . . . . . . . . . . 8 77 3.4. Node protection for binding sids . . . . . . . . . . . . 9 78 3.5. Node protection for edge nodes . . . . . . . . . . . . . 11 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 7.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 It is possible for a routing device to completely go out of service 90 abruptly due to power failure, hardware failure or software crashes. 91 Node protection is an important property of the Fast Reroute 92 mechanism. It provides protection against a node failure by 93 rerouting traffic around the failed node. For example, the 94 mechanisms described in Loop Free Alternates [RFC5286] and Remote 95 loop free alternates [I-D.ietf-rtgwg-rlfa-node-protection] can be 96 used to provide node protection to ensure minimal traffic loss after 97 a node failure. 99 Section 2 describes problems with SR-TE paths and need for a 100 specialized mechanism to provide node protection for the SR-TE paths. 101 Section 3 describes the solution applied to paths built using 102 adjacency-sids, node-sids and binding-sids. Section 3.5 describes 103 the solution applied to egress node protection. 105 2. Node Failures Along SR-TE Paths 107 The topology shown in Figure 1. illustrates a example network 108 topology with SPRING enabled on each node. 110 Node Node Node Node Node 111 sid:1 sid:2 sid:3 sid:4 sid:5 112 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 113 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 114 +----+ +----+ +----+ +----+ +----+ 115 \ \ / 116 \ 10 \ 100 / 60 117 \ \ / 118 \ +----+ +----+ 119 +--| R7 |------------------| R8 | 120 +----+ 30 +----+ 121 / Node Node Label stack: 122 / sid:7 sid:8 +------------+ 123 +----+ SRGB: | 1008 (top)| 124 | R6 | 3000-4000 +------------+ 125 +----+ | 3005 | 126 Node +------------+ 127 sid:6 129 Figure 1: Example topology. The segment index for each node is shown 130 in the diagram. All nodes have SRGB = [1000-2000], except for R8 131 which has SRGB = [3000-4000]. A label stack that represents the path 132 R1->R7->R8->R4->R5 is shown as well. 134 2.1. Node protection for node-sid explicit paths 136 Consider an explicit path in the topology in Figure 1 from R1->R5 via 137 R1->R7->R8->R4->R5. This path can be built using the shortest paths 138 from R1-to-R8 and R8-to-R5. The label stack to instantiate this path 139 contains two node-sids 1008 and 3005. The 1008 label will take the 140 packet from R1 to R8 via R7 and get popped. The next label in the 141 stack 3005 will take the packet from R8 to the destination R5 via R4. 142 If the node R8 goes down, it is not possible for R7 to perform FRR 143 without examining the second label in the incoming label stack 144 (3005). 146 Note that in the absence of a failure, R7 does not need to understand 147 the meaning of the second label (3005) in order to perform normal 148 forwarding. However, in order to support node protection, R7 will 149 need to understand the meaning of label 3005 in order to determine 150 where the packet is headed after R8. 152 2.2. Node-Protection for Anycast-SIDs 154 A prefix segment advertised as a node SID may only be advertised by 155 one node in the network. Instead, an anycast prefix segment may be 156 advertised by more than one node. In some situations, one can use 157 anycast SIDs to construct SR-TE paths that are protected against node 158 failure, without the need for the mechanism described in this 159 document. 161 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 162 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 163 +----+ +----+ +----+ +----+ +----+ 164 \ \ / | 165 \ 10 \100 60/ | 166 \ \ / | 167 \ +----+ 30 +----+ | 168 +--| R7 |------------------| R8 | | 169 +----+ +----+ | 170 / \ Anycast + 171 / \ sid:100 / 172 +----+ \ / 173 | R6 | \ 40 +----+ /60 174 +----+ +---------------| R9 |+ Label stack: 175 +----+ +------------+ 176 Anycast | 1100 (top)| 177 sid:100 +------------+ 178 | 1005 | 179 +------------+ 181 Figure 2: Topology illustrating use of anycast-sids to protect 182 against node failures. All nodes have SRGB = [1000-2000]. 184 An example of this is shown in Figure 2. In this example, R8 and R9 185 advertise an anycast SID of 100. The label stack in this example = 186 [1100, 1005];. The top label (1100) corresponds to the anycast SID 187 advertised by both R8 and R9. In the absence of a failure, the 188 packet sent by R1 with this label stack will follow the path from 189 R1->R5 along R1->R7->R8->R4->R5. 191 If R7 is performing a per-prefix LFA calculation [RFC5286], then R7 192 will install a backup next-hop to R9 for this anycast SID, protecting 193 against the failure of the primary next-hop to R8. This backup path 194 does not pass through R8, so it is would not be affected by a 195 complete failure of node R8. As illustrated by this example, for 196 some topologies node-protecting SR-TE paths can constructed through 197 the use of anycast SIDs, as opposed to the mechanism described in 198 this document. 200 2.3. Node-protection for adj-sid explicit paths 202 Adj-sid: 203 R3-R8:9044 205 Node Node Node Node Node 206 sid:1 sid:2 sid:3 sid:4 sid:5 207 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 208 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 209 +----+ +----+ +----+ +----+ +----+ 210 \ \ / | 211 \ 10 \ 100 / 60 | 10 212 \ \ / | 213 \ +----+ +----+ +----+ 214 +--| R7 |------------------| R8 |---------------| R9 | 215 +----+ 30 +----+ 10 +----+ 216 / Node Node Node 217 / sid:7 sid:8 sid:9 218 +----+ SRGB: 219 | R6 | 3000-4000 Label stack: 220 +----+ +------------+ 221 Node Adj-sids: | 1003 (top)| 222 sid:6 R8-R4:9054 +------------+ 223 | 9044 | 224 +------------+ 225 | 9054 | 226 +------------+ 227 | 1005 | 228 +------------+ 230 Figure 3: Explicit path using an adjacency sid. All nodes have SRGB 231 = [1000-2000], except for R8 which has SRGB = [3000-4000]. 233 Consider an explicit path from R1->R5 via R1->R2->R3->R8->R4->R5. 234 This path can be built using a combination of node sids and adjacency 235 sids, as shown in Figure 3. The diagram shows shows the label stack 236 needed to instantiate this path, as well as several adjacency sids 237 advertised by nodes involved in this path. When a packet leaving R1 238 with this label stack reaches R3, the top label is 9044, which will 239 take the packet to R8. The next-next-hop in the path is R4. To 240 provide protection for the failure of node R8, R3 would need to send 241 the the packet to R4 without going through R8. However, the only way 242 R3 can learn that the packet needs to go to the R4 is to examine the 243 next label in the stack, label 9054. Since R3 knows that R8 has 244 advertised label 9054 as the adjacency segment for the link from R8 245 to R4, R3 knows that a backup path can merge back into the original 246 explicit path at R4. 248 2.4. Node-protection of binding-sid explicit paths 250 Binding sids (defined in SR architecture 251 [I-D.ietf-spring-segment-routing]) allow the SR-TE path to be built 252 using a hierarchy of sub-paths. The binding sid provides a single 253 label to represent a set of nodes and links. If the node advertising 254 the binding sid goes down, the traffic needs to be protected. The 255 label stack involving the binding-sid contains next label in the 256 stack which corresponds to the end point represented by the binding- 257 sid. The penultimate node of the binding-sid advertiser cannot know 258 the meaning of the next label in the stack. 260 3. Detailed Solution using Context Tables 262 3.1. Building Context Tables 264 [RFC5331] introduced the concept of Context Specific Label Spaces and 265 there are various applications making use of this concept.A context 266 label table on a router represents the Label Forwarding Information 267 Base (LFIB) from the point of view of a particular neighbor . Context 268 tables are built by constructing incoming label mappings advertised 269 by the neighbor and the actions corresponding to those labels. The 270 labels advertised by each node are local to the node and may not be 271 unique across the segment routing domain. The context tables are 272 separate tables built on a per-neighbor basis on every node to ensure 273 they represent LFIBs of a particular neighbor. 275 When a node requires to protect an SRTE path against the failure of a 276 neighbor N, it MUST create a context table associated to N. This 277 context table MUST be populated with the following segment routing 278 forwarding entries: 280 - All the Prefix-SIDs of the network. The programmed ILM MUST use 281 the SRGB of N to compute the input label value. The NHLFE SHOULD 282 be constructed by looking into all the nexthops for the prefix-SID 283 and choosing a loop-free path as explained in Section 3.2 285 - All the Adjacency SIDs advertised by N. The NHLFE SHOULD be 286 constructed as explained in Section 3.3 288 - All the Binding SIDs advertised by N. The NHLFE SHOULD be 289 constructed as explained in Section 3.4 291 The following section illustrates how the context table is 292 constructed to allow the PLR to provide node-protecting paths for the 293 next-next hops in the topology shown in Figure 1 and Figure 3. 295 3.2. Node protection for node SIDs 297 Figure 4 shows the routing table entries on R7 corresponding to the 298 node SIDs to reach R1 and R8 for the topology in Figure 1. In the 299 absence of a failure, a packet with a label stack whose top label is 300 1008 will have its top label popped by R7 (assuming PHP behavior), 301 and R7 will forward the packet to R8. When the interface to R8 is 302 down, the backup next-hop entry is used. R7 will pop the top label 303 of 1008, and use the context table that R7 computed for R8 to 304 evaluate the next label on the stack. 306 R7's Routing Table (partial) 307 Transits routes for Node SIDs for R1 and R8 308 +=============+=============================================+ 309 | In label | Outgoing label action | 310 +=============+=============================================+ 311 | 1001 | Primary: pop, fwd to R1 | 312 | | Backup: pop, lookup context.r1 | 313 +-------------+---------------------------------------------+ 314 | 1008 | Primary: pop, fwd to R8 | 315 | | Backup: pop, lookup context.r8 | 316 +-------------+---------------------------------------------+ 318 R7's Context Table for R8 (context.r8, partial) 319 +=============+=============================================+ 320 | In label | Outgoing label action | 321 +=============+=============================================+ 322 | 3004 | swap 1004, fwd to R1 | 323 +-------------+---------------------------------------------+ 324 | 3005 | swap 1005, fwd to R1 | 325 +-------------+---------------------------------------------+ 326 | 3008 | swap 1008, fwd to R1 | 327 +-------------+---------------------------------------------+ 329 Figure 4: Building node-protecting backup paths for SR-TE paths 330 involving node SIDs 332 R7 builds context table for R8 using the following process. R7 333 computes the mapping of incoming label to node-sid that R8 expects to 334 see based on the SRGB advertised by R8. In the example in Figure 1, 335 R7 can determine that R8 interprets in incoming label of 3005 as 336 mapping to the the node SID for R5. 338 R7 then computes a loop-free backup path to reach R5 which is node- 339 protecting with respect to the failure of R8. In this example, the 340 backup path computed by R7 to reach R5 without passing through R8 can 341 be achieved forwarding the packet to R1 with a top label of 1005, 342 corresponding to the node SID for R5 in the context of R1's SRGB. 343 The loop-free path computation may be based on a mechanism such as 344 LFA, R-LFA, TI-LFA, or constraint based SPF avoiding failure. To 345 populate the context table for R8, R7 maps the out label actions 346 corresponding to the backup path to R5 to the incoming label 3005. 347 This results in the entry for label 3005 showin in context.r8 in 348 Figure 4. 350 Therefore, when a packet arrives at R7 with label stack = [1008, 351 3005], and the link from R7 to R8 has recently failed, R7 will use 352 backup next-hop entry for label 1008 in its main routing table. 353 Based on this entry, R7 will pop label 1008, and use context.r8 to 354 lookup the new top label = 3005. R7 will swap label 3005 for 1005 355 and forward the packet to R1. This will get the packet to R5 on a 356 node protecting backup path. 358 Note that R7 activates the node-protecting backup path when it 359 detects that the link to R8 has failed. R7 does not know that node 360 R8 has actually failed. However, the node-protecting backup path is 361 computed assuming that the failure of the link to R8 implies that R8 362 has failed. 364 3.3. Node protection for ajacency SIDs 366 This section gives an example of how to constuct node-protecting 367 backup paths when the SR-TE path uses adjacency SIDs. Figure 5 shows 368 some of the routing table entries for R3 corresponding to the sample 369 network shown in Figure 3. When the top label of the label stack is 370 an adjacency SID, the PLR needs to recognize that in order to provide 371 a node-protecting backup path, it needs to pop the top label and 372 examine the next label in the context of the next-hop router 373 identified by the top label adjacency SID. In this example, when R3 374 is constructing its routing table, it recognizes that label 9044 375 corresponds to a next-hop of R8, so it installs a backup entry, 376 corresponding to the failure of the link to R8, when pops label 9044, 377 and then examines the new top label in the context of R8. 379 R3's Routing Table (partial) 380 Transit route for Adj SID 381 +=============+=============================================+ 382 | In label | Outgoing label action | 383 +=============+=============================================+ 384 | 9044 | Primary: pop, fwd to R8 | 385 | | Backup: pop, lookup context.r8 | 386 +-------------+---------------------------------------------+ 388 R3's Context Table for R8 (context.r8, partial) 389 +=============+=============================================+ 390 | In label | Outgoing label action | 391 +=============+=============================================+ 392 | 3005 | swap 1005, fwd to R4 | 393 +-------------+---------------------------------------------+ 394 | 9054 | pop, fwd to R4 | 395 +-------------+---------------------------------------------+ 397 Figure 5: Building node-protecting backup paths for SR-TE paths 398 involving adjacency SIDs 400 R3 constructs its context table for R8 by determining which labels R8 401 expects to receive to accomplish different forwarding actions. The 402 entry for incoming label 3005 in context.r8 in Figure 5 corresponds 403 to a node SID. This entry is computed using the methods described in 404 Section 3.2 406 The entry for incoming label 9054 in context.r8 corresponds to an 407 adjacency SID. R3 recognizes that R8 has advertised this adjacency 408 SID for the link from R8 to R4 in Figure 3. So R3 determines the 409 outgoing label action needed to reach R4 without passing through R8. 410 This can be accomplished by popping the label 9054, and forwarding 411 the packet directly on the link from R3 to R4. 413 3.4. Node protection for binding sids 415 Figure 6 shows a sample network where R2 advertises a binding sid 416 2014 for the path R2->R3->R8->R4. This mechanism is very useful in 417 compressing the label stack depth as a sub-path can be represented 418 using a single label. The explicit path R7->R1->R2->R3->R8->R4->R5 419 can be represented by a 3 label stack as shown in Figure 6. If the 420 node that advertises the binding-sid goes down, protection mechanisms 421 are needed for the binding sid that the node advertised. 423 Binding sid 424 to reach R4: 425 8014 427 Node Node Node Node Node 428 sid:1 sid:2 sid:3 sid:4 sid:5 429 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 430 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 431 +----+ +----+ +----+ +----+ +----+ 432 \ \ / 433 \ 10 \ 100 / 60 434 \ \ / 435 \ +----+ +----+ 436 +--| R7 |------------------| R8 | Label stack 437 +----+ 30 +----+ for packet fwd 438 / Node Node from R7 to R1 439 / sid:7 sid:8 +------------+ 440 +----+ SRGB: | 1002 (top)| 441 | R6 | 3000-4000 +------------+ 442 +----+ | 8014 | 443 Node +------------+ 444 sid:6 | 1005 | 445 +------------+ 447 Figure 6: Building node-protecting backup paths for SR-TE paths 448 involving binding SIDs 450 In the example topology, R7 forwards a packet to R1 with label stack 451 = [1002,8014,1005]. In the absence of a failure, R1 pops the label 452 1002 (assuming PHP behavior) and forwards the packet with label stack 453 = [8014,1005] to R2. R2 recognizes label 8014 as the binding SID it 454 advertised for a path to reach R4 so it pops the label 8014 and uses 455 some forwarding mechanism to have the packet reach R4 with label 456 stack = [1005]. 458 If node R2 fails, it is up to R1 to figure out where traffic would 459 have been sent by R2, had it reached R2, by looking deeper into the 460 label stack. In this example, R1 recognizes that the second label in 461 the stack corresponds to the binding SID advertised by R2 with R4 as 462 the tail-end of the advertised path. R1 therefore pops label 1002, 463 swaps label 8014 with 1004 (the node SID to reach R4), and forwards 464 the packet to R7. 466 Note that the PLR (R1 in this example) needs to receive and 467 understand the binding SID advertisement in order to be able to 468 determine the tail-end of the path advertised by the binding SID. 469 This would be the case with binding SIDs advertised using the IGP. 471 If other mechanisms are used for advertising binding SIDs, the PLR 472 may not automatically have access to this information. 474 3.5. Node protection for edge nodes 476 The node protection mechanism described in previous sections depends 477 on the assumption that the label below the top label in the label 478 stack are understood in the IGP domain. In the example topology in 479 Figure 7, CE-A and CE-B are customer edge routers receiving services 480 from provider edge routers. The provider edge routers are exchanging 481 service labels via BGP or some other non-IGP mechanism. A packet 482 with label stack = [1005,70099] sent from PE1 to R2 would be 483 forwarded along the path PE1->R2->R3->R4->PE5. Assuming PHP 484 behavior, PE5 receives the packet with the label stack = [70099]. 485 PE5 uses the service label 70099 to send the packet to CE-B with the 486 appropriate service characteristics. If PE5 fails, R4 needs to act 487 as the PLR. However, R4 does not understand the meaning of the 488 service label 70099. 490 Primary PE: 491 context 1.1.1.1 492 prefix sid: 201 494 Node Node Node Node Node 495 sid:1 sid:2 sid:3 sid:4 sid:5 496 +---+ 10 +----+ 10 +----+ 10 +----+ 10 +---+ +----+ 497 |PE1|--------| R2 |--------| R3 |--------| R4 |------|PE5|---|CE-A| 498 +---+ +----+ +----+ +----+ +---+ +----+ 499 \ \ / \ / 500 \ 10 \ 100 / 60 \/ 501 \ \ / /\ 502 \ +----+ +----+ +---+/ +----+ 503 +--| R7 |------------------| R8 |-------------|PE9+---|CE-B| 504 +----+ 30 +----+ 10 +---+ +----+ 505 / Node Node Node 506 / sid:7 sid:8 sid:9 507 +----+ 508 | R6 | Protector PE: 509 +----+ context 1.1.1.1 510 Node prefix sid: 201 511 sid:6 binding sid:8002 513 Normal Protection 514 label stack label stack 515 +------------+ +------------+ 516 | 1201 (top)| | 1201 (top)| 517 +------------+ +------------+ 518 | 70099 | | 8002 | 519 +------------+ +------------+ 520 | 70099 | 521 +------------+ 523 Figure 7: Node Protection for edge nodes 525 The service mirroring use case is described in 526 [I-D.filsfils-spring-segment-routing-use-cases]. The customer edge 527 (CE) routers are multi-homed to provider edge (PE) routers, and one 528 of the PE's acts in a primary role and the other in protector role. 529 The two PEs advertise a context ip address for each customer site and 530 attaches a prefix-sid to the context. The protector PE advertises a 531 binding sid with M bit set which implies mirroring capability for the 532 context. Protector PE builds the context table for the BGP service 533 labels advertised by the primary PE for the same context. The BGP 534 service is built using a stack of labels with context-sid at the 535 bottom of the label stack. 537 Each node acting as a PLR with respect to failure of the Primary PE 538 installs a backup routing entry that accomplishes two things. The 539 routes gets the packet to the Protector PE. And it positions the 540 context-label immediately above the service label in the label stack, 541 so that the Protector PE is able to identify the correct context 542 table to interpret the service label. 544 In the example in Figure 7, R4 makes sure that the packet originally 545 destined for PE5 is forwarded on the interface to R8 with label stack 546 = [1201,8002,70099]. This gets the packet to PE9 with label stack = 547 [8002,70099] (assuming PHP behavior). PE9 then uses the context 548 label of 8002 to identify the context table corresponding to PE5. 550 4. Security Considerations 552 TBD 554 5. IANA Considerations 556 6. Acknowledgments 558 7. References 560 7.1. Normative References 562 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 563 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 564 DOI 10.17487/RFC5286, September 2008, 565 . 567 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 568 Label Assignment and Context-Specific Label Space", 569 RFC 5331, DOI 10.17487/RFC5331, August 2008, 570 . 572 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 573 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 574 RFC 7490, DOI 10.17487/RFC7490, April 2015, 575 . 577 7.2. Informative References 579 [I-D.filsfils-spring-segment-routing-use-cases] 580 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 581 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 582 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 583 Crabbe, "Segment Routing Use Cases", draft-filsfils- 584 spring-segment-routing-use-cases-01 (work in progress), 585 October 2014. 587 [I-D.francois-rtgwg-segment-routing-ti-lfa] 588 Francois, P., Bashandy, A., Filsfils, C., Decraene, B., 589 and S. Litkowski, "Abstract", draft-francois-rtgwg- 590 segment-routing-ti-lfa-04 (work in progress), December 591 2016. 593 [I-D.ietf-rtgwg-rlfa-node-protection] 594 Sarkar, P., Hegde, S., Bowers, C., Gredler, H., and S. 595 Litkowski, "Remote-LFA Node Protection and Manageability", 596 draft-ietf-rtgwg-rlfa-node-protection-13 (work in 597 progress), January 2017. 599 [I-D.ietf-spring-segment-routing] 600 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 601 and R. Shakir, "Segment Routing Architecture", draft-ietf- 602 spring-segment-routing-12 (work in progress), June 2017. 604 [I-D.minto-rsvp-lsp-egress-fast-protection] 605 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 606 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 607 protection-03 (work in progress), November 2013. 609 [ISO10589] 610 "Intermediate system to Intermediate system intra-domain 611 routeing information exchange protocol for use in 612 conjunction with the protocol for providing the 613 connectionless-mode Network Service (ISO 8473), ISO/IEC 614 10589:2002, Second Edition.", Nov 2002. 616 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 617 dual environments", RFC 1195, DOI 10.17487/RFC1195, 618 December 1990, . 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, 622 DOI 10.17487/RFC2119, March 1997, 623 . 625 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 626 DOI 10.17487/RFC2328, April 1998, 627 . 629 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 630 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 631 . 633 Authors' Addresses 635 Shraddha Hegde 636 Juniper Networks, Inc. 637 Exora Business Park 638 Bangalore, KA 560103 639 India 641 Email: shraddha@juniper.net 643 Chris Bowers 644 Juniper Networks, Inc. 646 Email: cbowers@juniper.net 648 Stephane Litkowski 649 Orange 651 Email: stephane.litkowski@orange.com