idnits 2.17.1 draft-boutros-bess-eline-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 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 (11 October 2021) is 899 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 371, but no explicit reference was found in the text == Unused Reference: 'RFC8660' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'RFC4664' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC8214' is defined on line 402, 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: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS 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 E-Line Service Model with Segment Routing Underlay 16 draft-boutros-bess-eline-services-over-sr-01 18 Abstract 20 This document proposes a new approach for realizing Ethernet line 21 (E-Line) services over Segment Routing (SR) networks. This approach 22 significantly improves scalability and convergence of control plane, 23 and simplifies network operation. Furthermore, it naturally yields 24 All-Active multi-homing support for E-Line services without relying 25 on any overlay techniques. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 14 April 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Control Plane Behavior . . . . . . . . . . . . . . . . . . . 5 64 4.1. Service discovery . . . . . . . . . . . . . . . . . . . . 5 65 4.2. All-Active Service Redundancy . . . . . . . . . . . . . . 5 66 4.3. E-Line Attributes . . . . . . . . . . . . . . . . . . . . 6 67 4.4. Service withdrawal . . . . . . . . . . . . . . . . . . . 6 68 5. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Data Packet Format . . . . . . . . . . . . . . . . . . . 6 70 5.2. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.3. Single-Homed CE . . . . . . . . . . . . . . . . . . . . . 7 72 5.4. Multi-Homed CE . . . . . . . . . . . . . . . . . . . . . 8 73 6. Benefits of E-Line services over SR . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 10.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 Historically, E-Line services are realized as Virtual Private Wire 85 Services (VPWS) using point-to-point (P2P) Pseudo-Wires (PWs). A PW 86 identifies both the service type and the service termination nodes in 87 both control and data planes. A PW can be dynamically established 88 via LDP or BGP. Ethernet VPN (EVPN) signaling mechanisms via BGP can 89 be used to provide VPWS with Single-Active and All-Active multihoming 90 redundancy as well as Inter-Autonomous System (AS) support. 92 This document proposes a new approach for supporting E-Line services 93 over Segment Routing (SR) networks. It reduces BGP signaling 94 overhead by at least by two orders of magnitudes compared to the 95 current EVPN-VPWS signaling mechanisms and hence yields better 96 control plane scalabilty. Furthermore, it eliminates the need to 97 associate Route Distinguisher (RD) and Route Target (RT) with EVPN 98 routes, and hence leads to simpler network operations. The proposed 99 approach enables the benefit of All-Active redundancy and aliasing 100 for the Multi-Home (MH) sites. This proposal makes use of the 101 properties of SR anycast SID to achieve redundancy and fast 102 convergence at the transport level. Anycast SIDs provide the ability 103 to discover nodes supporting multihoming and perform Designated 104 Forwarder (DF) election. As such, the need for any overlay mechanism 105 to achieve redundancy and fast convergence is eliminated. Also, the 106 proposed approach supports auto-discovery and single-sided service 107 provisioning. 109 In the proposed approach, an E-Line service instance is represented 110 by a Segment ID (SID) which is referred to "Service SID" in the rest 111 of the document. Such a SID can be: 113 * an MPLS label for SR-MPLS. 115 * a uSID (micro SID) for SRv6 representing network function 116 associated with an E-Line service instance. A new SRv6 network 117 programming function will be specified in the next version of this 118 document. 120 In the present form, classical VPWS service is incapable of 121 supporting All-Active multihoming. However, thanks to SR anycast SID 122 capability, the proposed approach natively provides such redundancy 123 at transport layer. 125 A Service SID is unique within a service domain. A node can 126 advertise service SID(s) of the E-Line instance(s) that it hosts via 127 BGP for auto-discovery purpose. In the case of SR-MPLS, a service 128 SID can be carried as a range of absolute MPLS label values or an 129 index into an Segment Routing Global Block (SRGB), and in the case of 130 SRv6, a service SID can be carried as uSID in BGP update. 132 A node advertising E-Line service routes packs information about as 133 many service instances as possible at the time of advertisement in a 134 single route. The objective is to reduce the volume of signaling 135 messages advertised as well as processed in control plane. E-Line 136 service SIDs are represented as an array. A service route contains 137 SID value at the start of the array and a bitmask where each bit 138 represents an index in the array. The SID value for an E-Line 139 service instance can be derived from the start and the index of the 140 array. When advertising routes to E-Line services, a node sends the 141 initial value of the SID array and sets the bitmask to indicate all 142 E-Line services instances that it hosts along with its node SID which 143 may be anycast SID for MH case. For FXC, a route containing the 144 start normalized VID and the bitmask of VIDs in association with the 145 E-Line service SID is advertised. The necessary BGP extension will 146 be described in a future version of this document. 148 Each node attached to the MH site advertises the same anycast SID to 149 allow other nodes to discover the redundancy group membership (auto- 150 discovery). 152 The proposed solution can also be applicable to the existing EVPN 153 control plane without compromising its benefits such as All-Active 154 multihoming on access, aliasing in the core, auto-provisioning and 155 auto-discovery, etc. With this approach, the need for advertising of 156 EVPN route types 1 and 4 as well Split-Horizon (SH) label is 157 eliminated which simplifies EVPN-VPWS operations. 159 In the following sections, we will describe the functionalities of 160 the proposed approach in detail. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 3. Abbreviations 170 CE: Customer Edge node e.g., host or router or switch. 172 E-Line: Ethernet virtual private line. 174 EVPN: Ethernet VPN. 176 MH: Multi-Home. 178 OAM: Operations, Administration and Maintenance. 180 PE: Provide Edge Node. 182 SID: Segment Identifier. 184 SR: Segment Routing. 186 VPWS: Virtual Private Wire Service. 188 4. Control Plane Behavior 190 ____ CE3 191 / ____CE1 192 -------- PE3 --------- / 193 / PE1 194 / | \ 195 PE5 | \ 196 /| | \ CE2 197 / | Service Provider Network | / 198 CE5 | | / 199 \ | | / 200 \| PE2 201 PE6 / 202 / -------- PE4 -------- 203 CE6___ / CE4_____/ 205 Figure 1: A reference network used for the examples below 207 4.1. Service discovery 209 A node (e.g., PE5 in Figure 1) can discover E-Line instances as well 210 as the associated service SIDs on other nodes (e.g., PE1, PE2, etc in 211 Figure 1) via configuration or auto-discovery. With the latter, the 212 service SIDs may be advertised using BGP. 214 4.2. All-Active Service Redundancy 216 An anycast SID per Ethernet Segment (ES) will be configured on all 217 nodes attached to a Multi-Home (MH) site. For example, in Figure 1, 218 PE1 and PE2 are configured with an anycast SID representing the 219 multi-homed site CE2. The ES anycast SIDs will be advertised in BGP 220 by nodes (e.g., PE1 and PE2) connected to the MH site. 222 Upon receiving advertisement containing ES anycast SID, a node (e.g., 223 PE5 in Figure 1) learns the nodes (e.g., PE1 and PE2) hosting MH 224 sites, and performs DF election. Aliasing is natively achieved at 225 transport layer. 227 4.3. E-Line Attributes 229 Layer 2 extended community can be advertised with E-Line service 230 routes. Such a route includes the start of service SID and the 231 bitmap of all other Services enabled on the advertising node. This 232 will be elaborated more in the next revision of this document. As 233 mentioned earlier, the goal is to pack information about as many 234 E-Line services hosted on the advertising node as possible to reduce 235 the overall amount of signaling messages. 237 4.4. Service withdrawal 239 Node failure can be detected due via IGP convergence. For faster 240 detection of node failure, mechanism like BFD can be deployed. The 241 proposed approach does not require additional service withdrawal 242 mechanism. 244 On PE-CE link failure, the PE node withdraws the route to the 245 corresponding ES in BGP in order to stop receiving traffic to that 246 ES. 248 With MH case with anycast SID, upon detecting a failure on PE-CE 249 link, a PE node may forward incoming traffic to the impacted ES(s) to 250 another PE node which is part of the anycast group until it withdraws 251 routes to the impacted ES(s) for faster convergence. For example, in 252 Figure 1, assuming PE5 and PE6 are part of an anycast group, upon 253 link failure between PE5 and CE5, PE5 can forward the received 254 packets from the core to PE6 until it withdraws the anycast SID 255 associated with the MH site. 257 5. Data Plane Behavior 259 5.1. Data Packet Format 261 The proposed method requires unicast data packet be formed as shown 262 in Figure 2. 264 +-------------------------------+ 265 | SID(s) to reach destination | 266 +-------------------------------+ 267 | Service SID | 268 +-------------------------------+ 269 | Layer-2 Payload | 270 +-------------------------------+ 272 Figure 2: Data packet format for sending traffic to a destination 274 * SID(s) to reach destination: depends on the intent of the underlay 275 transport: 277 - IGP shortest path: node SID of the destination. The 278 destination can belong to an anycast group. 280 - IGP path with intent: Flex-Algo SID if the destination can be 281 reached using the Flex-Algo SID for a specific intent (e.g., 282 low latency path). The destination can belong to an anycast 283 group. 285 - SR policy: a SID-list for the SR policy that can be used to 286 reach the destination. 288 * Service SID: The SID that uniquely identifies a E-Line service 289 instance in an SR domain. 291 5.2. Aliasing 293 Packets destined to a MH CE is distributed to the PE nodes attached 294 to the CE for load-balancing (UCMP/ECMP) purpose. This is achieved 295 implicitly due to the use of anycast SIDs for both ES as well as PE 296 attached to the ES. In our example, traffic destined to CE5 is 297 distributed via PE5 and PE6. 299 5.3. Single-Homed CE 301 Referring to Figure 1, PE3 and PE4 provide an E-Line service to 302 connect CE3 to CE4. If PE3 wants to forward a packet received from 303 CE3 to CE4, it formulates the packet as shown in Figure 3. 305 +-----------------------------+ 306 |Transport SID(s) to reach PE4| 307 +-----------------------------+ 308 | Service SID | 309 +-----------------------------+ 310 | Layer-2 Packet | 311 +-----------------------------+ 313 Figure 3: Data packet format for forwarding traffic from PE3 to CE4 315 5.4. Multi-Homed CE 317 Referring to Figure 1, PE5 and PE6 and PE1 and PE2 provide to provide 318 E-Line services to connect CE2 and CE5. PE5 and PE6 share an anycast 319 SID, and PE1 and PE2 share another anycast SID. 321 Packets sent from CE2 to CE5 are load-balanced (ECMP/UCMP) between 322 PE5 and PE6 assuming that PE1 and PE2 learned the corresponding 323 E-Line Service SID from PE5 and PE6. 325 The following diagram shows SID stack for a L2 packet sent from CE2 326 to CE5. 328 +--------------------------------+ 329 |Anycast Node SID for PE5 and PE6| 330 +--------------------------------+ 331 | Service SID | 332 +--------------------------------+ 333 | Layer-2 Packet | 334 +--------------------------------+ 336 Figure 4: Data packet format for forwarding traffic from PE1 or PE2 to CE5 338 In case of FXC the signaled normalized VID will be encoded in the 339 Layer 2 packet. 341 6. Benefits of E-Line services over SR 343 The proposed approach eliminates the need for establishing and 344 maintaining PWs as with legacy VPWS technology. This yields 345 significant reduction in control plane overhead. The proposed 346 approach provides the benefits as such fast convergence. Finally, 347 using anycast SID, the proposed approach provides All-Active 348 multihoming as well as aliasing. 350 7. Security Considerations 352 The mechanisms in this document use Segment Routing control plane as 353 defined in Security considerations described in Segment Routing 354 control plane are equally applicable. 356 8. IANA Considerations 358 TBD. 360 9. Acknowledgements 362 10. References 364 10.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, 368 DOI 10.17487/RFC2119, March 1997, 369 . 371 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 372 Decraene, B., Litkowski, S., and R. Shakir, "Segment 373 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 374 July 2018, . 376 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 377 Decraene, B., Litkowski, S., and R. Shakir, "Segment 378 Routing with the MPLS Data Plane", RFC 8660, 379 DOI 10.17487/RFC8660, December 2019, 380 . 382 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 383 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 384 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 385 . 387 10.2. Informative References 389 [I-D.ietf-spring-segment-routing-policy] 390 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 391 P. Mattes, "Segment Routing Policy Architecture", Work in 392 Progress, Internet-Draft, draft-ietf-spring-segment- 393 routing-policy-13, 28 May 2021, 394 . 397 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 398 2 Virtual Private Networks (L2VPNs)", RFC 4664, 399 DOI 10.17487/RFC4664, September 2006, 400 . 402 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 403 Rabadan, "Virtual Private Wire Service Support in Ethernet 404 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 405 . 407 Authors' Addresses 409 Sami Boutros (editor) 410 Ciena Corporation 411 United States of America 413 Email: sboutros@ciena.com 415 Siva Sivabalan (editor) 416 Ciena Corporation 417 Canada 419 Email: ssivabal@ciena.com 421 James Uttaro 422 AT&T 423 United States of America 425 Email: ju1738@att.com 427 Daniel Voyer 428 Bell Canada 429 Canada 431 Email: daniel.voyer@bell.ca 433 Bin Wen 434 Comcast 435 United States of America 437 Email: bin_wen@cable.comcast.com 438 Luay Jalil 439 Verizon 440 United States of America 442 Email: luay.jalil@verizon.com