idnits 2.17.1 draft-hegde-rtgwg-egress-protection-sr-networks-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 5 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([RFC8679]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 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 (2 March 2022) is 785 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) == Unused Reference: 'RFC4271' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC7911' is defined on line 404, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-bashandy-rtgwg-segment-routing-uloop-12 == Outdated reference: A later version (-20) exists of draft-ietf-rtgwg-bgp-pic-17 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-08 == Outdated reference: A later version (-06) exists of draft-ietf-spring-segment-protection-sr-te-paths-02 -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing area S. Hegde 3 Internet-Draft W. Lin 4 Intended status: Standards Track Juniper Networks Inc. 5 Expires: 3 September 2022 P. Shaofu 6 ZTE Corporation 7 2 March 2022 9 Egress Protection for Segment Routing (SR) networks 10 draft-hegde-rtgwg-egress-protection-sr-networks-02 12 Abstract 14 This document specifies a Fast Reroute(FRR) mechanism for protecting 15 IP/MPLS services that use Segment Routing (SR) paths for transport 16 against egress node and egress link failures. The mechanism is based 17 on egress protection framework described in [RFC8679]. The egress 18 protection mechanism can be further simplified in Segment Routing 19 networks with anycast SIDs and anycast Locators. This document 20 addresses all kinds of networks that use Segment Routing transport 21 such as SR-MPLS over IPv4, SR-MPLS over IPv6, SRv6 and SRm6. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 3 September 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Egress Node Protection . . . . . . . . . . . . . . . . . . . 3 64 2.1. SR-MPLS Networks . . . . . . . . . . . . . . . . . . . . 4 65 2.2. SRm6 Networks . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. SRv6 Networks . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Egress Link Protection . . . . . . . . . . . . . . . . . . . 6 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 7.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 Segment Routing Architecture as defined in [RFC8402] provides a 79 simple and scalable MPLS control plane that removes state from 80 transit nodes in the network. SRm6 as defined in 81 [I-D.bonica-spring-sr-mapped-six] and SRv6 as defined in 82 [I-D.ietf-spring-srv6-network-programming] provide Segment Routing 83 transport in pure IPv6 networks where MPLS data plane is not used. 84 End-to-End resiliency is very important to satisfy Service Level 85 Agreements (SLA) such as 50ms convergence. The transport resiliency 86 and fast rerouting are described 87 in[I-D.ietf-rtgwg-segment-routing-ti-lfa] and 88 [I-D.ietf-spring-segment-protection-sr-te-paths]. Egress node and 89 egress link failures are not covered by these protection mechanisms. 90 Egress node and link failures need to address moving the services to 91 other nodes where the customer services are multi-homed. In 92 traditional MPLS networks service labels (ex: L3VPN) are assigned 93 dynamically. The protector nodes need to learn the service labels 94 advertised by primary nodes and build a local context table 95 corresponding to each primary node that a node protects. This 96 requires building local context tables and also specialized context 97 table lookups as described in [RFC8679]. 99 Egress protection can be simplified by statically assigning service 100 labels on egress nodes. When a service is multi-homed to two or more 101 egress nodes, the same service label can be assigned to the service 102 on each egress node. This mechanism, coupled with using anycast SIDs 103 for loopbacks, greatly simplifies the egress protection. Following 104 the principles described in [RFC8679], this document specifies 105 procedures which can be used to greatly simplify the operation of 106 egress protection in a segment routing network. Egress protection 107 for Multicast services is for FFS. 109 2. Egress Node Protection 111 services 1, ..., N 112 =====================================> tunnel 114 I ------ R1 ------- PLR --------------- E ---- 115 ingress penultimate-hop egress \ 116 | . (primary \ 117 | . service \ 118 | . instances) \ 119 | . \ 120 | . \ service 121 | . destinations 122 | . / (CEs, sites) 123 | . / 124 | . TI-LFA backup / 125 | . path / 126 | . / 127 | ............... / 128 R2 --------------- P ---- 129 protector 130 (protection 131 service 132 instances) 134 Figure 1: Reference topology 136 The reference topology from [RFC8679] has been reproduced in Figure 1 137 for ease of reading. The current document also uses the terminology 138 defined in [RFC8679]. In the topology in Figure 1, service 139 destinations are attached to two egress nodes. The two egress nodes 140 could be used in primary/protection mode or they could also be used 141 in ECMP mode. When one of egress nodes fails, traffic should be 142 switched to the other egress node and the convergence should be on 143 the order of 50ms. The transport network is based on Segment Routing 144 technology and could be using any of the SR-MPLS over IPv4, SR-MPLS 145 over IPV6 , SRm6 or SRv6. The sections below describe the solution 146 for each of the transport mechanisms. 148 2.1. SR-MPLS Networks 150 [RFC8402] describes the concept of anycast SIDs. Applying anycast 151 SIDs to egress protection, the same IP address is configured as a 152 loopback address on multiple egress nodes, and the same SID is 153 advertised for this IP address. In the reference topology in 154 Figure 1, E and P are associated with anycast loopback and 155 corresponding anycast SID. The egress protected tunnel is considered 156 logically destined to this anycast address and the egress protected 157 tunnel always carries this anycast SID corresponding to the 158 destination anycast address as the last SID. The egress protected 159 service is hosted on both E and P. The egress protected tunnel can 160 be used in primary/protector mode in which case, the anycast loopback 161 MUST be advertised with better metric and the protector MUST 162 advertise with an inferior metric. An egress protected service MUST 163 advertise same service label from both E and P. The service label is 164 assigned from the SRLB as defined in [RFC8402]. The egress node 165 pairs that serve egress protected service MUST be able to allocate 166 the same service label and hence MUST have overlapping local label 167 space (SRLB) reserved for static assignment. 169 The TI-LFA procedures described in 170 [I-D.ietf-rtgwg-segment-routing-ti-lfa] apply to the anycast 171 prefixes. Based on the transport IGP topology, TI-LFA backup path is 172 computed and programmed into the forwarding plane on the PLR nodes. 173 The PLR SHOULD be configured to provide node protection for the 174 failure. On the egress node E's failure, traffic on the PLR SHOULD 175 be switched to the other egress node which is P. As the service 176 label carried in the packet is understood by P as well, P will 177 correctly send the traffic to the service destination. 179 Note that the micro-loop avoidance procedures as described in 180 [I-D.bashandy-rtgwg-segment-routing-uloop] are applicable to anycast 181 prefixes as well. When the anycast prefix is impacted by the failure 182 event, a micro-loop avoiding path for the anycast prefix/anycast-SID 183 will be programed during convergence. This mechanims does not affect 184 the egress protection procedures described in this document. 186 The above procedure is applicable to SR-MPLS over IPv4 as well as SR- 187 MPLS over IPv6 networks. In case of IPv4 networks, the anycast SIDs 188 are assigned to IPv4 loopbacks and in case of IPv6 networks, the 189 anycast SIDs are assigned to IPv6 loopback addresses. The egress 190 protected IP/MPLS services advertise the service prefix with the 191 anycast address information in the message. In case of BGP based 192 services such as L3vpn [RFC2547], the nexthop attribute carries the 193 anycast address which is the logical tunnel destination address. On 194 the ingress, when the service prefix is received, the service is 195 mapped to the corresponding egress protected tunnel. 197 If some services are multi-homed to a different node for example, in 198 the reference topology, if a service is multi-homed to E and another 199 node P', then there SHOULD be another anycast address representing 200 {E,P'}. The number of anycast loopbacks on a given node will be equal 201 to the number of such {primary, protector} pairs a node belongs to. 202 The egress protected service prefixes MUST carry the anycast address 203 corresponding to the {primary, protector} pair in their next hop 204 attribute. 206 When there is a single homed CE connected to the egress node, it 207 SHOULD use a node loopback in the next hop attribute and should not 208 use anycast loopback address. 210 2.2. SRm6 Networks 212 [I-D.bonica-spring-sr-mapped-six] defines segment routing applied to 213 IPv6 networks which is optimized for high data rate forwarding. SRm6 214 control plane is very similar to SR-MPLS but it uses the IPv6 data 215 plane. The egress node protection procedures described for SR-MPLS 216 are applicable to SRm6 as well. Anycast loopback addresses are 217 advertised and corresponding anycast SIDs are associated with the 218 anycast addresses. The anycast SIDs in case of SRm6 are globally 219 unique indices of size 16 or 32 bits. 221 The VPN services that require a label to identify the service are 222 advertised as described in [I-D.ssangli-idr-bgp-vpn-srv6-plus]. The 223 same PPSI value MUST be allocated to the service prefix on both the 224 egress nodes on which the service is multi-homed. The TI-LFA 225 procedures explained in Section 2.1 are applicable to SRm6 as well. 226 After the CRH header is removed at the egress node, lookup is done 227 based on PPSI which points to the correct service instance. Since 228 the same PPSI is assigned on both nodes, the context table as 229 described in [RFC8679] is not required to be built. 231 2.3. SRv6 Networks 233 [I-D.ietf-spring-srv6-network-programming] describes various types of 234 SIDs used in SRv6 networks. The routing in the transport is based on 235 the locators. Locators are most significant bits of the SID. In 236 order to achieve the egress protection functionality, anycast 237 locators MUST be assigned on the egress nodes {E,P} where the service 238 are multi-homed. The service SIDs MUST be derived from the anycast 239 SID. The multi-homed service MUST be assigned with same service SID 240 on both the egress nodes. It is recommended to provide mechanisms to 241 statically configure the service SIDs which can easily serve the 242 purpose of synchronized SID allocation on both nodes. As explained 243 in the Section 2.1, if an egress node has services which are multi- 244 homed to different nodes, then each such pair of node will need a 245 separate locator assigned. 247 When there is a single homed CE connected to an egress, it MUST use a 248 node specific locator to advertise service SID. It should not use 249 service SIDs based on anycast locator 251 The TI-LFA procedure is applicable to anycast locators and each 252 transport node in the transport IGP, installs a primary and backup 253 path to the anycast locator. However, only the directly connected 254 upstream PLR of the primary egress node will respond to the failure 255 of the primary egress node and switch to the TI-LFA backup path. It 256 is assumed that PLR has a backup path to alternate egress node which 257 does not go via the primary egress node. 259 3. Egress Link Protection 261 Anycast loopback:10.10.10.10 262 Anycast SID: 10 SRGB (1000-2000) 263 Node loopback: 2.2.2.2 265 ---------- R1 ----------- PE2 - 266 / (PLR) (PLR) \ 267 ( ) / | | ( ) 268 ( ) / | | ( ) 269 ( site 1 )-- PE1 | | R3 ( site 2 ) 270 ( ) \ | | ( ) 271 ( ) \ | | ( ) 272 \ | | / 273 ---------- R2 ----------- PE3 - 274 (protector) 275 Anycast loopback:10.10.10.10 276 Anycast SID: 10 SRGB (1000-2000) 277 Node loopback: 3.3.3.3 279 Figure 2: Egress Link Protection 281 The link from egress node towards the CE (service destination) fails, 282 that failure needs to be protected. Egress link protection can be 283 achieved using similar means as egress node protection. section 6.2.2 284 of [I-D.ietf-rtgwg-bgp-pic] describes the procedures for protecting 285 egress link failures in detail. When anycast ip address is used as 286 BGP protocol nexthop, some additional considerations are required 287 along with the procedures described in [I-D.ietf-rtgwg-bgp-pic]. In 288 egress link failure case, egress node is the PLR and it has learned 289 the service prefix from the other egress node. PLR egress node pre- 290 establishes backup path to the other egress node and programs the 291 forwarding plane with backup path. As the BGP based service prefixes 292 advertise the anycast loopback address in the next hop attribute, the 293 egress nodes will ignore the advertisement from other egress node. 294 For Example, in the above Figure 2, when PE3 advertises a service 295 prefix for site 2 with a next hop attribute of anycast loopback 296 address, PE2 does not consider this advertisement and program a 297 backup path towards PE3. To solve this problem, The egress nodes 298 could advertise service prefixes with NEXT_HOP [RFC4271]attribute 299 carrying anycast loopback as well as node specific loopback with a 300 different RD [RFC2547]. 302 4. Security Considerations 304 This document does not introduce any new security risks. For 305 deploying this solution, security considerations described in 306 [RFC8402], [I-D.bonica-spring-sr-mapped-six], 307 [I-D.ietf-spring-srv6-network-programming] and [RFC8679] are 308 applicable. 310 5. IANA Considerations 312 This document does not introduce any new IANA requests. 314 6. Acknowledgments 316 Thanks to Krzysztof Szarkowicz,Louis Chan and Chris Bowers for 317 careful review and inputs. 319 7. References 321 7.1. Normative References 323 [I-D.bonica-spring-sr-mapped-six] 324 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 325 D., Jalil, L., Halpern, J., Linkova, J., and G. Chen, 326 "Segment Routing Mapped To IPv6 (SRm6)", Work in Progress, 327 Internet-Draft, draft-bonica-spring-sr-mapped-six-04, 27 328 September 2021, . 331 [I-D.ietf-spring-srv6-network-programming] 332 Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D., 333 Matsushima, S., and Z. Li, "Segment Routing over IPv6 334 (SRv6) Network Programming", Work in Progress, Internet- 335 Draft, draft-ietf-spring-srv6-network-programming-28, 29 336 December 2020, . 339 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 340 Decraene, B., Litkowski, S., and R. Shakir, "Segment 341 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 342 July 2018, . 344 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 345 Michel, C., and H. Chen, "MPLS Egress Protection 346 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 347 . 349 7.2. Informative References 351 [I-D.bashandy-rtgwg-segment-routing-uloop] 352 Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., 353 Francois, P., and P. Psenak, "Loop avoidance using Segment 354 Routing", Work in Progress, Internet-Draft, draft- 355 bashandy-rtgwg-segment-routing-uloop-12, 22 December 2021, 356 . 359 [I-D.ietf-rtgwg-bgp-pic] 360 Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix 361 Independent Convergence", Work in Progress, Internet- 362 Draft, draft-ietf-rtgwg-bgp-pic-17, 12 October 2021, 363 . 366 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 367 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 368 Decraene, B., and D. Voyer, "Topology Independent Fast 369 Reroute using Segment Routing", Work in Progress, 370 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 371 08, 21 January 2022, . 374 [I-D.ietf-spring-segment-protection-sr-te-paths] 375 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 376 "Segment Protection for SR-TE Paths", Work in Progress, 377 Internet-Draft, draft-ietf-spring-segment-protection-sr- 378 te-paths-02, 21 January 2022, 379 . 382 [I-D.ssangli-idr-bgp-vpn-srv6-plus] 383 Sangli, S. and R. Bonica, "BGP based Virtual Private 384 Network (VPN) Services over SRv6+ enabled IPv6 networks", 385 Work in Progress, Internet-Draft, draft-ssangli-idr-bgp- 386 vpn-srv6-plus-02, 22 July 2019, 387 . 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, 392 DOI 10.17487/RFC2119, March 1997, 393 . 395 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 396 DOI 10.17487/RFC2547, March 1999, 397 . 399 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 400 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 401 DOI 10.17487/RFC4271, January 2006, 402 . 404 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 405 "Advertisement of Multiple Paths in BGP", RFC 7911, 406 DOI 10.17487/RFC7911, July 2016, 407 . 409 Authors' Addresses 411 Shraddha Hegde 412 Juniper Networks Inc. 413 Exora Business Park 414 Bangalore 560103 415 KA 416 India 417 Email: shraddha@juniper.net 419 Wen Lin 420 Juniper Networks Inc. 422 Email: wlin@juniper.net 424 Peng Shaofu 425 ZTE Corporation 426 Email: peng.shaofu@zte.com.cn