idnits 2.17.1 draft-hegde-rtgwg-egress-protection-sr-networks-00.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 ([I-D.ietf-mpls-egress-protection-framework]), 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 (March 8, 2020) is 1509 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 367, but no explicit reference was found in the text == Unused Reference: 'RFC7911' is defined on line 372, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-bonica-spring-sr-mapped-six-00 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-10 == 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 -- 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: September 9, 2020 March 8, 2020 7 Egress Protection for Segment Routing (SR) networks 8 draft-hegde-rtgwg-egress-protection-sr-networks-00 10 Abstract 12 This document specifies a Fast Reroute(FRR) mechanism for protecting 13 IP/MPLS services that use Segment Routing (SR) paths for transport 14 against egress node and egress link failures. The mechanism is based 15 on egress protection framework described in 16 [I-D.ietf-mpls-egress-protection-framework]. The egress protection 17 mechanism can be further simplified in Segment Routing networks with 18 anycast SIDs and anycast Locators. This document addresses all kinds 19 of networks that use Segment Routing transport such as SR-MPLS over 20 IPv4, SR-MPLS over IPv6, SRv6 and SRm6. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 9, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 [RFC8401] 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.hegde-spring-node-protection-for-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 requires 96 building local context tables and also specialized context table 97 lookups as described in [I-D.ietf-mpls-egress-protection-framework]. 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 105 [I-D.ietf-mpls-egress-protection-framework], this document specifies 106 procedures which can be used to greatly simplify the operation of 107 egress protection in a segment routing network. Egress protection 108 for Multicast services is for FFS. 110 2. Egress Node Protection 112 services 1, ..., N 113 =====================================> tunnel 115 I ------ R1 ------- PLR --------------- E ---- 116 ingress penultimate-hop egress \ 117 | . (primary \ 118 | . service \ 119 | . instances) \ 120 | . \ 121 | . \ service 122 | . destinations 123 | . / (CEs, sites) 124 | . / 125 | . TI-LFA backup / 126 | . path / 127 | . / 128 | ............... / 129 R2 --------------- P ---- 130 protector 131 (protection 132 service 133 instances) 135 Figure 1: Reference topology 137 The reference topology from 138 [I-D.ietf-mpls-egress-protection-framework] has been reproduced in 139 Figure 1 for ease of reading. The current document also uses the 140 terminology defined in [I-D.ietf-mpls-egress-protection-framework].In 141 the topology in Figure 1, service destinations are attached to two 142 egress nodes. The two egress nodes could be used in primary/ 143 protection mode or they could also be used in ECMP mode. When one of 144 egress nodes fails, traffic should be switched to the other egress 145 node and the convergence should be on the order of 50ms. The 146 transport network is based on Segment Routing technology and could be 147 using any of the SR-MPLS over IPv4, SR-MPLS over IPV6 , SRm6 or SRv6. 148 The sections below describe the solution for each of the transport 149 mechanisms. 151 2.1. SR-MPLS Networks 153 [RFC8401] describes the concept of anycast SIDs. Applying anycast 154 SIDs to egress protection, the same IP address is configured as a 155 loopback address on multiple egress nodes, and the same SID is 156 advertised for this IP address. In the reference topology in 157 Figure 1, E and P are associated with anycast loopback and 158 corresponding anycast SID. The egress protected tunnel is considered 159 logically destined to this anycast address and the egress protected 160 tunnel always carries this anycast SID corresponding to the 161 destination anycast address as the last SID. The egress protected 162 service is hosted on both E and P. The egress protected tunnel can 163 be used in primary/protector mode in which case, the anycast loopback 164 MUST be advertised with better metric and the protector MUST 165 advertise with an inferior metric. An egress protected service MUST 166 advertise same service label from both E and P. The service label is 167 assigned from the SRLB as defined in [RFC8401]. The egress node 168 pairs that serve egress protected service MUST be able to allocate 169 the same service label and hence MUST have overlapping local label 170 space (SRLB) reserved for static assignment. 172 The TI-LFA procedures described in 173 [I-D.ietf-rtgwg-segment-routing-ti-lfa] apply to the anycast 174 prefixes. Based on the transport IGP topology, TI-LFA backup path is 175 computed and programmed into the forwarding plane on the PLR nodes. 176 The PLR SHOULD be configured to provide node protection for the 177 failure. On the egress node E's failure, traffic on the PLR SHOULD 178 be switched to the other egress node which is P. As the service 179 label carried in the packet is understood by P as well, P will 180 correctly send the traffic to the service destination. 182 The above procedure is applicable to SR-MPLS over IPv4 as well as SR- 183 MPLS over IPv6 networks. In case of IPv4 networks, the anycast SIDs 184 are assigned to IPv4 loopbacks and in case of IPv6 networks, the 185 anycast SIDs are assigned to IPv6 loopback addresses. The egress 186 protected IP/MPLS services advertise the service prefix with the 187 anycast address information in the message. In case of BGP based 188 services such as L3vpn [RFC2547], the nexthop attribute carries the 189 anycast address which is the logical tunnel destination address. On 190 the ingress, when the service prefix is received, the service is 191 mapped to the corresponding egress protected tunnel. 193 If some services are multi-homed to a different node for example, in 194 the reference topology, if a service is multi-homed to E and another 195 node P', then there SHOULD be another anycast address representing 196 {E,P'}. The number of anycast loopbacks on a given node will be equal 197 to the number of such {primary, protector} pairs a node belongs 198 to.The egress protected service prefixes MUST carry the anycast 199 address corresponding to the {primary, protector} pair in their next 200 hop attribute. 202 When there is a single homed CE connected to the egress node, it 203 SHOULD use a node loopback in the next hop attribute and should not 204 use anycast loopback address. 206 2.2. SRm6 Networks 208 [I-D.bonica-spring-sr-mapped-six] defines segment routing applied to 209 IPv6 networks which is optimized for high data rate forwarding. SRm6 210 control plane is very similar to SR-MPLS but it uses the IPv6 data 211 plane. The egress node protection procedures described for SR-MPLS 212 are applicable to SRm6 as well. Anycast loopback addresses are 213 advertised and corresponding anycast SIDs are associated with the 214 anycast addresses. The anycast SIDs in case of SRm6 are globally 215 unique indices of size 16 or 32 bits. 217 The VPN services that require a label to identify the service are 218 advertised as described in [I-D.ssangli-idr-bgp-vpn-srv6-plus]. The 219 same PPSI value MUST be allocated to the service prefix on both the 220 egress nodes on which the service is multi-homed.The TI-LFA 221 procedures explained in Section 2.1 are applicable to SRm6 as well. 222 After the CRH header is removed at the egress node, lookup is done 223 based on PPSI which points to the correct service instance. Since 224 the same PPSI is assigned on both nodes, the context table as 225 described in [I-D.ietf-mpls-egress-protection-framework] is not 226 required to be built. 228 2.3. SRv6 Networks 230 [I-D.ietf-spring-srv6-network-programming] describes various types of 231 SIDs used in SRv6 networks.The routing in the transport is based on 232 the locators. Locators are most significant bits of the SID. In 233 order to achieve the egress protection functionality, anycast 234 locators MUST be assigned on the egress nodes {E,P} where the service 235 are multi-homed. The service SIDs MUST be derived from the anycast 236 SID. The multi-homed service MUST be assigned with same service SID 237 on both the egress nodes. It is recommended to provide mechanisms to 238 statically configure the service SIDs which can easily serve the 239 purpose of synchronized SID allocation on both nodes. As explained 240 in the Section 2.1, if an egress node has services which are multi- 241 homed to different nodes, then each such pair of node will need a 242 separate locator assigned. 244 When there is a single homed CE connected to an egress, it MUST use a 245 node specific locator to advertise service SID. It should not use 246 service SIDs based on anycast locator 248 The TI-LFA procedure is applicable to anycast locators and each 249 transport node in the transport IGP, installs a primary and backup 250 path to the anycast locator. It is assumed that PLR has a backup 251 path to alternate egress node which does not go via the primary 252 egress node. 254 3. Egress Link Protection 256 Anycast loopback:10.10.10.10 257 Anycast SID: 10 SRGB (1000-2000) 258 Node loopback: 2.2.2.2 260 ---------- R1 ----------- PE2 - 261 / (PLR) (PLR) \ 262 ( ) / | | ( ) 263 ( ) / | | ( ) 264 ( site 1 )-- PE1 | | R3 ( site 2 ) 265 ( ) \ | | ( ) 266 ( ) \ | | ( ) 267 \ | | / 268 ---------- R2 ----------- PE3 - 269 (protector) 270 Anycast loopback:10.10.10.10 271 Anycast SID: 10 SRGB (1000-2000) 272 Node loopback: 3.3.3.3 274 Figure 2: Egress Link Protection 276 The link from egress node towards the CE (service destination) fails, 277 that failure needs to be protected. Egress link protection can be 278 achieved using similar means as egress node protection. In egress 279 link failure case, egress node is the PLR and it has learned the 280 service prefix from the other egress node. PLR egress node pre- 281 establishes backup path to the other egress node and programs the 282 forwarding plane with backup path. As the BGP based service prefixes 283 advertise the anycast loopback address in the next hop attribute, the 284 egress nodes will ignore the advertisement from other egress node. 285 For Example, in the above Figure 2, when PE3 advertises a service 286 prefix for site 2 with a next hop attribute of anycast loopback 287 address, PE2 does not consider this advertisement and program a 288 backup path towards PE3. To solve this problem, The egress nodes 289 could advertise service prefixes with NEXT_HOP [RFC4271]attribute 290 carrying anycast loopback as well as node specific loopback with a 291 different RD [RFC2547]. 293 4. Security Considerations 295 This document does not introduce any new security risks. For 296 deploying this solution, security considerations described in 297 [RFC8401], [I-D.bonica-spring-sr-mapped-six], 298 [I-D.ietf-spring-srv6-network-programming] and 299 [I-D.ietf-mpls-egress-protection-framework] are applicable. 301 5. IANA Considerations 303 This document does not introduce any new IANA requests. 305 6. Acknowledgments 307 Thanks to Krzysztof Szarkowicz,Louis Chan and Chris Bowers for 308 careful review and inputs. 310 7. References 312 7.1. Normative References 314 [I-D.bonica-spring-sr-mapped-six] 315 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 316 D., Jalil, L., Halpern, J., Linkova, J., and G. Chen, 317 "Segment Routing Mapped To IPv6 (SRm6)", draft-bonica- 318 spring-sr-mapped-six-00 (work in progress), November 2019. 320 [I-D.ietf-mpls-egress-protection-framework] 321 Shen, Y., Jeganathan, J., Decraene, B., Gredler, H., 322 Michel, C., and H. Chen, "MPLS Egress Protection 323 Framework", draft-ietf-mpls-egress-protection-framework-07 324 (work in progress), July 2019. 326 [I-D.ietf-spring-srv6-network-programming] 327 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 328 Matsushima, S., and Z. Li, "SRv6 Network Programming", 329 draft-ietf-spring-srv6-network-programming-10 (work in 330 progress), February 2020. 332 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 333 Zhang, "Bit Index Explicit Replication (BIER) Support via 334 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 335 . 337 7.2. Informative References 339 [I-D.hegde-spring-node-protection-for-sr-te-paths] 340 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 341 "Node Protection for SR-TE Paths", draft-hegde-spring- 342 node-protection-for-sr-te-paths-05 (work in progress), 343 July 2019. 345 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 346 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 347 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 348 "Topology Independent Fast Reroute using Segment Routing", 349 draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in 350 progress), March 2020. 352 [I-D.ssangli-idr-bgp-vpn-srv6-plus] 353 Ramachandra, S. and R. Bonica, "BGP based Virtual Private 354 Network (VPN) Services over SRv6+ enabled IPv6 networks", 355 draft-ssangli-idr-bgp-vpn-srv6-plus-02 (work in progress), 356 July 2019. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, 360 DOI 10.17487/RFC2119, March 1997, 361 . 363 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 364 DOI 10.17487/RFC2547, March 1999, 365 . 367 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 368 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 369 DOI 10.17487/RFC4271, January 2006, 370 . 372 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 373 "Advertisement of Multiple Paths in BGP", RFC 7911, 374 DOI 10.17487/RFC7911, July 2016, 375 . 377 Authors' Addresses 379 Shraddha Hegde 380 Juniper Networks Inc. 381 Exora Business Park 382 Bangalore, KA 560103 383 India 385 Email: shraddha@juniper.net 387 Wen Lin 388 Juniper Networks Inc. 390 Email: wlin@juniper.net