idnits 2.17.1 draft-boutros-bess-l3vpn-services-over-sr-01.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 (11 October 2021) is 926 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: 'RFC8402' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'I-D.voyer-pim-sr-p2mp-policy' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 390, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Workgroup S. Boutros, Ed. 3 Internet-Draft S. Sivabalan, Ed. 4 Intended status: Standards Track Ciena Corporation 5 Expires: 14 April 2022 J. Uttaro 6 AT&T 7 D. Voyer 8 Bell Canada 9 B. Wen 10 Comcast 11 L. Jalil 12 Verizon 13 11 October 2021 15 A Simplified Scalable L3VPN Service Model with Segment Routing Underlay 16 draft-boutros-bess-l3vpn-services-over-sr-01 18 Abstract 20 This document proposes a new approach for realizing classical L3VPN 21 (vpnv4/vpnv6/6PE/6VPE) over Segment Routing (SR) networks. It 22 significantly improves scalability and convergence of the L3VPN 23 control plane. Furthermore, it naturally brings the benefits of All- 24 Active multi-homing support to the classical L3VPN. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 14 April 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Control Plane Functionality . . . . . . . . . . . . . . . . . 6 63 4.1. Service discovery . . . . . . . . . . . . . . . . . . . . 6 64 5. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . . 7 65 6. Service discovery . . . . . . . . . . . . . . . . . . . . . . 7 66 7. All-Active service Redundancy . . . . . . . . . . . . . . . . 8 67 8. Multi-pathing . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. Mass service withdrawal . . . . . . . . . . . . . . . . . . . 8 69 10. Benefits of L3VPN over SR . . . . . . . . . . . . . . . . . . 9 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 73 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 14.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 14.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Layer 3 VPN (L3VPN) enables a service provider to use an Internet 81 Protocol (IP) backbone to provide IP VPNs for customers. This 82 approach uses a peer model, in which the Customer Edge (CE) nodes 83 send their routes to the Service Provider Edge (PE) nodes. BGP is 84 used to exchange the routes of a particular VPN among the PE nodes 85 that are attached to that VPN. This is done in a way that ensures 86 that routes from different VPNs remain distinct and separate, even if 87 two VPNs have an overlapping address space. The PE nodes distribute 88 to the CE nodes in a particular VPN, the routes from other the CE 89 nodes in that VPN. The CE nodes do not peer with each other. Each 90 L3VPN route (v4/v6) advertisement is prepended with an 8-byte Route 91 Distinguisher (RD) to allow the IP address space to be reused by 92 multiple VPNs. Each L3VPN route is associated with a set of extended 93 communities, i.e., Route Targets (RTs). Each L3VPN route can be 94 associated with other attributes such as local preferences, MED 95 (Multi_EXIT_DISC attribute), color, etc. Each L3VPN route is 96 associated with a tunnel encapsulation, i.e., MPLS label. 98 Current mechanisms require control plane scale to distribute a large 99 number of VPN routes in the service provider network. In this 100 document we propose a new approach that intends to simplify and 101 improve the scalability of existing control plane to support L3VPN 102 options A, B, and C using a global service SID per VPN across AS 103 domains. Non mesh, hub/spoke and extranet topology can be realized 104 using different SIDs or possibly RTs associated with the L3VPN 105 services attached to different service routes. Non mesh topologies 106 can then be realized by applying different import, export rules. The 107 proposed control plane can be realized through protocols like BGP or 108 using a centralized controller. 110 The proposed approach takes advantage of the inherent properties of 111 SR. It maintains the existing L3VPN semantics to (1) allow 112 overlapping IP addresses to be used across multiple VPNs and (2) 113 associate routes with attributes. Further, it allows operators to 114 represent an L3VPN instance by one or more globally allocated service 115 Segment Identifiers (SID(s)). The VPN route import/export is 116 governed by SID and allows the operator to deploy extranet, hub-and- 117 spoke, and mesh VPN topologies. RT-based import/export can also be 118 used to support non-mesh L3VPN sites. Also, the proposed approach 119 provides All-Active redundancy and multi-pathing using SR anycast 120 SIDs for Multi-Homed (MH) L3VPN sites. It significantly reduces the 121 BGP overhead for L3VPN control planes by at least two orders of 122 magnitude and, in mesh deployments by up to four orders of magnitude. 123 At the same time, it does not compromise the desired benefits of 124 L3VPN and EVPN prefix advertisements (RT-5), such as support of All- 125 Active redundancy on access, multi-pathing in the core, auto- 126 provisioning and auto-discovery. 128 The crux of the proposal is how the routes are advertised. All VPN 129 routes originating from a PE node share the same tunnel encapsulation 130 (ENCAP) to that PE node. Thus, we propose to advertise the tunnel 131 encapsulation as the unique route, and the VPN prefixes as the 132 attributes of the route. A new BGP message (to be specified in a 133 future version of this document) will be used to advertise the route 134 and attributes in the new format. The goal is to pack as many VPN 135 prefixes as possible in a single BGP message. About 10k VPNv4 136 prefixes can be packed in a 64k message. With SRv6 and uSID, the 137 ENCAP will be an IPv6 prefix that contains both the Node SID for the 138 PE node as well as the Service SID representing the VPN. In common 139 cases, this will be a /64 globally unique prefix. 141 A SID identifying a L3VPN instance (we call it "Service SID" in the 142 rest of the document) can be: 144 * an MPLS label for SR-MPLS. 146 * a uSID (micro SID) for SRv6 representing network function 147 associated with a VPLS instance. The new function will be 148 specified in a future version of this document. 150 In the data packets, the service SID uniquely identify the L3VPN 151 service in an SR domain. 153 Thanks to SR anycast SID capability, the proposed approach inherently 154 provides All-Active multi-homing support. 156 A node can advertise service SID(s) of the L3VPN instance(s) that it 157 is associated with via BGP for auto-discovery purpose. In the case 158 of SR-MPLS, a service SID can be carried as a range of absolute 159 values or an index into an Segment Routing Global Block (SRGB), and 160 in the case of SRv6, a service SID can be carried as uSID in BGP 161 updates. The objective is to pack information about all L3VPN 162 service instances supported (at the time of sending update) on a 163 transmitting node in single BGP update so as to reduce the amount of 164 of overall BGP update messages in a network. 166 The proposed solution can also be applicable to EVPN control plane 167 without compromising its benefits such as multi-active redundancy on 168 access, multipathing in the core, auto-provisioning and auto- 169 discovery, etc. With this approach, the need for advertisement of 170 EVPN route types 1 and 5. 172 In the following sections, we will describe the functionalities of 173 the proposed approach in detail. 175 2. Terminology 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 3. Abbreviations 183 L3VPN: Layer 3 Virtual Private Network. 185 CE: Customer Edge node e.g., host or node or switch. 187 EVPN: Ethernet VPN. 189 MAC: Media Access Control. 191 VRF: A Virtual Routing and Forwarding table for Customer Routes on a 192 PE. 194 MH: Multihome. 196 OAM: Operations, Administration and Maintenance. 198 PE: Provide Edge Node. 200 SID: Segment Identifier. 202 SR: Segment Routing. 204 BGP PIC: BGP Prefix independent convergence. 206 4. Control Plane Functionality 208 4.1. Service discovery 210 A node can discover L3VPN services instances as well as the 211 associated service SIDs on other nodes via configuration or auto- 212 discovery. With the latter, the service SIDs can be advertised using 213 BGP. As mentioned earlier, the service SIDs can be MPLS label 214 (absolute value or index into an SRGB) or SRv6 uSID. 216 VPNv4/v6 prefixes and operation type, i.e., to inform BGP neighbors 217 whether prefixes are added or deleted, can be advertised in a new 218 TLV. The prefixes will be packed efficiently; prefix length followed 219 by prefixes sharing the same prefix length. With this format, at 220 least 12k VPNv4 prefixes can be encoded in the message. A single 221 route will carry a large number of VPN prefixes (e.g., ~10k VPNv4 222 prefixes), instead of advertising one route per each VPN prefix. In 223 the case of VPNv4, this results in approximately four orders of 224 magnitude reduction in BGP messages. L3VPN Service SIDs may be 225 allocated from an SRGB range dedicated only for L3VPN services. 227 ____ CE3 228 / ____CE1 229 -------- PE3 --------- / 230 / PE1 231 / | \ 232 PE5 | \ 233 /| | \ 234 / | Service Provider Network | CE2 235 CE5 | | / 236 \ | | / 237 \ | PE2/ 238 PE6 / 239 / -------- PE4 -------- 240 CE6___ / CE4_____/ 242 Figure 1: A Reference L3VPN Network 244 Each PE nodes (PE1 through PE6 in Figure 1) advertises, via IGP/BGP, 245 (1) a regular Node SID to be used by the PE nodes when an L3VPN 246 service is attached to local Single-Home sites, and/or (2) an anycast 247 SID per MH site when an L3VPN service is attached to the MH site. 248 For example, in Figure 1, the PE nodes PE3 and PE4 could advertise a 249 Node SID for an L3VPN associated with the CE5 and CE3, respectively. 250 For MH, the PE5 and PE6 can advertise an anycast SID for an L3VPN 251 associated with the CE2. With the use of anycast SID per MH site, 252 shared by PEs attached to the site, there is no need to implement any 253 BGP PIC techniques at the L3VPN layer, as the routing convergence 254 relies on the underlay of SR. The data plane can be MPLS or SRv6. 256 5. Data Plane Behavior 258 The proposed method requires L3 data packet be formed as shown in 259 Figure 2. 261 +-------------------------------+ 262 | SID(s) to reach destination | 263 +-------------------------------+ 264 | Service SID | 265 +-------------------------------+ 266 | Layer-3 Payload | 267 +-------------------------------+ 269 Figure 2: Data packet format for sending L3VPN traffic 271 * SID(s) to reach destination: depends on the intent of the underlay 272 transport: 274 - IGP shortest path: node SID of the destination. The 275 destination can belong to an anycast group. 277 - IGP path with intent: Flex-Algo SID if the destination can be 278 reached using the Flex-Algo SID for a specific intent (e.g., 279 low latency path). The destination can belong to an anycast 280 group. 282 - SR policy (to support fine intent): a SID-list for the SR 283 policy that can be used to reach the destination. 285 * Service SID: The SID that uniquely identifies a L3VPN instance in 286 an SR domain. 288 6. Service discovery 290 A node can discover L3VPN services instances as well as the 291 associated service SIDs on other nodes via configuration or auto- 292 discovery. With the latter, the service SIDs can be advertised using 293 BGP. As mentioned earlier, the service SIDs can be MPLS label 294 (absolute value or index into an SRGB) or SRv6 uSID. 296 The necessary BGP extensions will be specified in a future version of 297 this document. 299 7. All-Active service Redundancy 301 Referring to Figure 1, an anycast SID per MH Site is configured on 302 all PE nodes PE1, PE2, PE5, and PE6 attached to the MH sites, such as 303 CE2 and CE5. These anycast SIDs are advertised via BGP for 304 reachability. Each PE node 1, 2 and 5, 6 attached to the MH site, 305 advertises the same anycast SID to allow other nodes to discover the 306 membership (auto-discovery). With SRv6, L3VPN routes associated with 307 an MH site can be advertised as a single route containing both 308 anycast SID of the egress PEs and service SIDs. Multi-pathing/Fast 309 convergence achieved using the same mechanisms used for anycast SID. 310 Single-Active redundancy is the same as the All-Active model except 311 that the backup egress PE node advertises its route with a higher 312 cost than the primary egress PE node. 314 8. Multi-pathing 316 Packets destined to a MH CE is distributed to the PE nodes attached 317 to the CE for load-balancing purpose. This is achieved implicitly 318 due to the use of anycast SIDs for both ES as well as PE attached to 319 the ES. In Figure 1, traffic destined to CE5 is distributed via PE5 320 and PE6. 322 9. Mass service withdrawal 324 Node failure is detected by IGP/BGP will converge. Technique like 325 BFD shall be deployed for fast detection of failure. 327 On PE-CE link failure, the PE node withdraws the route to the 328 corresponding ES in BGP in order to stop receiving traffic to that 329 ES. 331 With MH case with anycast SID, upon detecting a failure on PE-CE 332 link, a PE node may forward incoming traffic to the impacted ES(s) to 333 other PE nodes part of the anycast group until it withdraws routes to 334 the impacted ES(s) for faster convergence. For example, in Figure 1, 335 assuming PE5 and PE6 are part of an anycast group, upon link failure 336 between PE5 and CE5, PE5 can forward the received packets from the 337 core to PE6 until it withdraws the anycast SID associated with the MH 338 site. 340 10. Benefits of L3VPN over SR 342 The proposed approach significantly reduces the control plane 343 overhead, provides fast convergence, and All-Active multi-homing as 344 well as multipathing benefits. The proposed approach eliminates the 345 need for BGP PIC. 347 11. Security Considerations 349 The mechanisms in this document use SR control plane as defined in 350 Security considerations described in SR control plane are equally 351 applicable. 353 12. IANA Considerations 355 TBD. 357 13. Acknowledgement 359 14. References 361 14.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 369 Decraene, B., Litkowski, S., and R. Shakir, "Segment 370 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 371 July 2018, . 373 14.2. Informative References 375 [I-D.ietf-spring-segment-routing-policy] 376 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 377 P. Mattes, "Segment Routing Policy Architecture", Work in 378 Progress, Internet-Draft, draft-ietf-spring-segment- 379 routing-policy-13, 28 May 2021, 380 . 383 [I-D.voyer-pim-sr-p2mp-policy] 384 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 385 Zhang, "Segment Routing Point-to-Multipoint Policy", Work 386 in Progress, Internet-Draft, draft-voyer-pim-sr-p2mp- 387 policy-02, 10 July 2020, . 390 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 391 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 392 2006, . 394 Authors' Addresses 396 Sami Boutros (editor) 397 Ciena Corporation 398 Canada 400 Email: sboutros@ciena.com 402 Siva Sivabalan (editor) 403 Ciena Corporation 404 United States of America 406 Email: ssivabal@ciena.com 408 James Uttaro 409 AT&T 410 United States of America 412 Email: ju1738@att.com 414 Daniel Voyer 415 Bell Canada 416 Canada 418 Email: daniel.voyer@bell.ca 420 Bin Wen 421 Comcast 422 United States of America 424 Email: bin_wen@cable.comcast.com 425 Luay Jalil 426 Verizon 427 United States of America 429 Email: luay.jalil@verizon.com