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