idnits 2.17.00 (12 Aug 2021) /tmp/idnits17750/draft-cheng-rtgwg-srv6-multihome-egress-protection-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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC3849-compliant IPv6 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 (April 27, 2022) is 17 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: '0' on line 283 -- Looks like a reference, but probably isn't: '1' on line 321 -- Looks like a reference, but probably isn't: '4' on line 381 == Outdated reference: A later version (-19) exists of draft-hu-spring-segment-routing-proxy-forwarding-18 == Outdated reference: A later version (-05) exists of draft-ietf-rtgwg-srv6-egress-protection-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 rtgwg Working Group W. Cheng 2 Internet-Draft W. Jiang 3 Intended status: Standards Track China Mobile 4 Expires: October 26, 2022 C. Lin 5 Y. Qiu 6 New H3C Technologies 7 April 27, 2022 9 SRv6 Egress Protection in Multi-home scenario 10 draft-cheng-rtgwg-srv6-multihome-egress-protection-00 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on October 26, 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 This document describes a SRv6 egress node protection mechanism in 53 multi-home scenarios. 55 Table of Contents 57 1. Introduction ................................................. 2 58 2. Terminology .................................................. 3 59 3. Multi-home SRv6 Egress Protection Mechanism .................. 3 60 3.1. B-flag in Segment Routing Header ........................ 3 61 3.2. Procedure of Multi-home Egress Protection on SRv6 TE Path 3 62 3.2.1. Procedure on the Ingress Endpoint .................. 4 63 3.2.2. Procedure on the Penultimate Endpoint .............. 6 64 3.3. Procedure of Multi-home Egress Protection on SRv6 BE Path 7 65 4. Multi-home SRv6 Egress Protection Example .................... 8 66 5. IANA Considerations ......................................... 10 67 6. Security Considerations ..................................... 10 68 7. References .................................................. 11 69 7.1. Normative References ................................... 11 70 7.2. Informative References ................................. 12 71 8. Acknowledgments ............................................. 12 72 Authors' Addresses ............................................. 12 74 1. Introduction 76 The fast protection of a transit node of a Segment Routing (SR) path 77 or tunnel is described in [I-D.ietf-rtgwg-segment-routing-ti-lfa] 78 and [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8400] 79 specifies the fast protection of egress node(s) of an MPLS TE LSP 80 tunnel including P2P TE LSP tunnel and P2MP TE LSP tunnel in details. 81 However, these documents do not discuss the fast protection of the 82 egress node of a Segment Routing for IPv6 (SRv6) path or tunnel. 84 [I-D.ietf-rtgwg-srv6-egress-protection] proposes mirror protection 85 mechanism and presents protocol extensions for the fast protection 86 of the egress node of a SRv6 path or tunnel. However, the mechanism 87 provided in this document is relatively complex. It is necessary to 88 configure the Mirror SID for the protected egress node on the backup 89 egress node. The mirror relationship is distributed through IGP and 90 BGP protocols to automatically create mapping entries. 92 This document introduces a simplified protection mechanism of the 93 egress node of a SRv6 path. Only expanding the data plane can 94 perform fast path switching in case of egress node failure. 96 2. Terminology 98 The following terminologies are used in this document. 100 SR: Segment Routing 102 SRv6: SR for IPv6 104 SRH: Segment Routing Header 106 SID: Segment Identifier 108 CE: Customer Edge 110 PE: Provider Edge 112 VPN: Virtual Private Network 114 3. Multi-home SRv6 Egress Protection Mechanism 116 This section describes the mechanism of SRv6 path egress protection 117 in multi-home scenarios and the extension of SRH extension header. 119 3.1. B-flag in Segment Routing Header 121 [RFC8754] describes the Segment Routing Header (SRH) and how SR 122 capable nodes use it. The SRH contains an 8-bit "Flags" field. 124 This document defines the following bit in the SRH Flags field to 125 carry the B-flag: 127 0 1 2 3 4 5 6 7 128 +-+-+-+-+-+-+-+-+ 129 | |B| | 130 +-+-+-+-+-+-+-+-+ 131 Where: 133 - B-flag: The marking bit of carrying backup SID in segment list. If 134 the B-flag is set to 1, a backup SID is carried in the segment list. 136 3.2. Procedure of Multi-home Egress Protection on SRv6 TE Path 138 The Figure 1 is used to explain the multi-home egress node 139 protection mechanism. 141 Locator: A3:1::/64 142 VPN SID: A3:1::B100 143 +---+ *** +---+ *** +---+ *** +---+ +---+ 144 |PE1|-----| P1|-----| P2|-----|PE3|---|CE2| 145 +---+ +---+ +---+ +---+ +---+ 146 / | | | | \ / 147 +---+/ | | | | \ / 148 |CE1| | | | | X 149 +---+\ | | | | / \ 150 \ | | | | / \ 151 +---+ +---+ +---+ +---+ +---+ 152 |PE2|-----| P3|-----| P4|-----|PE4|---|CE3| 153 +---+ +---+ +---+ +---+ +---+ 154 Locator: A4:1::/64 155 VPN SID: A4:1::B100 156 PE3 Egress 157 PE4 Backup Egress 158 CEx Customer Edge 159 Px Non-Provider Edge 160 *** SR Path 161 Figure 1 163 3.2.1. Procedure on the Ingress Endpoint 165 In the multi-home or dual-home scenario, after the ingress node 166 learns the multi-home or dual-home route through routing protocol, 167 it determines the optimal path and suboptimal path according to the 168 route optimization strategy. The egress node on the optimal path is 169 an primary egress, and the SID of the primary egress node is used as 170 the primary SID The egress node on the suboptimal path is an backup 171 egress,and the SID of the backup egress node is used as the backup 172 SID. 174 On the path forwarded based on SRv6 TE policy, when the ingress node 175 encapsulates the SRH extension header, judge whether the primary VPN 176 SID of the egress node (PE1) has a backup SID. If yes, insert the 177 backup SID into the position of SRH[Last Entry], and set B-flag to 1 178 to identify that the backup SID has been carried in the last 179 position of the segment list, then the value of SL is set to n-1. The 180 format of SRH extension header filling is shown in the following 181 figure 2. 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Next Header | Hdr Ext Len | Routing Type | SL = n-1 | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Last Entry=n |Flags(B-flag=1)| Tag | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 | Active SID (Segment List[0], 128 bits IPv6 address) | 192 | | 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 ~ ... ~ 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | 198 | Segment List[n-1] (128 bits IPv6 address) | 199 | | 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 | Backup SID (Segment List[n],128 bits IPv6 value) | 204 | | 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 // Optional Type Length Value objects (variable) // 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 2 211 3.2.2. Procedure on the Penultimate Endpoint 213 Normally, the traffic is forwarded along the path P1->P2->PE3->CE2. 214 When primary egress node (PE3) fails, P2 finds out that the PE3's 215 SID is unreachable and the B-flag value is set. Then P2 modifies the 216 destination address of the packet to SRH[Last Entry] which is the 217 backup SID, and sends the modified packet to backup egress node 218 (PE4). Through this method P2 can provide fast protection for the 219 egress failure. 221 The detailed processing can be described in two cases according to 222 the endpoint behavior of the destination address of the packet 223 received by P2. 225 The behavior of the local endpoint is END.X 227 When receiving a packet destined to a local End.X SID whose 228 outgoing interface is down, the penultimate endpoint acting as a 229 Repair Node can provide fast protection for the failure of 230 directly connected egress nodes after SL decreasing through 231 executing the following procedures. 233 IF B-flag = 1 THEN 234 IF SL = 0 and the failed egress node is directly connected to 235 Repair Node THEN 236 Update the IPv6 DA with SRH[Last Entry]; 237 FIB lookup on the updated DA; 238 Forward the packet according to the matched entry; 239 ELSE IF SL = 1 and SRH[1] and SRH[0] are the SIDs of the 240 failed egress node directly connected to Repair Node THEN 241 Update the IPv6 DA with SRH[Last Entry]; 242 FIB lookup on the updated DA; 243 Forward the packet according to the matched entry; 245 The behavior of the local endpoint is END 247 After looking up the FIB for the updated DA with Segment 248 List[Segments Left] and SL decreasing, in the following two cases, 249 the penultimate endpoint acting as a Repair Node can provide fast 250 protections for the failure of directly connected egress nodes 251 through executing the following procedure. 253 Case 1: For the packet whose Next Header is SRH and Segments Left 254 is equal to 1, perform the following processing: 256 IF B-flag = 1 and SRH[1] and SRH[0] are the SIDs of the failed 257 egress node directly connected to Repair Node THEN 258 Update the IPv6 DA with SRH[Last Entry]; 259 FIB lookup on the updated DA; 260 Forward the packet according to the matched entry; 262 Case 2: For the packet whose Next Header is SRH and Segments Left 263 is equal to 0, perform the following processing: 265 IF B-flag = 1 and the failed egress endpoint is directly 266 connected to Repair Node THEN 267 Update the IPv6 DA with SRH[Last Entry]; 268 FIB lookup on the updated DA; 269 Forward the packet according to the matched entry; 271 When the packet arrives at PE4, PE4 removes the outer IPv6 header, 272 and forwards the exposed inner packet. 274 After the route convergence is completed, the ingress node (PE1) 275 will reselect the forwarding path for the traffic to VPN, and switch 276 the path P1->P3->P4->PE4->CE2 to the CE to the egress node (PE4). 277 After that, P2 no longer needs to forward the packet with the 278 destination address of PE3. 280 Considering that the egress node may check the consistency between 281 the segment list and the destination address, for the packet with B- 282 flag 1, as long as the destination address is the same as any one of 283 SRH[0] or SRH[Last Entry], it is considered to be consistent. 285 In addition, when a penultimate endpoint using non-PSP-flavored SID 286 receives a packet with B-flag of 1, it is recommended to directly 287 remove the SRH extension header after replacing the destination 288 address with SRH[Last Entry]. 290 3.3. Procedure of Multi-home Egress Protection on SRv6 BE Path 292 The multi-home egress node protection processing on the SRv6 BE path 293 is consistent with that on the SRv6 TE path, except that the ingress 294 node is required to add an SRH extension header with the active SID, 295 backup SID and B-flag when encapsulating the outer IPv6 packet 296 header. 298 In the multi-home scenario egress node scenario, the ingress node 299 determines the active SID (PE3's SID) and the backup SID (PE4's SID) 300 of the egress node through the optimization strategy of the routing 301 protocol. 303 When the traffic from PE1 to CE2 is forwarded through the SRv6 BE 304 path, in order to realize the fast protection of egress node failure, 305 when the ingress node adds an outer IPv6 packet header to the 306 forwarded packet, it must encapsulate the SRH extension header at 307 the same time. The contents filled in the SRH extension header are 308 the same as Figure 2 in Section 3.2.1, in which the segment list 309 only fills in the active SID and backup SID, the SL is set to 0, the 310 last entry is set to 1, and the B-flag is set to 1. The active SID 311 is used as the destination address of the outer IP packet header. 313 Normally, because the destination address of the packet is the 314 active SID (PE3's SID), P1 and P2 will forward the packet to PE3 315 according to the destination address. 317 Once PE3 fails, the processing of the penultimate endpoint is the 318 same as that on the SRv6 TE path. When P2 finds out that the route 319 to the directly connected egress node PE3 is unreachable, if the B- 320 flag is 1, modify the destination address to the backup SID in 321 SRH[1], and send the packet to the updated destination address. 323 4. Multi-home SRv6 Egress Protection Example 325 Figure 3 shows an example of protecting egress PE3 of a SRv6 TE path, 326 which is from ingress PE1 to egress PE3. 328 Locator: A3:1::/64 329 Locator:A0:1::/64 VPN SID: A3:1::B100 330 +---+ *** +---+ *** +---+ *** +---+ +---+ 331 |PE1|-----| P1|-----| P2|-----|PE3|---|CE2| 332 +---+ +---+ +---+ +---+ +---+ 333 / | | |& | \ / 334 +---+/ | | |& | \ / 335 |CE1| | | |& | X 336 +---+\ | | |& | / \ 337 \ | | |& | / \ 338 +---+ +---+ +---+ &&& +---+ +---+ 339 |PE2|-----| P3|-----| P4|-----|PE4|---|CE3| 340 +---+ +---+ +---+ +---+ +---+ 341 Locator: A4:1::/64 342 VPN SID: A4:1::B100 343 PE3 Egress 344 PE4 Backup Egress 345 CEx Customer Edge 346 Px Non-Provider Edge 347 *** SR Path 348 &&& backup Path 349 Figure 3 351 In this document, a SID list is represented as where S1 352 is the first SID to visit, S2 is the second SID to visit and S3 is 353 the last SID to visit along the SRv6 path. 355 In Figure 3, Both CE2 and CE3 are dual home to PE3 and PE4. PE1 has 356 a locator A0:1::/64. P1 has a locator A1:1::/64. P2 has a locator 357 A2:1::/64 and END.X SID A2:1::A100. PE3 has a locator A3:1::/64 and 358 a VPN SID A3:1::B100. PE4 has a locator A4:1::/64 and VPN SID 359 A4:1::B100. The traffic from CE1 to CE2 is forwarded along the path 360 PE1->P1->P2->PE3. After the configuration, PE1 determines that PE3's 361 backup SID is PE4's VPN SID through the routing optimization 362 strategy of BGP. 364 In normal operations, after receiving a packet with destination PE3, 365 P2 forwards the packet to PE3 according to its FIB. When PE3 366 receives the packet, it sends the packet to CE2. 368 When PE1 receives the packet from CE1 to CE2, PE1 encapsulates the 369 packet with IPv6 header. The segment list in SRH is designed as 370 . The SL is 371 set to 3, the Last Entry is set to 4, and B-flag is set to 1. 373 When P2 receives a packet destined to END.X SID A2:1::A100, in 374 normal operations, it forwards the packet with source A0:1::1 and 375 destination PE3's VPN SID A3:1::B100 from the link between P2 and 376 PE3 according to END.X SID. 378 When PE3 fails, P2 receives the packet to be sent to PE3's VPN SID 379 A3:1::B100. P2 finds that the outgoing interface is down. If the B- 380 flag is 1, P2 changes the destination address of the packet with the 381 backup SID of SRH[4], removes SRH extension header and sends the 382 modified packet to A4:1::B100. 384 When PE4 receives the modified packet, it decapsulates the packet 385 and forwards the decapsulated packet by executing End.DT6 behavior 386 for an End.DT6 SID instance. 388 5. IANA Considerations 390 This document requests that IANA allocate the following registration 391 in the "Segment Routing Header Flags" sub-registry for the "Internet 392 Protocol Version 6 (IPv6) Parameters" registry maintained by IANA: 394 +-------+------------------------------+---------------+ 395 | Bit | Description | Reference | 396 +=======+==============================+===============+ 397 | 4 | B-flag | This document | 398 +-------+------------------------------+---------------+ 400 6. Security Considerations 402 [RFC8754] defines the notion of an SR domain and use of SRH within 403 the SR domain. The use of egress protection mechanism described in 404 this document is restricted to an SR domain. For example, similar 405 to the SID manipulation, B-flag manipulation is not considered as a 406 threat within the SR domain. Procedures for securing an SR domain 407 are defined the section 5.1 and section 7 of [RFC8754]. 409 This document does not impose any additional security challenges to 410 be considered beyond security threats described in [RFC8754], 411 [RFC8679] and [RFC8986]. 413 7. References 415 7.1. Normative References 417 [I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A., 418 Filsfils, C., Francois, P., Decraene, B., and D. Voyer, 419 "Topology Independent Fast Reroute using Segment Routing", 420 Work in Progress, Internet-Draft, draft-ietf-rtgwg- 421 segment-routing-ti-lfa-08, 21 January 2022, 422 . 425 [I-D.hu-spring-segment-routing-proxy-forwarding] Hu, Z., Chen, H., 426 Yao, J., Bowers, C., Yongqing, and Yisong, "SR-TE Path 427 Midpoint Restoration", Work in Progress, Internet-Draft, 428 draft-hu-spring-segment-routing-proxy-forwarding-18, 1 429 September 2022, . 432 [I-D.ietf-rtgwg-srv6-egress-protection] Hu, Z., Chen, H., Chen, H., 433 Wu, P., Toy, M., Cao, C., He T., Liu, L., Liu, X., "SRv6 434 Path Egress Protection", Work in Progress, Internet-Draft, 435 draft-ietf-rtgwg-srv6-egress-protection-04, 17 October 436 2021, < https://www.ietf.org/archive/id/draft-ietf-rtgwg- 437 srv6-egress-protection-04.txt > 439 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 440 "Extensions to RSVP-TE for Label Switched Path (LSP) 441 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 442 2018, . 444 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 445 Michel, C., and H. Chen, "MPLS Egress Protection 446 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 447 . 449 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 450 Matsushima, S., and D. Voyer, "IPv6 Segment Routing 451 Header(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 452 . 454 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 455 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 456 (SRv6) Network Programming", RFC 8986, DOI 457 10.17487/RFC8986, February 2021, . 460 7.2. Informative References 462 TBD 464 8. Acknowledgments 466 The authors would like to thank the following for their valuable 467 contributions of this document: 469 Yisong Liu 470 China Mobile 472 Authors' Addresses 474 Weiqiang Cheng 475 China Mobile 477 Email: chengweiqiang@chinamobile.com 479 Wenying Jiang 480 China Mobile 482 Email: jiangwenying@chinamobile.com 484 Changwang Lin 485 New H3C Technologies 487 Email: linchangwang.04414@h3c.com 489 Yuanxiang Qiu 490 New H3C Technologies 492 Email: qiuyuanxiang@h3c.com