idnits 2.17.1 draft-chen-rtgwg-srv6-midpoint-protection-02.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 4 instances of too long lines in the document, the longest one being 16 characters in excess of 72. 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 02, 2020) is 1422 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SL' is mentioned on line 265, but not defined == Missing Reference: '1-N' is mentioned on line 215, but not defined == Unused Reference: 'I-D.hu-spring-segment-routing-proxy-forwarding' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lsr-isis-srv6-extensions' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lsr-ospfv3-srv6-extensions' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 318, 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.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.ietf-spring-segment-routing-policy' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 367, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-08 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-08 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-00 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-15 == Outdated reference: A later version (-07) exists of draft-hegde-spring-node-protection-for-sr-te-paths-05 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 Summary: 1 error (**), 0 flaws (~~), 21 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 4, 2020 Huawei Technologies 6 H. Chen 7 Futurewei 8 X. Geng 9 Huawei Technologies 10 June 02, 2020 12 SRv6 Midpoint Protection 13 draft-chen-rtgwg-srv6-midpoint-protection-02 15 Abstract 17 The previous work in IETF has provided some mechanism, e.g., TI-LFA, 18 that allows local repair actions on the direct neighbors of the 19 failed node to temporarily route traffic to the destination. These 20 mechanism could not work properly when the failure happens in the 21 destination point or the link connected to the destination. In SRv6 22 TE, the IPv6 destination address in the outer IPv6 header could be 23 the dedicated endpoint of the TE path rather than the destination of 24 the TE path. When the endpoint fails, local repair couldn't work on 25 the direct neighbor of the failed endpoint either. This document 26 defines midpoint protection, which enables the direct neighbor of the 27 failed endpoint to do the function of the endpoint, replace the IPv6 28 destination address to the other endpoint, and choose the next hop 29 based on the 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 4, 2020. 54 Copyright Notice 56 Copyright (c) 2020 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 . . . . . . . . . . . . . . 5 77 4.3. Endpoint x Node as Repair Node . . . . . . . . . . . . . 6 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 83 8.2. Informative References . . . . . . . . . . . . . . . . . 8 84 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 87 1. Introduction 89 The previous work in IETF has provided some mechanism, e.g., TI- 90 LFA([I-D.ietf-rtgwg-segment-routing-ti-lfa]), that allows local 91 repair actions on the direct neighbors of the failed node to 92 temporarily route traffic to the destination. These mechanism could 93 not work properly when the failure happens in the destination point 94 or the link connected to the destination. In SRv6 TE, the IPv6 95 destination address in the outer IPv6 header could be the dedicated 96 endpoint of the TE path rather than the destination of the TE 97 path([I-D.ietf-spring-srv6-network-programming]). When the endpoint 98 fails, local repair couldn't work on the direct neighbor of the 99 failed endpoint either. This document defines midpoint protection, 100 which enables the direct neighbor of the failed endpoint to do the 101 function of the endpoint, replace the IPv6 destination address to the 102 other endpoint, and choose the next hop based on the new destination 103 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. On the Repair Node (i.e., the previous hop of the 110 failed endpoint node), it performs the proxy forwarding as follows : 112 o Outbound interface failure happens in the Repair Node; 114 Case 1: Route to the failed endpoint could be found in the FIB of 115 Repair Node: 117 o If the Repair Node is not directly connected to the failed 118 endpoint, the normal Ti-LFA is executed; 120 o If the Repair Node is directly connected to the failed endpoint, 121 the Repair Node forwards the packets through a bypass to the 122 failed endpoint, changing the IPv6 destination address with the 123 IPv6 address of the next, the last or other reasonable endpoint 124 nodes, which could avoid going throw the failed endpoint. 126 Case 2: Route to the failed endpoint could not be found in the FIB of 127 Repair Node: 129 o Repair Node forwards the packets through a bypass of the failed 130 endpoint to the next, the last or other reasonable endpoint node 131 directly . There is no need to check whether the failed endpoint 132 node is directly connected to the Repair Node or not. 134 3. SRv6 Midpoint Protection Example 136 The topology shown in Figure 1 illustrates an example of network 137 topology 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 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: 159 Node N1 is an ingress node of SRv6 domain. Node N1 steers a packet 160 into a segment list < B:3, B:4>. 162 When Node N3 fails, the packet needs to bypass the failed endpoint 163 node and be forwarded to the next endpoint node after the failed 164 endpoint in the TE path. When outbound interface failure happens in 165 the Repair Node (which is not limited to the previous hop node of the 166 failed endpoint node), it performs the proxy forwarding as follows,: 168 For node N2, if the outbound interface to the endpoint B:3 is failed 169 before IGP converges: 171 o Because node N2, as a Repair Node, is connected to the failed 172 endpoint B:3 directly, node N2 forwards the packets through a 173 bypass of the failed endpoint, changing the IPv6 destination 174 address with the next sid B:4. N2 detects the failure of outbound 175 interface to B:4 in the current route, it could use the normal Ti- 176 LFA repait path to forward the packet, because it is not directly 177 connected to the node N4. N2 encapsulates the packet with the 178 segment list < B:5:6> as a repair path. 180 For node N1, route to the failed endpoint N3 could not be found in 181 the FIB after IGP converges: 183 o Node N1, as a Repair Node, forwards the packets through a bypass 184 of the failed endpoint to the next or endpoint node (e.g., N4) 185 directly. There is no need to check whether the failed endpoint 186 node is directly connected to N1. N1 changes the IPv6 destination 187 address with the next sid B:4. Since IGP has completed 188 convergence, it forwards packets directly based on the IGP SPF 189 path 191 4. SRv6 Midpoint Protection Behavior 193 4.1. Transit Node as Repair Node 195 When the Repair Node is a transit node, it provides fast protection 196 against the endpoint node failure as follows after looking up the 197 FIB. 199 IF the primary outbound interface used to forward the packet failed 200 IF NH = SRH && SL != 0, and 201 the failed endpoint is directly connected to the Repair Node THEN 202 SL decreases*; update the IPv6 DA with SRH[SL]; 203 FIB lookup on the updated DA; 204 forward the packet according to the matched entry; 205 ELSE 206 forward the packet according to the backup nexthop; 207 ELSE // there is no FIB entry for forwarding the packet 208 IF NH = SRH && SL != 0 THEN 209 SL decreases*; update the IPv6 DA with SRH[SL]; 210 FIB lookup on the updated DA; 211 forward the packet according to the matched entry; 212 ELSE 213 drop the packet; 215 *: SL could decrease any dedicated value from [1-N], where N is the current value of SL. 216 The case is similar in the following examples. 218 4.2. Endpoint Node as Repair Node 220 When a node N receives a packet, if the destination address (DA) of 221 the packet is a local END SID, then node N is an endpoint node. When 222 the Repair Node is an endpoint node, it provides fast protections for 223 the failure through executing the following procedure after looking 224 up the FIB for the updated DA. 226 IF the primary outbound interface used to forward the packet failed 227 IF NH = SRH && SL != 0, and 228 the failed endpoint is directly connected to the Repair Node THEN 229 SL decreases; update the IPv6 DA with SRH[SL]; 230 FIB lookup on the updated DA; 231 forward the packet according to the matched entry; 232 ELSE 233 forward the packet according to the backup nexthop; 234 ELSE // there is no FIB entry for forwarding the packet 235 IF NH = SRH && SL != 0 THEN 236 SL decreases; update the IPv6 DA with SRH[SL]; 237 FIB lookup on the updated DA; 238 forward the packet according to the matched entry; 239 ELSE 240 drop the packet; 241 ELSE 242 forward accordingly to the matched entry; 244 4.3. Endpoint x Node as Repair Node 246 An endpoint node with cross-connect (End.X for short) is an endpoint 247 node with an array of layer 3 adjacencies. When a node N receives a 248 packet, if the destination address (DA) of the packet is a local 249 END.X SID, then node N as Repair Node provides fast protections for 250 the failure through executing the following procedure after updating 251 DA. 253 IF the layer-3 adjacency interface is down THEN 254 FIB lookup on the updated DA; 255 IF the primary interface used to forward the packet failed THEN 256 IF NH = SRH && SL != 0, and 257 the failed endpoint is directly connected to the Repair Node THEN 258 SL decreases; update the IPv6 DA with SRH[SL]; 259 FIB lookup on the updated DA; 260 forward the packet according to the matched entry; 261 ELSE 262 forward the packet according to the backup nexthop; 263 ELSE // there is no FIB entry for forwarding the packet 264 IF NH = SRH && SL != 0 THEN 265 SL decreases; update the IPv6 DA with SRH[SL]; 266 FIB lookup on the updated DA; 267 forward the packet according to the matched entry; 268 ELSE 269 drop the packet; 270 ELSE 271 forward accordingly to the matched entry; 273 5. Security Considerations 275 This section reviews security considerations related to SRv6 Midpoint 276 protection processing discussed in this document.To ensure that the 277 Repair node does not modify the SRH header Encapsulated by nodes 278 outside the SRv6 Domain.Only the segment within the SRH is same 279 domain as the repair node. So it is necessary to check the skipped 280 segment have same block as repair node. 282 6. IANA Considerations 284 This document makes no request of IANA. 286 Note to RFC Editor: this section may be removed on publication as an 287 RFC. 289 7. Acknowledgements 291 8. References 293 8.1. Normative References 295 [I-D.hu-spring-segment-routing-proxy-forwarding] 296 Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE 297 Path Midpoint Protection", draft-hu-spring-segment- 298 routing-proxy-forwarding-08 (work in progress), May 2020. 300 [I-D.ietf-isis-segment-routing-extensions] 301 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 302 Gredler, H., and B. Decraene, "IS-IS Extensions for 303 Segment Routing", draft-ietf-isis-segment-routing- 304 extensions-25 (work in progress), May 2019. 306 [I-D.ietf-lsr-isis-srv6-extensions] 307 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 308 Z. Hu, "IS-IS Extension to Support Segment Routing over 309 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 310 (work in progress), April 2020. 312 [I-D.ietf-lsr-ospfv3-srv6-extensions] 313 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 314 "OSPFv3 Extensions for SRv6", draft-ietf-lsr- 315 ospfv3-srv6-extensions-00 (work in progress), February 316 2020. 318 [I-D.ietf-ospf-segment-routing-extensions] 319 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 320 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 321 Extensions for Segment Routing", draft-ietf-ospf-segment- 322 routing-extensions-27 (work in progress), December 2018. 324 [I-D.ietf-spring-srv6-network-programming] 325 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 326 Matsushima, S., and Z. Li, "SRv6 Network Programming", 327 draft-ietf-spring-srv6-network-programming-15 (work in 328 progress), March 2020. 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 8.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-05 (work in progress), 346 July 2019. 348 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 349 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 350 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 351 "Topology Independent Fast Reroute using Segment Routing", 352 draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in 353 progress), March 2020. 355 [I-D.ietf-spring-segment-routing-policy] 356 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 357 P. Mattes, "Segment Routing Policy Architecture", draft- 358 ietf-spring-segment-routing-policy-07 (work in progress), 359 May 2020. 361 [I-D.sivabalan-pce-binding-label-sid] 362 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 363 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 364 in PCE-based Networks.", draft-sivabalan-pce-binding- 365 label-sid-07 (work in progress), July 2019. 367 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 368 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 369 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 370 2009, . 372 Appendix A. An Appendix 374 Authors' Addresses 376 Huanan 377 China Telecom 379 Email: chenhuan6@chinatelecom.cn 381 Zhibo 382 Huawei Technologies 384 Email: huzhibo@huawei.com 386 Huaimo 387 Futurewei 389 Email: Huaimo.chen@futurewei.co 391 Xuesong 392 Huawei Technologies 394 Email: gengxuesong@huawei.com