idnits 2.17.1 draft-chen-rtgwg-srv6-midpoint-protection-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (19 December 2021) is 859 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SL' is mentioned on line 273, but not defined == Missing Reference: '1-N' is mentioned on line 228, but not defined == Unused Reference: 'I-D.ietf-lsr-isis-srv6-extensions' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lsr-ospfv3-srv6-extensions' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'I-D.hu-spring-segment-routing-proxy-forwarding' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 391, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-18 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-03 == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-15 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 == Outdated reference: A later version (-09) exists of draft-li-rtgwg-enhanced-ti-lfa-05 Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft China Telecom 4 Intended status: Experimental Z. Hu 5 Expires: 22 June 2022 Huawei Technologies 6 H. Chen 7 Futurewei 8 X. Geng 9 Huawei Technologies 10 Y. Liu 11 China Mobile 12 G. Mishra 13 Verizon Inc. 14 19 December 2021 16 SRv6 Midpoint Protection 17 draft-chen-rtgwg-srv6-midpoint-protection-06 19 Abstract 21 The current local repair mechanism, e.g., TI-LFA, allows local repair 22 actions on the direct neighbors of the failed node to temporarily 23 route traffic to the destination. This mechanism could not work 24 properly when the failure happens in the destination point or the 25 link connected to the destination. In SRv6 TE, the IPv6 destination 26 address in the outer IPv6 header could be the dedicated endpoint of 27 the TE path rather than the destination of the TE path. When the 28 endpoint fails, local repair couldn't work on the direct neighbor of 29 the failed endpoint either. This document defines midpoint 30 protection for SRv6 TE path, which enables the direct neighbor of the 31 failed endpoint to do the function of the endpoint, replace the IPv6 32 destination address to the other endpoint, and choose the next hop 33 based on the new destination address. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in [RFC2119] [RFC8174] 40 when, and only when, they appear in all capitals, as shown here. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 22 June 2022. 59 Copyright Notice 61 Copyright (c) 2021 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. SRv6 Midpoint Protection Mechanism . . . . . . . . . . . . . 3 77 3. SRv6 Midpoint Protection Example . . . . . . . . . . . . . . 3 78 4. SRv6 Midpoint Protection Behavior . . . . . . . . . . . . . . 5 79 4.1. Transit Node as Repair Node . . . . . . . . . . . . . . . 5 80 4.2. Endpoint Node as Repair Node . . . . . . . . . . . . . . 6 81 4.3. Endpoint x Node as Repair Node . . . . . . . . . . . . . 6 82 5. Determining whether the Endpoint could Be Bypassed . . . . . 7 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 88 9.2. Informative References . . . . . . . . . . . . . . . . . 8 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 The current mechanism, e.g., TI-LFA 94 ([I-D.ietf-rtgwg-segment-routing-ti-lfa]), allows local repair 95 actions on the direct neighbors of the failed node to temporarily 96 route traffic to the destination. This mechanism could not work 97 properly when the failure happens in the destination point or the 98 link connected to the destination. In SRv6 TE, the IPv6 destination 99 address in the outer IPv6 header could be the dedicated endpoint of 100 the TE path rather than the destination of the TE path ([RFC8986]). 101 When the endpoint fails, local repair couldn't work on the direct 102 neighbor of the failed endpoint either. This document defines 103 midpoint protection for SRv6 TE path, which enables the direct 104 neighbor of the failed endpoint to do the function of the endpoint, 105 replace the IPv6 destination address to the other endpoint, and 106 choose the next hop based on the new destination address. 108 2. SRv6 Midpoint Protection Mechanism 110 When an endpoint node fails, the packet needs to bypass the failed 111 endpoint node and be forwarded to the next endpoint node of the 112 failed endpoint. There are two stages or time periods after an 113 endpoint node fails. The first is the time period from the failure 114 until the IGP converges on the failure. The second is the time 115 period after the IGP converges on the failure. 117 During the first time period, the packet will be sent to the direct 118 neighbor of the failed endpoint node. After detecting the failure of 119 its interface to the failed endpoint node, the neighbor forwards the 120 packets around the failed endpoint node. It changes the IPv6 121 destination address with the IPv6 address of the next endpoint node 122 (or the last or other reasonable endpoint node) which could avoid 123 going through the failed endpoint. 125 During the second time period, the packet of a SRv6 TE path may not 126 be sent to the direct neighbor of the failed endpoint node. There is 127 no route to the failed endpoint node after the IGP converges. When a 128 previous hop node of the failed endpoint node finds out that there is 129 no route to the IPv6 destination address (of the failed endpoint 130 node), it changes the IPv6 destination address with the IPv6 address 131 of the next endpoint node. Note that the previous hop node may not 132 be the direct neighbor of the failed endpoint node. 134 3. SRv6 Midpoint Protection Example 136 The topology in Figure 1 illustrates an example of network topology 137 with SRv6 enabled on each node. 139 +-----+ +-----+ 140 | N5 |-----------| N6 |--------------+ 141 +-----+ +-----+ | 142 | | | 143 | | | 144 | | | 145 +-----+ +-----+ +-----+ +-----+ 146 | N1 |-----------| N2 |-----------| N3 |-----------| N4 | 147 +-----+ +-----+ +-----+ +-----+ 149 Figure 1: An example of network for midpoint protection 151 In this document, an end SID at node n with locator block B is 152 represented as B:n. An end.x SID at node n towards node k with 153 locator block B is represented as B:n:k. A SID list is represented 154 as where S1 is the first SID to visit, S2 is the second 155 SID to visit and S3 is the last SID to visit along the SRv6 TE path. 157 In the reference topology, suppose that Node N1 is an ingress node of 158 SRv6 TE path going through N3 and N4. Node N1 steers a packet into a 159 segment list < B:3, B:4>. 161 When node N3 fails, the packet needs to bypass the failed endpoint 162 node and be forwarded to the next endpoint node after the failed 163 endpoint in the TE path. When outbound interface failure happens in 164 the Repair Node (which is not limited to the previous hop node of the 165 failed endpoint node), it performs the proxy forwarding as follows: 167 During the first time period (i.e., before the IGP converges), node 168 N2 (direct neighbor of N3) as a Repair Node forwards the packets 169 around the failed endpoint N3 after detecting the failure of the 170 outbound interface to the endpoint B:3. It changes the IPv6 171 destination address with the next sid B:4. N2 detects the failure of 172 outbound interface to B:4 in the current route, it could use the 173 normal Ti-LFA repair path to forward the packet, because it is not 174 directly connected to the node N4. N2 encapsulates the packet with 175 the segment list < B:5:6> as a repair path. 177 During the second time period (i.e., after the IGP converges), node 178 N1 does not have any route to the failed endpoint N3 in its FIB. 179 Node N1, as a Repair Node, forwards the packets around the failed 180 endpoint N3 to the next endpoint node (e.g., N4) directly. There is 181 no need to check whether the failed endpoint node is directly 182 connected to N1. N1 changes the IPv6 destination address with the 183 next sid B:4. Since IGP has completed convergence, it forwards 184 packets directly based on the IGP SPF path 186 4. SRv6 Midpoint Protection Behavior 188 A node N protecting the failure of an endpoint node on a SRv6 path 189 may be one of the following types: 191 * a transit node: the destination address (DA) of the packet 192 received by N is not N's local SID. 194 * an endpoint node: the destination address (DA) of the packet 195 received by N is a N's local END SID. 197 * an endpoint x node (i.e., an endpoint with cross-connect node): 198 the destination address (DA) of the packet received by N is a N's 199 local End.X SID with an array of layer 3 adjacencies. 201 This section describes the behavior of each of these nodes as a 202 repair node for the two time periods after the endpoint node fails. 204 4.1. Transit Node as Repair Node 206 When the Repair Node is a transit node, it provides fast protection 207 against the endpoint node failure as follows after looking up the 208 FIB. 210 IF the primary outbound interface used to forward the packet failed 211 IF NH = SRH && SL != 0 and 212 the failed endpoint is directly connected to Repair Node THEN 213 SL decreases*; update the IPv6 DA with SRH[SL]; 214 FIB lookup on the updated DA; 215 forward the packet according to the matched entry; 216 ELSE 217 forward the packet according to the backup nexthop; 218 ELSE IF there is no FIB entry for forwarding the packet THEN 219 IF NH = SRH && SL != 0 THEN 220 SL decreases*; update the IPv6 DA with SRH[SL]; 221 FIB lookup on the updated DA; 222 forward the packet according to the matched entry; 223 ELSE 224 drop the packet; 225 ELSE 226 forward accordingly to the matched entry; 228 *: SL could be decreased by any dedicated value from [1-N], 229 where N is the current value of SL. 231 4.2. Endpoint Node as Repair Node 233 When the Repair Node is an endpoint node, it provides fast 234 protections for the failure through executing the following procedure 235 after looking up the FIB for the updated DA. 237 IF the primary outbound interface used to forward the packet failed 238 IF NH = SRH && SL != 0 and 239 the failed endpoint is directly connected to Repair Node THEN 240 SL decreases; update the IPv6 DA with SRH[SL]; 241 FIB lookup on the updated DA; 242 forward the packet according to the matched entry; 243 ELSE 244 forward the packet according to the backup nexthop; 245 ELSE IF there is no FIB entry for forwarding the packet THEN 246 IF NH = SRH && SL != 0 THEN 247 SL decreases; update the IPv6 DA with SRH[SL]; 248 FIB lookup on the updated DA; 249 forward the packet according to the matched entry; 250 ELSE 251 drop the packet; 252 ELSE 253 forward accordingly to the matched entry; 255 4.3. Endpoint x Node as Repair Node 257 When the Repair Node is an endpoint x node, it provides fast 258 protections for the failure through executing the following procedure 259 after updating DA. 261 IF the layer-3 adjacency interface is down THEN 262 FIB lookup on the updated DA; 263 IF the primary interface used to forward the packet failed THEN 264 IF NH = SRH && SL != 0 and 265 the failed endpoint directly connected to Repair Node THEN 266 SL decreases; update the IPv6 DA with SRH[SL]; 267 FIB lookup on the updated DA; 268 forward the packet according to the matched entry; 269 ELSE 270 forward the packet according to the backup nexthop; 271 ELSE IF there is no FIB entry for forwarding the packet THEN 272 IF NH = SRH && SL != 0 THEN 273 SL decreases; update the IPv6 DA with SRH[SL]; 274 FIB lookup on the updated DA; 275 forward the packet according to the matched entry; 276 ELSE 277 drop the packet; 278 ELSE 279 forward accordingly to the matched entry; 281 5. Determining whether the Endpoint could Be Bypassed 283 SRv6 Midpoint Protection provides a mechanism to bypass a failed 284 endpoint. But in some scenarios, some important functions may be 285 implemented in the bypassed failed endpoints that should not be 286 bypassed, such as firewall functionality or In-situ Flow Information 287 Telemetry of a specified path. Therefore, a mechanism is needed to 288 indicate whether an endpoint can be bypassed or not. 289 [I-D.li-rtgwg-enhanced-ti-lfa] provides method to determine whether 290 enbale SRv6 midpoint protection or not by defining a "no bypass" flag 291 for the SIDs in IGP. 293 6. Security Considerations 295 This section reviews security considerations related to SRv6 Midpoint 296 protection processing discussed in this document.To ensure that the 297 Repair node does not modify the SRH header Encapsulated by nodes 298 outside the SRv6 Domain.Only the segment within the SRH is same 299 domain as the repair node. So it is necessary to check the skipped 300 segment have same block as repair node. 302 7. IANA Considerations 304 This document makes no request of IANA. 306 Note to RFC Editor: this section may be removed on publication as an 307 RFC. 309 8. Acknowledgements 311 9. References 313 9.1. Normative References 315 [I-D.ietf-lsr-isis-srv6-extensions] 316 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 317 Z. Hu, "IS-IS Extensions to Support Segment Routing over 318 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 319 ietf-lsr-isis-srv6-extensions-18, 20 October 2021, 320 . 323 [I-D.ietf-lsr-ospfv3-srv6-extensions] 324 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 325 "OSPFv3 Extensions for SRv6", Work in Progress, Internet- 326 Draft, draft-ietf-lsr-ospfv3-srv6-extensions-03, 19 327 November 2021, . 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, 332 DOI 10.17487/RFC2119, March 1997, 333 . 335 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 336 Scope Link State PDUs (LSPs)", RFC 7356, 337 DOI 10.17487/RFC7356, September 2014, 338 . 340 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 341 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 342 May 2017, . 344 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 345 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 346 (SRv6) Network Programming", RFC 8986, 347 DOI 10.17487/RFC8986, February 2021, 348 . 350 9.2. Informative References 352 [I-D.hu-spring-segment-routing-proxy-forwarding] 353 Hu, Z., Chen, H., Yao, J., Bowers, C., Yongqing, and 354 Yisong, "SR-TE Path Midpoint Restoration", Work in 355 Progress, Internet-Draft, draft-hu-spring-segment-routing- 356 proxy-forwarding-15, 24 October 2021, 357 . 360 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 361 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 362 Decraene, B., and D. Voyer, "Topology Independent Fast 363 Reroute using Segment Routing", Work in Progress, 364 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 365 07, 29 June 2021, . 368 [I-D.ietf-spring-segment-routing-policy] 369 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 370 P. Mattes, "Segment Routing Policy Architecture", Work in 371 Progress, Internet-Draft, draft-ietf-spring-segment- 372 routing-policy-14, 25 October 2021, 373 . 376 [I-D.li-rtgwg-enhanced-ti-lfa] 377 Li, C., Hu, Z., Zhu, Y., and S. Hegde, "Enhanced Topology 378 Independent Loop-free Alternate Fast Re-route", Work in 379 Progress, Internet-Draft, draft-li-rtgwg-enhanced-ti-lfa- 380 05, 21 October 2021, . 383 [I-D.sivabalan-pce-binding-label-sid] 384 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 385 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 386 in PCE-based Networks.", Work in Progress, Internet-Draft, 387 draft-sivabalan-pce-binding-label-sid-07, 8 July 2019, 388 . 391 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 392 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 393 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 394 2009, . 396 Authors' Addresses 397 Huanan Chen 398 China Telecom 399 109, West Zhongshan Road, Tianhe District 400 Guangzhou 401 510000 402 China 404 Email: chenhuan6@chinatelecom.cn 406 Zhibo Hu 407 Huawei Technologies 408 Huawei Bld., No.156 Beiqing Rd. 409 Beijing 410 100095 411 China 413 Email: huzhibo@huawei.com 415 Huaimo Chen 416 Futurewei 417 Boston, MA, 418 United States of America 420 Email: Huaimo.chen@futurewei.com 422 Xuesong Geng 423 Huawei Technologies 425 Email: gengxuesong@huawei.com 427 Yisong Liu 428 China Mobile 430 Email: liuyisong@chinamobile.com 432 Gyan S. Mishra 433 Verizon Inc. 434 13101 Columbia Pike 435 Silver Spring, MD 20904 436 United States of America 438 Phone: 301 502-1347 439 Email: gyan.s.mishra@verizon.com