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