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