idnits 2.17.00 (12 Aug 2021) /tmp/idnits30149/draft-liu-rtgwg-srv6-protection-considerations-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 3, 2022) is 72 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 == Outdated reference: A later version (-01) exists of draft-ietf-spring-srv6-srh-compression-00 == Outdated reference: A later version (-05) exists of draft-ietf-rtgwg-srv6-egress-protection-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Yisong Liu 2 Internet Draft W. Cheng 3 Intended status: Informational China Mobile 4 Expires: September 3, 2022 C. Lin 5 New H3C Technologies 6 X. Geng 7 Huawei Technologies 8 Y. Liu 9 ZTE 10 March 3, 2022 12 Considerations for Protection of SRv6 Networks 13 draft-liu-rtgwg-srv6-protection-considerations-01 15 Abstract 17 This document describes the considerations for protection of SRv6 18 network. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on September 3, 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction...................................................3 61 1.1. Requirements Language.....................................3 62 1.2. Terminology...............................................3 63 2. Forwarding over SRv6 Network...................................3 64 2.1. SRv6 BE Path..............................................3 65 2.2. SRv6 TE Path..............................................4 66 3. Protection Mechanisms..........................................5 67 3.1. Path Protection...........................................5 68 3.1.1. Local Proctection Mechanisms.........................5 69 3.1.2. Liveness Check For Local Protection..................6 70 3.1.3. Micro-Loop Avoidance.................................6 71 3.1.4. End-to-End Protection Mechanisms.....................6 72 3.1.5. Liveness Check For End-to-End Protection.............7 73 3.2. Service Protection........................................8 74 3.2.1. Local Repair.........................................8 75 3.2.2. Ingress Node Switchover..............................8 76 4. Implementation Recommendations.................................9 77 4.1. SRv6 BE..................................................11 78 4.2. SRv6 TE..................................................12 79 5. Security Considerations.......................................15 80 6. IANA Considerations...........................................15 81 7. Contributors..................................................15 82 8. References....................................................16 83 8.1. Normative References.....................................16 84 8.2. Informative References...................................17 85 Authors' Addresses...............................................18 87 1. Introduction 89 Segment Routing [RFC8402] instantiated on the IPv6 dataplane (SRv6) 90 provides network programming capability to create interoperable 91 overlays with underlay optimization [RFC8986]. 93 This document describes the common failure scenarios and protection 94 mechanisms in SRv6 networks. Then implementation recommendations for 95 protection of SRv6 networks are proposed. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in 102 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 1.2. Terminology 107 BE: Best Effort 109 TE: Traffic Engineering 111 G-SRv6: Generalized SRv6 Network Programming 113 2. Forwarding over SRv6 Network 115 Segment Routing [RFC8402] leverages the source routing paradigm. 116 Segment Routing instantiated on the IPv6 dataplane is referred to as 117 SRv6. SRv6 provides network programming capability to create 118 interoperable overlays with underlay optimization [RFC8986]. 120 In an SRv6 network, the ingress node encapsulates a received packet 121 in an outer IPv6 header, followed by an optional Segment Routing 122 Header (SRH) [RFC8754], which instructs the SRv6 network to forward 123 the packet via a specific path to the egress node. The forwarding 124 path is either an SRv6 BE path or an SRv6 TE path. 126 2.1. SRv6 BE Path 128 In the SRv6 BE path, the ingress PE encapsulates the payload in an 129 outer IPv6 header where the destination address is the SRv6 Service 130 SID provided by the egress PE. The underlay P nodes between the PEs 131 only need to perform plain IPv6 shortest path forwarding. 133 ----------------------- 134 | IPv6 Header | 135 | DA = 2001:DB8:1:1:: | 136 ----------------------- 137 | Payload | 138 ----------------------- 140 Ingress PE ---> P nodes ---> Egress PE 142 Figure 1: Forwarding over SRv6 BE 144 2.2. SRv6 TE Path 146 In the SRv6 TE path, the ingress PE steers the traffic flow into an 147 SR Policy [I-D.ietf-spring-segment-routing-policy], and encapsulates 148 the payload packet in an outer IPv6 header with the Segment Routing 149 Header (SRH) carrying the segment list of the SR policy. The 150 underlay P nodes whose SRv6 SID's are part of the SRH segment list 151 are called endpoint nodes. They will be involved in the forwarding 152 path and execute the function associated with the SID. 154 ------------------------ 155 | IPv6 Header | 156 | DA = 2001:DB8:6:1:: | 157 ------------------------ 158 | SRH | 159 | Seg[0]= 2001:DB8:1:1:: | 160 | Seg[1]= 2001:DB8:2:1:: | 161 | Seg[2]= 2001:DB8:3:1:: | 162 | Seg[3]= 2001:DB8:4:1:: | 163 | Seg[4]= 2001:DB8:5:1:: | 164 | Seg[5]= 2001:DB8:6:1:: | 165 ------------------------ 166 | Payload | 167 ------------------------ 169 Ingress PE ---> P nodes ---> Egress PE 171 Figure 2: Forwarding over SRv6 TE 173 If Compressed Segment List encoding is enabled in the SRv6 network 174 [I-D.ietf-spring-srv6-srh-compression], the segment list in the SRH 175 will be encoded in the compressed way. The compressed SRv6 Segment- 176 List encoding can optimize the packet header length by avoiding the 177 repetition of the Locator-Block and trailing bits with each 178 individual SID. 180 The G-SRv6 mechanism will be used as an example for the encoding of 181 SRv6 TE path in this document. Figure 3 shows the encapsulation of 182 packet using the G-SRv6 mechanism. 184 ------------------------ 185 | IPv6 Header | 186 | DA = 2001:DB8:6:1:: | 187 ------------------------ 188 | SRH | 189 |Seg[0]= 2001:DB8:1:1:: | 190 |Seg[1]= 2:1|3:1|4:1|5:1 | 191 |Seg[2]= 2001:DB8:6:1:: | 192 ------------------------ 193 | Payload | 194 ------------------------ 196 Ingress PE ---> P nodes ---> Egress PE 198 Figure 3: Forwarding over G-SRv6 Encoded TE 200 3. Protection Mechanisms 202 3.1. Path Protection 204 3.1.1. Local Proctection Mechanisms 206 Local protection is performed by the node adjacent to the failed 207 component using fast-reroute techniques [RFC5286] [RFC5714]. The 208 common method of local repair is to provide a repair path for the 209 destination avoiding the failed component. 211 [I-D.ietf-rtgwg-segment-routing-ti-lfa] describes the Topology 212 Independent Loop-free Alternate Fast Re-route technology (TI-LFA) 213 using Segment Routing, which is able to provide a loop free backup 214 path irrespective of the topologies used in the network. For each 215 destination in the network, TI-LFA pre-installs a backup forwarding 216 entry for each protected destination ready to be activated upon 217 detection of the failure of a link used to reach the destination. 219 In SRv6 dataplane, the TI-LFA repair path is encoded as an SRv6 SID 220 list, and encapsulated in the SRH along with an outer IPv6 header. 221 If Compressed Segment List encoding is enabled, the repair node 222 should check the G-SRv6 capability of nodes along the repair path 223 and try to use G-SIDS to encode the repair path, which will help to 224 optimize the packet header length. 226 3.1.2. Liveness Check For Local Protection 228 In order to perceive the failures of links and neighbors, a node 229 should monitor the liveness of its adjacent components. 231 [RFC5880] and [RFC7880] provide widely used mechanisms for liveness 232 check, called Bidirectional Forwarding Detection (BFD) and Seamless 233 Bidirectional Forwarding Detection (S-BFD). 235 BFD can be associated with the interface state to detect the failure 236 of directly-connected links. Two adjacent nodes may establish BFD or 237 S-BFD sessions between each other, and send BFD control packets to 238 monitor the liveness of each other. In another way, a node may send 239 BFD echo packets to all the neighbors, and they will reflect the 240 packets back, without establishing BFD sessions. 242 Other OAM methods, such as Ping, TWAMP or STAMP, may also be used 243 for liveness check for local protection, which will not be 244 enumerated here in detail. 246 3.1.3. Micro-Loop Avoidance 248 When a component fails or comes back up, the topology is changed. 249 The routing convergence happens in each node at different times and 250 during a different lapse of time. These transient routing 251 inconsistencies may cause micro-loops. 253 [I-D.bashandy-rtgwg-segment-routing-uloop] provides a mechanism 254 leveraging segment routing to ensure loop-freeness during the IGP 255 reconvergence process, which relies on the temporary use of SR 256 policies ensuring loop-freeness over the post-convergence paths from 257 the converging node to the destination. 259 In SRv6 dataplane, the loop-free post-convergence path is encoded as 260 an SRv6 SID list, and encapsulated in the SRH along with an outer 261 IPv6 header. If Compressed Segment List encoding is enabled, the 262 converging node should check the G-SRv6 capability of nodes along 263 the post-convergence path and try to use G-SIDs to encode the path. 265 3.1.4. End-to-End Protection Mechanisms 267 End-to-end protection lets the ingress PE node be in charge of the 268 failure recovery. The ingress node should steer the flow from the 269 failed path into another alive path. 271 In the case of SRv6 TE path, the SR Policy itself allows for 272 multiple candidate paths, of which at any point in time there is a 273 single active candidate path that is provisioned in the forwarding 274 plane and used for traffic steering [I-D.ietf-spring-segment- 275 routing-policy]. The candidate path with highest preference is 276 selected as the primary path, and the candidate path with second 277 highest preference can be selected as the hot-standby backup. When 278 the primary candidate path fails, switchover to the backup candidate 279 path can be triggered by fast re-route mechanism. 281 If all the candidate paths fail, the ingress node may use SRv6 BE 282 path for best-effort forwarding. 284 3.1.5. Liveness Check For End-to-End Protection 286 It is essential that the ingress PE node should check the end-to-end 287 liveness of paths, including primary path and backup path. So that 288 the ingress PE node can perceive the path failure and then trigger 289 the switchover. 291 In the case of SRv6 TE path, BFD or S-BFD can be used to monitor the 292 liveness of SR Policy at the level of segment list. If all the BFD 293 sessions associated with segment lists in a candidate path are down, 294 the candidate path is deemed to be failed. If all the candidate 295 paths is failed, the SR Policy is deemed to be failed. 297 Moreover, If the SRv6 TE path is strict (every hop along the path 298 appearing in the SID list), the reverse path of the BFD packets 299 should be the same with the forward path. Otherwise, the failure in 300 the reverse path may cause the misjudgement of the liveness of SR 301 Policy. To achieve the consistence of forward path and reverse path, 302 the egress node should be instructed to use specific path to send 303 packets back to the ingress node. 305 Other OAM methods, such as Ping, TWAMP or STAMP, may also be used 306 for liveness check for end-to-end protection, which will not be 307 enumerated here in detail. 309 Local protection and end-to-end protection may both be used in the 310 same SRv6 network. Since the speed of failure detection for local 311 protection is faster than end-to-end protection, local protection 312 usually performs the local repair in advance, which allows the path 313 to remain alive. In this case, the ingress node will not perceive 314 the failure and does not need to trigger end-to-end protection. 316 3.2. Service Protection 318 If the failure occurs on the egress PE node, the service provided by 319 that PE is not accessible anymore. TI-LFA or the hot-standby backup 320 candidate path of SR Policy will not work under this circumstance. 321 To provide protection, the packet should be forwarded to another 322 backup Egress PE node of the same service, if it exists. 324 3.2.1. Local Repair 326 In the case of egress PE node failure, the local repair node should 327 forward packet to another Egress PE node. 329 [I-D.ietf-rtgwg-srv6-egress-protection] provides a method to use 330 Mirror SID for egress protection. The Mirror SID is configured on 331 the backup egress PE to protect the primary egress PE, and it will 332 be used by the repair node to encode the segment list of repair 333 path. 335 3.2.2. Ingress Node Switchover 337 If there are multiple egress PE nodes, the ingress PE node receives 338 all their advertisements of the same service, and builds paths for 339 each of them respectively. The ingress PE node may use Fast Reroute 340 (FRR) for these different paths. When the primary egress PE node 341 fails, the ingress node steers the flow to the path belonging to 342 another egress PE node for protection. 344 BFD can be used to monitor the liveness of the service SID, locator 345 or interface address of the egress PE node. If the BFD session is 346 down, the egress PE node is deemed to be unreachable. 348 Service protection and path protection may both be used in the same 349 SRv6 network. Among the different paths to the same egress PE node 350 and the paths to different egress PE nodes, one is selected as the 351 primary path and others are used as backup. The priorities of 352 multiple backup paths may be decided by the egress-node-first 353 strategy or the TE-first strategy. 355 By the Egress-node-first strategy, paths to the primary egress PE 356 nodes are prioritized. For example, if a failure occurs on the 357 primary path, the ingress PE node will select another path still 358 leading to the primary egress PE nodes. Unless all the paths to the 359 primary egress PE node are failed, the ingress PE node would use the 360 path to the backup egress PE node. 362 By the TE-first strategy, SRv6 TE paths to any egress PE node have 363 higher priorities than SRv6 BE paths. For example, if a failure 364 occurs on the primary path and there is no other alive SRv6 TE paths 365 to the primary egress PE node, the ingress node will select an SRv6 366 TE path to the backup egress PE node, rather than an SRv6 BE path 367 still leading to the primary egress PE node. 369 4. Implementation Recommendations 371 This section will introduce the implementation recommendations of 372 protection for SRv6 BE and SRv6 TE scenarios in SRv6 network: 374 Figure 5 is used as a reference topology in this section. PE1 and 375 PE3 are primary PE nodes for VPN service access. PE2 and PE4 are 376 used as backup. The prefix of CE2, along with VPN service SID, is 377 advertised by BGP routes from PE3 and PE4 to PE1 and PE2. The VPN 378 traffic is from CE1 to CE2. 380 PE1-----P1-----P3-----P5-----P7----PE3 381 / \ / | \ / | \ / | \ / | \ / \ 382 / \/ | \/ | \/ | \/ | \/ \ 383 CE1 /\ | /\ | /\ | /\ | /\ CE2 384 \ / \ | / \ | / \ | / \ | / \ / 385 \ / \|/ \|/ \|/ \|/ \ / 386 PE2-----P2-----P4-----P6-----P8----PE4 388 Figure 5: Reference Topology 390 The link metrics are configured as follows: 392 o Metrics of PE1-P2, PE2-P1, P1-P4, P2-P3, P3-P6, P4-P5, P5-P8, P6- 393 P7, P7-PE4, and P8-PE3 links are 11. 395 o Metrics of all other links are 5. 397 o Link metrics are bidirectional. 399 All P and PE nodes are capable of G-SRv6 compression. The SRv6 SIDs 400 are configured as follows: 402 Locator End.DT 403 PE1 2001:DB8:A1::/48 2001:DB8:A1:100:: 404 PE2 2001:DB8:A2::/48 2001:DB8:A2:100:: 405 PE3 2001:DB8:A3::/48 2001:DB8:A3:100:: 406 PE4 2001:DB8:A4::/48 2001:DB8:A4:100:: 407 P1 2001:DB8:B1::/48 - 408 P2 2001:DB8:B2::/48 - 409 P3 2001:DB8:B3::/48 - 410 P4 2001:DB8:B4::/48 - 411 P5 2001:DB8:B5::/48 - 412 P6 2001:DB8:B6::/48 - 413 P7 2001:DB8:B7::/48 - 414 P8 2001:DB8:B8::/48 - 416 End End with COC 417 PE1 2001:DB8:A1:1:: 2001:DB8:A1:2:: 418 PE2 2001:DB8:A2:1:: 2001:DB8:A2:2:: 419 PE3 2001:DB8:A3:1:: 2001:DB8:A3:2:: 420 PE4 2001:DB8:A4:1:: 2001:DB8:A4:2:: 421 P1 2001:DB8:B1:1:: 2001:DB8:B1:2:: 422 P2 2001:DB8:B2:1:: 2001:DB8:B2:2:: 423 P3 2001:DB8:B3:1:: 2001:DB8:B3:2:: 424 P4 2001:DB8:B4:1:: 2001:DB8:B4:2:: 425 P1 2001:DB8:B5:1:: 2001:DB8:B5:2:: 426 P2 2001:DB8:B6:1:: 2001:DB8:B6:2:: 427 P3 2001:DB8:B7:1:: 2001:DB8:B7:2:: 428 P4 2001:DB8:B8:1:: 2001:DB8:B8:2:: 430 The SR Policies on PE1 are configured as follows: 432 SR Policy 1 (Strict Path to PE3) 433 Candidate Path 1 434 Preference: 20 435 Segment List: 2001:DB8:B1:2::, 2001:DB8:B3:2::, 2001:DB8:B5:2::, 436 2001:DB8:B7:2::, 2001:DB8:A3:1:: 437 Candidate Path 2 438 Preference: 10 439 Segment List: 2001:DB8:B2:2::, 2001:DB8:B4:2::, 2001:DB8:B6:2::, 440 2001:DB8:B8:2::,2001:DB8:A3:1:: 442 SR Policy 2 (Loose Path to PE4) 443 Candidate Path 1 444 Preference: 20 445 Segment List: 2001:DB8:B4:2::, 2001:DB8:B8:2::,2001:DB8:A4:1:: 447 4.1. SRv6 BE 449 In this scenario, SRv6 BE paths are used to steer the VPN service. 450 The deployments of protection are as follows: 452 o All nodes enable TI-LFA for local protection. 454 o All nodes enable BFD for links and neighbors. 456 o Ingress PE node enables FRR of SRv6 BE path to backup egress PE 457 node for service protection. 459 o Ingress PE node enables BFD for locator of egress PE node to 460 monitor the liveness of SRv6 BE path. 462 PE1 installs the SRv6 BE path to PE3 with destination address 463 2001:DB8:A3:100:: as the primary next-hop for the VPN flow. 464 Meanwhile, PE1 also installs the SRv6 BE path to PE4 with 465 destination address 2001:DB8:A4:100:: as the backup next-hop. 467 PE1 enables BFD for locator 2001:DB8:A3::/48 and 2001:DB8:A4::/48 to 468 monitor the liveness of SRv6 BE paths. 470 TI-LFA is enabled on all nodes. Take P5 for example. The shortest 471 path from P5 to PE3 is via neighbor P7. In order to provide local 472 protection for P7 node failure, P5 computes and installs the repair 473 path P5->P6->P8->PE3, using [2001:DB8:B6:2::, B8:2, A3:1] as the G- 474 SRv6 SID list. 476 All nodes use BFD to monitor the liveness of links and adjacent 477 nodes. 479 Under normal circumstances, PE1 encapsulates the VPN payload in an 480 outer IPv6 header where the destination address is 481 2001:DB8:A3:100::. 483 Assume that a failure occurs on P7. The fail-timer of BFD echo from 484 P5 to P7 expires, so P5 perceives the failure. When P5 forwards the 485 VPN packet, the TI-LFA repair path is used. Then, P5 encapsulates 486 the packet in an outer IPv6 Header with SRH carrying a compressed 487 segment-list of [2001:DB8:B6:2::, B8:2, A3:1], as shown in the 488 following figure. The packet is forwarded in the repair path P5->P6- 489 >P8->PE3 according to the outer IPv6 Header and SRH. So the failure 490 is repaired by local protection. 492 ------------------------ 493 | IPv6 Header | 494 | DA = 2001:DB8:B6:2:: | 495 ------------------------ 496 | SRH | 497 |Seg[0]= B8:2|A3:1 | 498 |Seg[1]= 2001:DB8:B6:2:: | 499 ------------------------ ------------------------ 500 | IPv6 Header | | IPv6 Header | 501 | DA = 2001:DB8:A3:100:: | | DA = 2001:DB8:A3:100:: | 502 ------------------------ ------------------------ 503 | VPN Payload | | VPN Payload | 504 ------------------------ ------------------------ 506 P3 ---> P5 ---> P6 508 Assume that a failure occurs on PE3. TI-LFA does not work and the 509 packets along the SRv6 BE path are dropped. Then the BFD session 510 from PE1 to locator 2001:DB8:A3::/48 is down, so PE1 triggers the 511 switchover to the SRv6 BE path to PE4 and encapsulates the VPN 512 payload in an outer IPv6 header where the destination address is 513 2001:DB8:A4:100::. After that, the VPN traffic from CE1 to CE2 is 514 recovered. 516 4.2. SRv6 TE 518 In this scenario, the SRv6 TE strict path with G-SRv6 compression is 519 used to steer the VPN traffic flows to the primary egress node PE3, 520 and the SRv6 TE loose path with G-SRv6 compression is used for the 521 backup egress node PE4. 523 The deployments of protection are as follows: 525 o In the SR Policy of SRv6 TE strict path, disjoint backup 526 candidate path is used as hot standby for end-to-end protection. 528 o Ingress PE node uses SRv6 BE paths as backup for end-to-end 529 protection of SRv6 TE paths. 531 o Ingress PE node enables BFD for SR Policy. In the case of SRv6 TE 532 strict path, the reverse path of BFD packet keeps consistent with 533 forward path. 535 o Ingress PE node enables BFD for locator of egress PE node to 536 monitor the liveness of SRv6 BE path. 538 o Ingress PE node enables FRR of paths to backup egress PE node for 539 service protection. 541 o All nodes enable TI-LFA for local protection. All nodes enable 542 BFD for links and neighbors. 544 PE1 installs SR Policy 1, which is the SRv6 TE strict path to PE3, 545 as the primary next-hop for the VPN flow. SR Policy 1 has two 546 disjoint candidate paths. The candidate path with higher preference 547 is selected as the primary candidate path, and the candidate path 548 with lower preference is selected as hot standby backup. 550 Meanwhile, the SRv6 BE path to PE3, the SRv6 TE loose path to PE4 551 (SR Policy 2), and the SRv6 BE path to PE4 are also installed as 552 backup next-hops. The priorities of multiple backup paths may be 553 decided by either of the egress-node-first strategy or the TE-first 554 strategy. 556 Egress-node-first strategy: 558 o primary: SRv6 TE path to primary egress node PE3 (SR Policy 1) 560 o backup(1st priority): SRv6 BE path to primary egress node PE3 562 o backup(2nd priority): SRv6 TE path to backup egress node PE4 (SR 563 Policy 2) 565 o backup(3rd priority): SRv6 BE path to backup egress node PE4 567 TE-first strategy: 569 o primary: SRv6 TE path to primary egress node PE3 (SR Policy 1) 570 o backup(1st priority): SRv6 TE path to backup egress node PE4 (SR 571 Policy 2) 573 o backup(2nd priority): SRv6 BE path to primary egress node PE3 575 o backup(3rd priority): SRv6 BE path to backup egress node PE4 577 Egress-node-first strategy is used as an example below. 579 PE1 enables BFD for SR Policy 1 and SR Policy 2 to monitor the 580 liveness of SRv6 TE paths. For SR Policy 1 which is the strict path, 581 the forward and reverse paths of BFD packet should be the same. For 582 example, the primary path of SR Policy 1 is PE1->P1->P3->P5->P7- 583 >PE3, so the reverse path should be PE3->P7->P5->P3->P1->PE1. A 584 segment list of such reverse path is installed on PE3, and the BSID 585 is 2001:DB8:A3:200. PE1 may send BFD echo packet with the segment 586 list of SR Policy 1 along with the BSID of reverse path, which is 587 [2001:DB8:B1:2::, B3:2, B5:2, B7:2, A3:1, 2001:DB8:A3:200]. When the 588 BFD echo packet is forwarded along the strict path to PE3, PE3 will 589 add an outer IPv6 header with SRH carrying the segment list of 590 [2001:DB8:B7:2::, B5:2, B3:2, B1:2, A1:1], which instructs the 591 packet to be forwarded along the same strict path back to PE1. 593 PE1 enables BFD for locator 2001:DB8:A3::/48 and 2001:DB8:A4::/48 to 594 monitor the liveness of SRv6 BE paths. 596 TI-LFA is enabled on all nodes. BFD are used to monitor the liveness 597 of links and adjacent nodes. 599 Under normal circumstances, PE1 encapsulates the VPN payload in an 600 outer IPv6 header with SRH carrying the segment list of primary 601 candidate path of SR Policy 1 along with the VPN SID advertised by 602 PE3. Using G-SRv6 compression, the segment list will be encoded as 603 [2001:DB8:B1:2::, B3:2, B5:2, B7:2, A3:1, 2001:DB8:A3:100::]. 605 Assume that a failure occurs on P3. The packets are dropped since 606 the failed P3 is on the path. The BFD session of the segment list in 607 the primary candidate path of SR Policy 1 is down, so PE1 triggers 608 the switchover to the backup candidate path of SR Policy 1. Then PE1 609 encapsulates the VPN payload in an outer IPv6 header with SRH 610 carrying the segment list of [2001:DB8:B2:2::, B4:2, B6:2, B8:2, 611 A3:1, 2001:DB8:A3:100::]. 613 Before the recovery of P3, assume that P6 also fails. The BFD 614 session of the segment list in the backup candidate path of SR 615 Policy 1 is also down. Then PE1 triggers the switchover to the 1st 616 priority backup next-hop which is the SRv6 BE path to PE3. PE1 617 encapsulates the VPN payload in an outer IPv6 header where the 618 destination address is 2001:DB8:A3:100::. 620 Assume that a failure occurs on PE3. Both the BFD sessions of SR 621 Policy 1 and locator 2001:DB8:A3::/48 are down, which means the 622 primary next-hop and the 1st priority backup next-hop are down. So 623 PE1 triggers the switchover to the 2nd priority backup next-hop, 624 which is the SRv6 TE loose path to PE4. Then PE1 encapsulates the 625 VPN payload in an outer IPv6 header with SRH carrying the segment 626 list of [2001:DB8:B4:2::, B8:2, A4:1, 2001:DB8:A4:100::]. 628 Before the recovery of PE3, assume that a failure occurs on P6. The 629 fail-timer of BFD echo from P4 to P6 expires, so P4 perceives the 630 failure. When P4 forwards the VPN packet, the TI-LFA repair path is 631 used. Then, P4 encapsulates the packet in an outer IPv6 Header with 632 SRH carrying a compressed segment-list of [2001:DB8:B3:2::, B5:2, 633 A8:1]. The packet is forwarded in the repair path P4->P3->P5->P8 634 according to the outer IPv6 Header and SRH. So the failure is 635 repaired by local protection. 637 Before the recovery of PE3, assume that a failure occurs on P8. When 638 P6 forwards the VPN packet to destination address 2001:DB8:B8:2:: 639 which is one of the segments in the segment list of SRH, the TI-LFA 640 on P6 does not work, since the failed node P8 is the destination. So 641 the packets are dropped. The BFD session of SR Policy 2 is down, and 642 PE1 triggers the switchover to the 3rd priority backup next-hop 643 which is the SRv6 BE path to PE4. Then PE1 encapsulates the VPN 644 payload in an outer IPv6 header where the destination address is 645 2001:DB8:A4:100::. If the routing convergence is not completed at 646 the moment, P6 will use TI-LFA repair path P6->P5->P7->PE4 to 647 forward the packet. After the routing convergence is done, P nodes 648 will forward the packet along new shortest path excluding P8. 650 5. Security Considerations 652 TBD. 654 6. IANA Considerations 656 This document has no IANA actions. 658 7. Contributors 660 In addition to the authors listed on the front page, the following 661 co-authors have also contributed to this document: 663 Mengxiao Chen 664 H3C 665 Email: chen.mengxiao@h3c.com 667 8. References 669 8.1. Normative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, March 1997. 674 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 675 2119 Key Words", BCP 14, RFC 8174, May 2017 677 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 678 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 679 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 680 . 682 [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, 683 K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment 684 Routing Policy Architecture", draft-ietf-spring-segment- 685 routing-policy-18 (work in progress), February 2022. 687 [I-D.ietf-spring-srv6-srh-compression] Cheng, W., Filsfils, C., Li, 688 Z., Decraene, B., Cai, D., Clad, F., Zadok, S., Guichard, 689 J., Aihua, L., Raszuk, R. and C. Li, " Compressed SRv6 690 Segment List Encoding in SRH", draft-ietf-spring-srv6-srh- 691 compression-00 (work in progress), February 2022. 693 [I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A., 694 Filsfils, C., Francois, P., Decraene, B., and D. Voyer, 695 "Topology Independent Fast Reroute using Segment Routing", 696 draft-ietf-rtgwg-segment-routing-ti-lfa-08 (work in 697 progress), January 2022. 699 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 700 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 701 . 703 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 704 Pallagatti, "Seamless Bidirectional Forwarding Detection 705 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 706 . 708 8.2. Informative References 710 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 711 Decraene, B., Litkowski, S., and R. Shakir, "Segment 712 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 713 July 2018, . 715 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 716 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 717 (SRv6) Network Programming", RFC 8986, DOI 718 10.17487/RFC8986, February 2021, . 721 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 722 IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 723 10.17487/RFC5286, September 2008, . 726 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 727 5714, DOI 10.17487/RFC5714, January 2010, 728 . 730 [I-D.bashandy-rtgwg-segment-routing-uloop] Bashandy, A., Filsfils, 731 C., Litkowski, S., Decraene, B., Francois, P. and P., 732 Psenak, "Loop avoidance using Segment Routing", draft- 733 bashandy-rtgwg-segment-routing-uloop-12 (work in 734 progress), December 2021. 736 [I-D.ietf-rtgwg-srv6-egress-protection] Hu, Z., Chen, H., Chen, H., 737 Wu, P., Toy, M., Cao, C., He, T., Liu, L., and X. Liu, 738 "SRv6 Path Egress Protection", Work in Progress, Internet- 739 Draft, draft-ietf-rtgwg-srv6- egress-protection-04, 17 740 October 2021, . 743 Authors' Addresses 745 Yisong Liu 746 China Mobile 747 China 749 Email: liuyisong@chinamobile.com 751 Weiqiang Cheng 752 China Mobile 753 China 755 Email: chengweiqiang@chinamobile.com 757 Changwang Lin 758 New H3C Technologies 759 China 761 Email: linchangwang.04414@h3c.com 763 Xuesong Geng 764 Huawei Technologies 765 China 767 Email: gengxuesong@huawei.com 769 Yao Liu 770 ZTE Corp. 771 China 773 Email: liu.yao71@zte.com.cn