idnits 2.17.00 (12 Aug 2021) /tmp/idnits50707/draft-boutros-l2vpn-evpn-vpws-04.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 (July 2, 2014) is 2879 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 101, but not defined == Missing Reference: 'RFC2119' is mentioned on line 143, but not defined == Missing Reference: 'RFC4448' is mentioned on line 289, but not defined == Unused Reference: 'KEYWORDS' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'EVPN-REQ' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'PBB-EVPN' is defined on line 365, 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: January 3, 2015 July 2, 2014 21 VPWS support in E-VPN 22 draft-boutros-l2vpn-evpn-vpws-04.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 7 VPWS with multiple sites . . . . . . . . . . . . . . . . . . . . 8 80 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 81 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 82 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 11.1 Normative References . . . . . . . . . . . . . . . . . . . 8 85 11.2 Informative References . . . . . . . . . . . . . . . . . . 8 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 88 1 Introduction 90 This document describes how EVPN can be used to support virtual 91 private wire service (VPWS) in MPLS/IP networks. The use of EVPN 92 mechanisms for VPWS brings the benefits of EVPN to p2p services. 93 These benefits include single-active redundancy as well as all-active 94 redundancy with flow-based load-balancing. Furthermore, the use of 95 EVPN for VPWS eliminates the need for signaling single-segment and 96 multi-segment PWs for p2p Ethernet services. 98 [EVPN] has the ability to forward customer traffic to/from a given 99 customer Attachment Circuit (AC), aka Ethernet Segment in EVPN 100 terminology, without any MAC lookup. This capability is ideal in 101 providing p2p services (aka VPWS services). [MEF] defines Ethernet 102 Virtual Private Line (EVPL) service as p2p service between a pair of 103 ACs (designated by VLANs) and Ethernet Private Line (EPL) service, in 104 which all traffic flows are between a single pair of ESes. EVPL can 105 be considered as a VPWS with only two ACs. In delivering an EVPL 106 service, the traffic forwarding capability of EVPN based on the 107 exchange of a pair of Ethernet AD routes is used; whereas, for more 108 general VPWS, traffic forwarding capability of EVPN based on the 109 exchange of a group of Ethernet AD routes (one Ethernet AD route per 110 AC/segment) is used. In a VPWS service, the traffic from an 111 originating Ethernet Segment can be forwarded only to a single 112 destination Ethernet Segment; hence, no MAC lookup is needed and the 113 MPLS label associated with the per-EVI Ethernet AD route can be used 114 in forwarding user traffic to the destination AC. 116 Both services are supported by using the Per EVI Ethernet AD route 117 which contains an Ethernet Segment Identifier, in which the customer 118 ES is encoded, and an Ethernet Tag, in which the VPWS service 119 instance identifier is encoded. I.e., for both EPL and EVPL 120 services, a specific VPWS service instance is identified by a pair of 121 Per EVI Ethernet AD routes which together identify the VPWS service 122 instance endpoints and the VPWS service instance. In the control 123 plane the VPWS service instance is identified using the VPWS service 124 instance identifiers advertised by each PE and in the data plane the 125 MPLS label advertised by one PE is used by the other PE to send it 126 traffic for that VPWS service instance. As with the Ethernet Tag in 127 standard EVPN, the VPWS service instance identifier has uniqueness 128 within an EVPN instance. The Ethernet Segment identifier encoded in 129 he per EVI Ethernet AD route is not used to identify the service, 130 however it can be used for flow-based load-balancing and mass 131 withdraw functions. 133 As with standard EVPN, the Per ES Ethernet AD route is used for fast 134 convergence upon link or node failure and the Ethernet Segment route 135 is used for auto-discovery of the PEs attached to a given multi-homed 136 CE and to synchronize state between them. 138 1.1 Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 MAC: Media Access Control 146 MPLS: Multi Protocol Label Switching. 148 OAM: Operations, Administration and Maintenance. 150 PE: Provide Edge Node. 152 CE: Customer Edge device e.g., host or router or switch. 154 EVI: EVPN Instance. 156 Single-Active Mode: When a device or a network is multi-homed to two 157 or more PEs and when only a single PE in such redundancy group can 158 forward traffic to/from the multi-homed device or network for a given 159 VLAN, then such multi-homing or redundancy is referred to as "Single- 160 Active". 162 All-Active: When a device is multi-homed to two or more PEs and when 163 all PEs in such redundancy group can forward traffic to/from the 164 multi-homed device for a given VLAN, then such multi-homing or 165 redundancy is referred to as "All-Active". 167 1.2 Requirements 169 1. EPL service access circuit maps to the whole Ethernet port. 171 2. EVPL service access circuits are VLANs on single or double tagged 172 trunk ports. Each VLAN individually will be considered to be an 173 endpoint for an EVPL service, without any direct dependency on any 174 other VLANs on the trunk. Other VLANs on the same trunk could also be 175 used for EVPL services, but could also be associated with other 176 services. 178 3. If multiple VLANs on the same trunk are associated with EVPL 179 services, the respective remote endpoints of these EVPLs could be 180 dispersed across any number of PEs, i.e. different VLANs may lead to 181 different destinations. 183 4. The VLAN tag on the access trunk only has PE-local significance. 185 The VLAN tag on the remote end could be different, and could also be 186 double tagged when the other side is single tagged. 188 5. Also, multiple EVPL service VLANs on the same trunk could belong 189 to the same EVPN instance (EVI), or they could belong to different 190 EVIs. This should be purely an administrative choice of the network 191 operator. 193 6. A given access trunk could have hundreds of EVPL services, and a 194 given PE could have thousands of EVPLs configured. It must be 195 possible to configure multiple EVPL services within the same EVI. 197 7. Local access circuits configured to belong to a given EVPN 198 instance could also belong to different physical access trunks. 200 2. BGP Extensions 202 This document proposes the use of the Per EVI Ethernet AD route to 203 signal VPWS services. The Ethernet Segment Identifier field is set to 204 the customer ES and the Ethernet Tag field is set to the VPWS service 205 instance identifier. For both EPL and EVPL services, for a given 206 VPWS service instance the pair of PEs instantiating that VPWS service 207 instance will each advertise a Per EVI Ethernet AD route with its 208 VPWS service instance identifier and will each be configured with the 209 other PE's VPWS service instance identifier. When each PE has 210 received the other PE's 212 Per EVI Ethernet AD route the VPWS service instance is instantiated. 213 It should be noted that the same VPWS service instance identifier may 214 be configured on both PEs. 216 The Route-Target (RT) extended community with which the Per EVI 217 Ethernet AD route is tagged identifies the EVPN instance in which the 218 VPWS service instance is configured. It is the operator's choice as 219 to how many and which VPWS service instances are configured in a 220 given EVPN instance. However, a given EVPN instance MUST NOT be 221 configured with both VPWS service instances and standard EVPN multi- 222 point services. 224 3 Operation 226 The following figure shows an example of a P2P service deployed with 227 EVPN. 228 Ethernet Ethernet 229 Native |<--------- EVPN Instance ----------->| Native 230 Service | | Service 231 (AC) | |<-PSN1->| |<-PSN2->| | (AC) 232 | V V V V V V | 233 | +-----+ +-----+ +-----+ +-----+ | 234 +----+ | | PE1 |======|ASBR1|==|ASBR2|===| PE3 | | +----+ 235 | |-------+-----+ +-----+ +-----+ +-----+-------| | 236 | CE1| | | |CE2 | 237 | |-------+-----+ +-----+ +-----+ +-----+-------| | 238 +----+ | | PE2 |======|ASBR3|==|ASBR4|===| PE4 | | +----+ 239 ^ +-----+ +-----+ +-----+ +-----+ ^ 240 | Provider Edge 1 ^ Provider Edge 2 | 241 | | | 242 | | | 243 | EVPN Inter-provider point | 244 | | 245 |<---------------- Emulated Service -------------------->| 247 iBGP sessions are established between PE1, PE2, ASBR1 and ASBR3, 248 possibly via a BGP route-reflector. Similarly, iBGP sessions are 249 established between PE3, PE4, ASBR2 and ASBR4. eBGP sessions are 250 established among ASBR1, ASBR2, ASBR3, and ASBR4. 252 All PEs and ASBRs are enabled for the EVPN SAFI and exchange Per EVI 253 Ethernet AD routes, one route per VPWS service instance. For inter- 254 AS option B, the ASBRs re-advertise these routes with Next Hop 255 attribute set to their IP addresses. The link between the CE and the 256 PE is either a C-tagged or S-tagged interface, as described in 257 [802.1Q], that can carry a single VLAN tag or two nested VLAN tags 258 and it is configured as a trunk with multiple VLANs, one per VPWS 259 service instance. It should be noted that the VLAN ID used by the 260 customer at either end of a VPWS service instance to identify that 261 service instance may be different and EVPN doesn't perform that 262 translation between the two values. Rather, this should be done by 263 the Ethernet interface. 265 For single-homed CE, in an advertised Per EVI Ethernet AD route the 266 ESI field is set to 0 and the Ethernet Tag field is set to the VPWS 267 service instance identifier that identifies the EVPL or EPL service. 269 For a multi-homed CE, in an advertised Per EVI Ethernet AD route the 270 ESI field is set to the CE's ESI and the Ethernet Tag field is set to 271 the VPWS service instance identifier, which MUST have the same value 272 on all PEs attached to that ES. This allows an ingress PE to perform 273 flow-based load-balancing of traffic flows to all of the PEs attached 274 to that ES. In all cases traffic follows the transport paths, which 275 may be asymmetric. 277 The VPWS service instance identifier encoded in the Ethernet Tag 278 field in an advertised Per EVI Ethernet AD route MUST either be 279 unique across all ASs, or an ASBR needs to perform a translation when 280 the per EVI Ethernet AD route is re-advertised by the ASBR from one 281 AS to the other AS. 283 Per ES EAD route can be used for mass withdraw to withdraw all per 284 EVI EAD routes associated with the multi-home site on a given PE. 286 4 EVPN Comparison to PW Signaling 288 In EVPN, service endpoint discovery and label signaling are done 289 concurrently using BGP. Whereas, with VPWS based on [RFC4448], label 290 signaling is done via LDP and service endpoint discovery is either 291 through manual provisioning or through BGP. 293 In existing implementation of VPWS using pseudowires(PWs), redundancy 294 is limited to single-active mode, while with EVPN implementation of 295 VPWS both single-active and all-active redundancy modes can be 296 supported. 298 In existing implementation with PWs, backup PWs are not used to carry 299 traffic, while with EVPN, traffic can be load-balanced among 300 different PEs multi-homed to a single CE. 302 Upon link or node failure, EVPN can trigger failover with the 303 withdrawal of a single BGP route per EVPL service or multiple EVPL 304 services, whereas with VPWS PW redundancy, the failover sequence 305 requires exchange of two control plane messages: one message to 306 deactivate the group of primary PWs and a second message to activate 307 the group of backup PWs associated with the access link. Finally, 308 EVPN may employ data plane local repair mechanisms not available in 309 VPWS. 311 5 ESI Bandwidth 313 The ESI Bandwidth will be encoded using the Link Bandwidth Extended 314 community defined in [draft-ietf-idr-link-bandwidth] and associated 315 with the Ethernet AD route used to realize the EVPL services. 317 When a PE receives this attribute for a given EVPL it MUST request 318 the required bandwidth from the PSN towards the other EVPL service 319 destination PE originating the message. When resources are allocated 320 from the PSN for a given EVPL service, then the PSN SHOULD account 321 for the Bandwidth requested by this EVPL service. 323 In the case where PSN resources are not available, the PE receiving 324 this attribute MUST re-send its local Ethernet AD routes for this 325 EVPL service with the ESI Bandwidth = All FFs to declare that the 326 "PSN Resources Unavailable". 328 The scope of the ESI Bandwidth is limited to only one Autonomous 329 System. 331 7 VPWS with multiple sites 333 The VPWS among multiple sites (full mesh of P2P connections - one per 334 pair of sites) that can be setup automatically without any explicit 335 provisioning of P2P connections among the sites is outside the scope 336 of this document. 338 8 Acknowledgements 340 The authors would like to acknowledge Wen Lin contributions to this 341 document. 343 9 Security Considerations 345 This document does not introduce any additional security constraints. 346 10 IANA Considerations 348 TBD. 350 11 References 352 11.1 Normative References 354 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 11.2 Informative References 359 [EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for 360 Ethernet VPN", draft-ietf-l2vpn-evpn-req-00.txt. 362 [EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet 363 VPN", draft-ietf-l2vpn-evpn-04.txt. 365 [PBB-EVPN] A. Sajassi et. al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- 366 05.txt. 368 [draft-ietf-idr-link-bandwidth] P. Mohapatra, R. Fernando, "BGP Link 369 Bandwidth Extended Community", draft-ietf-idr-link-bandwidth-06.txt 371 Authors' Addresses 372 Sami Boutros 373 Cisco 374 Email: sboutros@cisco.com 376 Ali Sajassi 377 Cisco 378 Email: sajassi@cisco.com 380 Samer Salam 381 Cisco 382 Email: ssalam@cisco.com 384 John Drake 385 Juniper Networks 386 Email: jdrake@juniper.net 388 Jeff Tantsura 389 Ericsson 390 Email: jeff.tantsura@ericsson.com 392 Dirk Steinberg 393 Steinberg Consulting 394 Email: dws@steinbergnet.net 396 Patrice Brissette 397 Cisco 398 Email: pbrisset@cisco.com 400 Thomas Beckhaus 401 Deutsche Telecom 402 Email:Thomas.Beckhaus@telekom.de>