idnits 2.17.00 (12 Aug 2021) /tmp/idnits49582/draft-boutros-l2vpn-evpn-vpws-05.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 date (October 21, 2014) is 2768 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) == Missing Reference: 'MEF' is mentioned on line 104, but not defined == Missing Reference: 'RFC2119' is mentioned on line 146, but not defined == Missing Reference: 'RFC4448' is mentioned on line 292, but not defined == Unused Reference: 'KEYWORDS' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'EVPN-REQ' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'PBB-EVPN' is defined on line 389, but no explicit reference was found in the text == Outdated reference: draft-ietf-l2vpn-evpn-req has been published as RFC 7209 == Outdated reference: draft-ietf-l2vpn-evpn has been published as RFC 7432 == Outdated reference: draft-ietf-l2vpn-pbb-evpn has been published as RFC 7623 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Sami Boutros 3 Intended Status: Standard Track Ali Sajassi 4 Samer Salam 5 Cisco Systems 7 John Drake 8 Juniper Networks 10 Jeff Tantsura 11 Ericsson 13 Dirk Steinberg 14 Steinberg Consulting 16 Thomas Beckhaus 17 Deutsche Telecom 19 Expires: April 24, 2015 October 21, 2014 21 VPWS support in E-VPN 22 draft-boutros-l2vpn-evpn-vpws-05.txt 24 Abstract 26 This document describes how E-VPN can be used to support virtual 27 private wire service (VPWS) in MPLS/IP networks. E-VPN enables the 28 following characteristics for VPWS: single-active as well as all- 29 active multi-homing with flow-based load-balancing, eliminates the 30 need for single-segment and multi-segment PW signaling, and provides 31 fast protection using data-plane prefix independent convergence upon 32 node or link failure. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as 42 Internet-Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/1id-abstracts.html 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 Copyright and License Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4 EVPN Comparison to PW Signaling . . . . . . . . . . . . . . . . 7 78 5 ESI Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 8 80 6.1 Single-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 8 81 6.1 Multi-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 8 82 7 VPWS with multiple sites . . . . . . . . . . . . . . . . . . . . 8 83 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 84 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 85 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 86 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 11.1 Normative References . . . . . . . . . . . . . . . . . . . 9 88 11.2 Informative References . . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 91 1 Introduction 93 This document describes how EVPN can be used to support virtual 94 private wire service (VPWS) in MPLS/IP networks. The use of EVPN 95 mechanisms for VPWS brings the benefits of EVPN to p2p services. 96 These benefits include single-active redundancy as well as all-active 97 redundancy with flow-based load-balancing. Furthermore, the use of 98 EVPN for VPWS eliminates the need for signaling single-segment and 99 multi-segment PWs for p2p Ethernet services. 101 [EVPN] has the ability to forward customer traffic to/from a given 102 customer Attachment Circuit (AC), aka Ethernet Segment in EVPN 103 terminology, without any MAC lookup. This capability is ideal in 104 providing p2p services (aka VPWS services). [MEF] defines Ethernet 105 Virtual Private Line (EVPL) service as p2p service between a pair of 106 ACs (designated by VLANs) and Ethernet Private Line (EPL) service, in 107 which all traffic flows are between a single pair of ESes. EVPL can 108 be considered as a VPWS with only two ACs. In delivering an EVPL 109 service, the traffic forwarding capability of EVPN based on the 110 exchange of a pair of Ethernet AD routes is used; whereas, for more 111 general VPWS, traffic forwarding capability of EVPN based on the 112 exchange of a group of Ethernet AD routes (one Ethernet AD route per 113 AC/segment) is used. In a VPWS service, the traffic from an 114 originating Ethernet Segment can be forwarded only to a single 115 destination Ethernet Segment; hence, no MAC lookup is needed and the 116 MPLS label associated with the per-EVI Ethernet AD route can be used 117 in forwarding user traffic to the destination AC. 119 Both services are supported by using the Per EVI Ethernet AD route 120 which contains an Ethernet Segment Identifier, in which the customer 121 ES is encoded, and an Ethernet Tag, in which the VPWS service 122 instance identifier is encoded. I.e., for both EPL and EVPL 123 services, a specific VPWS service instance is identified by a pair of 124 Per EVI Ethernet AD routes which together identify the VPWS service 125 instance endpoints and the VPWS service instance. In the control 126 plane the VPWS service instance is identified using the VPWS service 127 instance identifiers advertised by each PE and in the data plane the 128 MPLS label advertised by one PE is used by the other PE to send it 129 traffic for that VPWS service instance. As with the Ethernet Tag in 130 standard EVPN, the VPWS service instance identifier has uniqueness 131 within an EVPN instance. The Ethernet Segment identifier encoded in 132 he per EVI Ethernet AD route is not used to identify the service, 133 however it can be used for flow-based load-balancing and mass 134 withdraw functions. 136 As with standard EVPN, the Per ES Ethernet AD route is used for fast 137 convergence upon link or node failure and the Ethernet Segment route 138 is used for auto-discovery of the PEs attached to a given multi-homed 139 CE and to synchronize state between them. 141 1.1 Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 MAC: Media Access Control 149 MPLS: Multi Protocol Label Switching. 151 OAM: Operations, Administration and Maintenance. 153 PE: Provide Edge Node. 155 CE: Customer Edge device e.g., host or router or switch. 157 EVI: EVPN Instance. 159 Single-Active Mode: When a device or a network is multi-homed to two 160 or more PEs and when only a single PE in such redundancy group can 161 forward traffic to/from the multi-homed device or network for a given 162 VLAN, then such multi-homing or redundancy is referred to as "Single- 163 Active". 165 All-Active: When a device is multi-homed to two or more PEs and when 166 all PEs in such redundancy group can forward traffic to/from the 167 multi-homed device for a given VLAN, then such multi-homing or 168 redundancy is referred to as "All-Active". 170 1.2 Requirements 172 1. EPL service access circuit maps to the whole Ethernet port. 174 2. EVPL service access circuits are VLANs on single or double tagged 175 trunk ports. Each VLAN individually will be considered to be an 176 endpoint for an EVPL service, without any direct dependency on any 177 other VLANs on the trunk. Other VLANs on the same trunk could also be 178 used for EVPL services, but could also be associated with other 179 services. 181 3. If multiple VLANs on the same trunk are associated with EVPL 182 services, the respective remote endpoints of these EVPLs could be 183 dispersed across any number of PEs, i.e. different VLANs may lead to 184 different destinations. 186 4. The VLAN tag on the access trunk only has PE-local significance. 188 The VLAN tag on the remote end could be different, and could also be 189 double tagged when the other side is single tagged. 191 5. Also, multiple EVPL service VLANs on the same trunk could belong 192 to the same EVPN instance (EVI), or they could belong to different 193 EVIs. This should be purely an administrative choice of the network 194 operator. 196 6. A given access trunk could have hundreds of EVPL services, and a 197 given PE could have thousands of EVPLs configured. It must be 198 possible to configure multiple EVPL services within the same EVI. 200 7. Local access circuits configured to belong to a given EVPN 201 instance could also belong to different physical access trunks. 203 2. BGP Extensions 205 This document proposes the use of the Per EVI Ethernet AD route to 206 signal VPWS services. The Ethernet Segment Identifier field is set to 207 the customer ES and the Ethernet Tag field is set to the VPWS service 208 instance identifier. For both EPL and EVPL services, for a given 209 VPWS service instance the pair of PEs instantiating that VPWS service 210 instance will each advertise a Per EVI Ethernet AD route with its 211 VPWS service instance identifier and will each be configured with the 212 other PE's VPWS service instance identifier. When each PE has 213 received the other PE's 215 Per EVI Ethernet AD route the VPWS service instance is instantiated. 216 It should be noted that the same VPWS service instance identifier may 217 be configured on both PEs. 219 The Route-Target (RT) extended community with which the Per EVI 220 Ethernet AD route is tagged identifies the EVPN instance in which the 221 VPWS service instance is configured. It is the operator's choice as 222 to how many and which VPWS service instances are configured in a 223 given EVPN instance. However, a given EVPN instance MUST NOT be 224 configured with both VPWS service instances and standard EVPN multi- 225 point services. 227 3 Operation 229 The following figure shows an example of a P2P service deployed with 230 EVPN. 231 Ethernet Ethernet 232 Native |<--------- EVPN Instance ----------->| Native 233 Service | | Service 234 (AC) | |<-PSN1->| |<-PSN2->| | (AC) 235 | V V V V V V | 236 | +-----+ +-----+ +-----+ +-----+ | 237 +----+ | | PE1 |======|ASBR1|==|ASBR2|===| PE3 | | +----+ 238 | |-------+-----+ +-----+ +-----+ +-----+-------| | 239 | CE1| | | |CE2 | 240 | |-------+-----+ +-----+ +-----+ +-----+-------| | 241 +----+ | | PE2 |======|ASBR3|==|ASBR4|===| PE4 | | +----+ 242 ^ +-----+ +-----+ +-----+ +-----+ ^ 243 | Provider Edge 1 ^ Provider Edge 2 | 244 | | | 245 | | | 246 | EVPN Inter-provider point | 247 | | 248 |<---------------- Emulated Service -------------------->| 250 iBGP sessions are established between PE1, PE2, ASBR1 and ASBR3, 251 possibly via a BGP route-reflector. Similarly, iBGP sessions are 252 established between PE3, PE4, ASBR2 and ASBR4. eBGP sessions are 253 established among ASBR1, ASBR2, ASBR3, and ASBR4. 255 All PEs and ASBRs are enabled for the EVPN SAFI and exchange Per EVI 256 Ethernet AD routes, one route per VPWS service instance. For inter- 257 AS option B, the ASBRs re-advertise these routes with Next Hop 258 attribute set to their IP addresses. The link between the CE and the 259 PE is either a C-tagged or S-tagged interface, as described in 260 [802.1Q], that can carry a single VLAN tag or two nested VLAN tags 261 and it is configured as a trunk with multiple VLANs, one per VPWS 262 service instance. It should be noted that the VLAN ID used by the 263 customer at either end of a VPWS service instance to identify that 264 service instance may be different and EVPN doesn't perform that 265 translation between the two values. Rather, this should be done by 266 the Ethernet interface. 268 For single-homed CE, in an advertised Per EVI Ethernet AD route the 269 ESI field is set to 0 and the Ethernet Tag field is set to the VPWS 270 service instance identifier that identifies the EVPL or EPL service. 272 For a multi-homed CE, in an advertised Per EVI Ethernet AD route the 273 ESI field is set to the CE's ESI and the Ethernet Tag field is set to 274 the VPWS service instance identifier, which MUST have the same value 275 on all PEs attached to that ES. This allows an ingress PE to perform 276 flow-based load-balancing of traffic flows to all of the PEs attached 277 to that ES. In all cases traffic follows the transport paths, which 278 may be asymmetric. 280 The VPWS service instance identifier encoded in the Ethernet Tag 281 field in an advertised Per EVI Ethernet AD route MUST either be 282 unique across all ASs, or an ASBR needs to perform a translation when 283 the per EVI Ethernet AD route is re-advertised by the ASBR from one 284 AS to the other AS. 286 Per ES EAD route can be used for mass withdraw to withdraw all per 287 EVI EAD routes associated with the multi-home site on a given PE. 289 4 EVPN Comparison to PW Signaling 291 In EVPN, service endpoint discovery and label signaling are done 292 concurrently using BGP. Whereas, with VPWS based on [RFC4448], label 293 signaling is done via LDP and service endpoint discovery is either 294 through manual provisioning or through BGP. 296 In existing implementation of VPWS using pseudowires(PWs), redundancy 297 is limited to single-active mode, while with EVPN implementation of 298 VPWS both single-active and all-active redundancy modes can be 299 supported. 301 In existing implementation with PWs, backup PWs are not used to carry 302 traffic, while with EVPN, traffic can be load-balanced among 303 different PEs multi-homed to a single CE. 305 Upon link or node failure, EVPN can trigger failover with the 306 withdrawal of a single BGP route per EVPL service or multiple EVPL 307 services, whereas with VPWS PW redundancy, the failover sequence 308 requires exchange of two control plane messages: one message to 309 deactivate the group of primary PWs and a second message to activate 310 the group of backup PWs associated with the access link. Finally, 311 EVPN may employ data plane local repair mechanisms not available in 312 VPWS. 314 5 ESI Bandwidth 316 The ESI Bandwidth will be encoded using the Link Bandwidth Extended 317 community defined in [draft-ietf-idr-link-bandwidth] and associated 318 with the Ethernet AD route used to realize the EVPL services. 320 When a PE receives this attribute for a given EVPL it MUST request 321 the required bandwidth from the PSN towards the other EVPL service 322 destination PE originating the message. When resources are allocated 323 from the PSN for a given EVPL service, then the PSN SHOULD account 324 for the Bandwidth requested by this EVPL service. 326 In the case where PSN resources are not available, the PE receiving 327 this attribute MUST re-send its local Ethernet AD routes for this 328 EVPL service with the ESI Bandwidth = All FFs to declare that the 329 "PSN Resources Unavailable". 331 The scope of the ESI Bandwidth is limited to only one Autonomous 332 System. 334 6 Failure Scenarios 336 On a link or port failure between the CE and the PE for both single 337 and multi-homed CEs, the PE must withdraw all the associated Ethernet 338 AD routes for the VPWS service instances on the failed port or link. 340 6.1 Single-Homed CEs 342 Unlike [EVPN], EVPN-VPWS uses Ethernet AD route advertisements for 343 single-homed Ethernet Segments. Therefore, upon a link/port failure 344 of this single-homed Ethernet Segment, the PE MUST withdraw the 345 associated Ethernet A-D routes. 347 6.1 Multi-Homed CEs 349 For a faster convergence in multi-homed scenarios with either Single- 350 Active Redundancy or All-active redundancy, mass withdraw technique 351 as per [EVPN] baseline is used. A PE previously advertising an 352 Ethernet A-D per ES route, can withdraw this route signaling to the 353 remote PEs to switch all the VPWS service instances associated with 354 this multi-homed ES to the backup PE 356 7 VPWS with multiple sites 358 The VPWS among multiple sites (full mesh of P2P connections - one per 359 pair of sites) that can be setup automatically without any explicit 360 provisioning of P2P connections among the sites is outside the scope 361 of this document. 363 8 Acknowledgements 365 The authors would like to acknowledge Wen Lin contributions to this 366 document. 368 9 Security Considerations 370 This document does not introduce any additional security constraints. 371 10 IANA Considerations 373 TBD. 375 11 References 376 11.1 Normative References 378 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 11.2 Informative References 383 [EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for 384 Ethernet VPN", draft-ietf-l2vpn-evpn-req-00.txt. 386 [EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet 387 VPN", draft-ietf-l2vpn-evpn-04.txt. 389 [PBB-EVPN] A. Sajassi et. al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- 390 05.txt. 392 [draft-ietf-idr-link-bandwidth] P. Mohapatra, R. Fernando, "BGP Link 393 Bandwidth Extended Community", draft-ietf-idr-link-bandwidth-06.txt 395 Authors' Addresses 397 Sami Boutros 398 Cisco 399 Email: sboutros@cisco.com 401 Ali Sajassi 402 Cisco 403 Email: sajassi@cisco.com 405 Samer Salam 406 Cisco 407 Email: ssalam@cisco.com 409 John Drake 410 Juniper Networks 411 Email: jdrake@juniper.net 413 Jeff Tantsura 414 Ericsson 415 Email: jeff.tantsura@ericsson.com 417 Dirk Steinberg 418 Steinberg Consulting 419 Email: dws@steinbergnet.net 420 Patrice Brissette 421 Cisco 422 Email: pbrisset@cisco.com 424 Thomas Beckhaus 425 Deutsche Telecom 426 Email:Thomas.Beckhaus@telekom.de>