idnits 2.17.1 draft-ietf-bess-evpn-vpws-14.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 (May 14, 2017) is 2531 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: 'RFCXXXX' is mentioned on line 546, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 2 errors (**), 0 flaws (~~), 2 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 VMware 4 Ali Sajassi 5 Samer Salam 6 Cisco Systems 7 John Drake 8 Juniper Networks 9 J. Rabadan 10 Nokia 12 Expires: November 15, 2017 May 14, 2017 14 Virtual Private Wire Service support in Ethernet VPN 15 draft-ietf-bess-evpn-vpws-14.txt 17 Abstract 19 This document describes how Ethernet VPN (EVPN) can be used to 20 support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN 21 enables the following characteristics for VPWS: single-active as well 22 as all-active multi-homing with flow-based load-balancing, eliminates 23 the need for Pseudowire (PW) signaling, and provides fast protection 24 convergence upon node or link failure. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2 Service interface . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1 VLAN-Based Service Interface . . . . . . . . . . . . . . . . 6 67 2.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 6 68 2.2.1 Port-Based Service Interface . . . . . . . . . . . . . . 7 69 2.3 VLAN-Aware Bundle Service Interface . . . . . . . . . . . . 7 70 3. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.1 EVPN Layer 2 attributes extended community . . . . . . . . . 7 72 4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5 EVPN Comparison to PW Signaling . . . . . . . . . . . . . . . . 11 74 6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1 Single-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 11 76 6.2 Multi-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 12 77 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 79 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 80 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13 82 10.2 Informative References . . . . . . . . . . . . . . . . . . 13 83 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 86 1 Introduction 88 This document describes how EVPN can be used to support VPWS in 89 MPLS/IP networks. The use of EVPN mechanisms for VPWS (EVPN-VPWS) 90 brings the benefits of EVPN to Point to Point (P2P) services. These 91 benefits include single-active redundancy as well as all-active 92 redundancy with flow-based load-balancing. Furthermore, the use of 93 EVPN for VPWS eliminates the need for traditional way of PW signaling 94 for P2P Ethernet services, as described in section 4. 96 [RFC7432] provides the ability to forward customer traffic to/from a 97 given customer Attachment Circuit (AC), without any Media Access 98 Control (MAC) lookup. This capability is ideal in providing P2P 99 services (aka VPWS services). [MEF] defines Ethernet Virtual Private 100 Line (EVPL) service as P2P service between a pair of ACs (designated 101 by VLANs) and Ethernet Private Line (EPL) service, in which all 102 traffic flows are between a single pair of ports, that in EVPN 103 terminology would mean a single pair of Ethernet Segments ES(es). 104 EVPL can be considered as a VPWS with only two ACs. In delivering an 105 EVPL service, the traffic forwarding capability of EVPN is based on 106 the exchange of a pair of Ethernet Auto-discovery (A-D) routes; 107 whereas, for more general VPWS as per [RFC4664], traffic forwarding 108 capability of EVPN is based on the exchange of a group of Ethernet AD 109 routes (one Ethernet AD route per AC/ES). In a VPWS service, the 110 traffic from an originating Ethernet Segment can be forwarded only to 111 a single destination Ethernet Segment; hence, no MAC lookup is needed 112 and the MPLS label associated with the per EVPN instance (EVI) 113 Ethernet A-D route can be used in forwarding user traffic to the 114 destination AC. 116 For both EPL and EVPL services, a specific VPWS service instance is 117 identified by a pair of per-EVI Ethernet A-D routes which together 118 identify the VPWS service instance endpoints and the VPWS service 119 instance. In the control plane the VPWS service instance is 120 identified using the VPWS service instance identifiers advertised by 121 each Provider Edge node (PE). In the data plane the value of the MPLS 122 label advertised by one PE is used by the other PE to send traffic 123 for that VPWS service instance. As with the Ethernet Tag in standard 124 EVPN, the VPWS service instance identifier has uniqueness within an 125 EVPN instance. 127 For EVPN routes, the Ethernet Tag IDs are set to zero for Port-based, 128 VLAN-based, and VLAN-bundle interface mode and set to non-zero 129 Ethernet Tag IDs for VLAN-aware bundle mode. Conversely, for EVPN- 130 VPWS, the Ethernet Tag ID in the Ethernet A-D route MUST be set to a 131 non-zero value for all four service interface types. 133 In terms of route advertisement and MPLS label lookup behavior, EVPN- 134 VPWS resembles the VLAN-aware bundle mode of [RFC7432] such that when 135 a PE advertises per-EVI Ethernet A-D route, the VPWS service instance 136 serves as a 32-bit normalized Ethernet Tag ID. The value of the MPLS 137 label in this route represents both the EVI and the VPWS service 138 instance, so that upon receiving an MPLS encapsulated packet, the 139 disposition PE can identify the egress AC from the MPLS label and 140 subsequently perform any required tag translation. For EVPL service, 141 the Ethernet frames transported over an MPLS/IP network SHOULD remain 142 tagged with the originating VLAN-ID (VID) and any VID translation 143 MUST be performed at the disposition PE. For EPL service, the 144 Ethernet frames are transported as is and the tags are not altered. 146 The MPLS label value in the Ethernet A-D route can be set to the 147 Virtual Extensible LAN (VXLAN) Network Identifier (VNI) for VXLAN 148 encapsulation as per [RFC7348], and this VNI will have a local scope 149 per PE and may also be equal to the VPWS service instance identifier 150 set in the Ethernet A-D route. When using VXLAN encap, the BGP 151 Encapsulation extended community is included in the Ethernet A-D 152 route as described in [ietf-evpn-overlay]. The VXLAN VNI like the 153 MPLS label that will be set in the tunnel header used to tunnel 154 Ethernet packets from all the service interface types defined in 155 section 2. The EVPN-VPWS techniques defined in this document has no 156 dependency on the tunneling technology. 158 The Ethernet Segment identifier encoded in the Ethernet A-D per-EVI 159 route is not used to identify the service. However it can be used for 160 flow-based load-balancing and mass withdraw functions as per the 161 [RFC7432] baseline. 163 As with standard EVPN, the Ethernet A-D per-ES route is used for fast 164 convergence upon link or node failure. The Ethernet Segment route is 165 used for auto-discovery of the PEs attached to a given multi-homed 166 Customer Edge node (CE) and to synchronize state between them. 168 1.1 Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 EVPN: Ethernet VPN 176 MAC: Media Access Control 178 MPLS: Multi Protocol Label Switching. 180 OAM: Operations, Administration and Maintenance. 182 PE: Provide Edge Node. 184 ASBR: Autonomous System Border Router 186 CE: Customer Edge device e.g., host or router or switch. 188 EVPL: Ethernet Virtual Private Line. 190 EPL: Ethernet Private Line. 192 EP-LAN: Ethernet Private LAN. 194 EVP-LAN: Ethernet Virtual Private LAN. 196 S-VLAN: Service VLAN identifier. 198 C-VLAN: Customer VLAN identifier. 200 VID: VLAN-ID. 202 VPWS: Virtual Private Wire Service. 204 EVI: EVPN Instance. 206 P2P: Point to Point. 208 VXLAN: Virtual Extensible LAN. 210 DF: Designated Forwarder. 212 L2: Layer 2. 214 MTU: Maximum Transmission Unit. 216 eBGP: Exterior Border Gateway Protocol. 218 iBGP: Internal Border Gateway Protocol. 220 ES: Ethernet Segment on a PE refers to the link attached to it, this 221 link can be part of a set of links attached to different PEs in multi 222 homed cases, or could be a single link in single homed cases. 224 ESI: Ethernet Segment Identifier. 226 Single-Active Mode: When a device or a network is multi-homed to two 227 or more PEs and when only a single PE in such redundancy group can 228 forward traffic to/from the multi-homed device or network for a given 229 VLAN, then such multi-homing or redundancy is referred to as "Single- 230 Active". 232 All-Active: When a device is multi-homed to two or more PEs and when 233 all PEs in such redundancy group can forward traffic to/from the 234 multi-homed device for a given VLAN, then such multi-homing or 235 redundancy is referred to as "All-Active". 237 VPWS Service Instance: It is represented by a pair of EVPN service 238 labels associated with a pair of endpoints. Each label is downstream 239 assigned and advertised by the disposition PE through an Ethernet A-D 240 per-EVI route. The downstream label identifies the endpoint on the 241 disposition PE. A VPWS service instance can be associated with only 242 one VPWS service identifier. 244 2 Service interface 246 2.1 VLAN-Based Service Interface 248 With this service interface, a VPWS instance identifier corresponds 249 to only a single VLAN on a specific interface. Therefore, there is a 250 one-to-one mapping between a VID on this interface and the VPWS 251 service instance identifier. The PE provides the cross-connect 252 functionality between an MPLS LSP identified by the VPWS service 253 instance identifier and a specific . If the VLAN is 254 represented by different VIDs on different PEs and different ES(es), 255 (e.g., a different VID per Ethernet segment per PE), then each PE 256 needs to perform VID translation for frames destined to its Ethernet 257 segment. In such scenarios, the Ethernet frames transported over an 258 MPLS/IP network SHOULD remain tagged with the originating VID, and a 259 VID translation MUST be supported in the data path and MUST be 260 performed on the disposition PE. 262 2.2 VLAN Bundle Service Interface 264 With this service interface, a VPWS service instance identifier 265 corresponds to multiple VLANs on a specific interface. The PE 266 provides the cross-connect functionality between the MPLS label 267 identified by the VPWS service instance identifier and a group of 268 VLANs on a specific interface. For this service interface, each VLAN 269 is presented by a single VID which means no VLAN translation is 270 allowed. The receiving PE, can direct the traffic based on EVPN label 271 alone to a specific port. The transmitting PE can cross-connect 272 traffic from a group of VLANs on a specific port to the MPLS label. 273 The MPLS-encapsulated frames MUST remain tagged with the originating 274 VID. 276 2.2.1 Port-Based Service Interface 278 This service interface is a special case of the VLAN bundle service 279 interface, where all of the VLANs on the port are mapped to the same 280 VPWS service instance identifier. The procedures are identical to 281 those described in Section 2.2. 283 2.3 VLAN-Aware Bundle Service Interface 285 Contrary to EVPN, in EVPN-VPWS this service interface maps to a VLAN- 286 based service interface (defined in section 2.1) and thus this 287 service interface is not used in EVPN-VPWS. In other words, if one 288 tries to define data plane and control plane behavior for this 289 service interface, one would realize that it is the same as that of 290 VLAN-based service. 292 3. BGP Extensions 294 This document specifies the use of the per-EVI Ethernet A-D route to 295 signal VPWS services. The Ethernet Segment Identifier field is set to 296 the customer ES and the Ethernet Tag ID 32-bit field MUST be set to 297 the VPWS service instance identifier value. The VPWS service instance 298 identifier value MAY be set to a 24-bit value and when a 24-bit value 299 is used, it MUST be right aligned. For both EPL and EVPL services 300 using a given VPWS service instance, the pair of PEs instantiating 301 that VPWS service instance will each advertise a per-EVI Ethernet A-D 302 route with its VPWS service instance identifier and will each be 303 configured with the other PE's VPWS service instance identifier. When 304 each PE has received the other PE's per-EVI Ethernet A-D route, the 305 VPWS service instance is instantiated. It should be noted that the 306 same VPWS service instance identifier may be configured on both PEs. 308 The Route-Target (RT) extended community with which the per-EVI 309 Ethernet A-D route is tagged identifies the EVPN instance in which 310 the VPWS service instance is configured. It is the operator's choice 311 as to how many and which VPWS service instances are configured in a 312 given EVPN instance. However, a given EVPN instance MUST NOT be 313 configured with both VPWS service instances and standard EVPN multi- 314 point services. 316 3.1 EVPN Layer 2 attributes extended community 318 This document defines a new extended community [RFC4360], to be 319 included with per-EVI Ethernet A-D routes. This attribute is 320 mandatory if multihoming is enabled. 322 +------------------------------------+ 323 | Type(0x06)/Sub-type(0x04)(2 octet)| 324 +------------------------------------+ 325 | Control Flags (2 octets) | 326 +------------------------------------+ 327 | L2 MTU (2 octets) | 328 +------------------------------------+ 329 | Reserved (2 octets) | 330 +------------------------------------+ 332 Figure 1: EVPN Layer 2 attributes extended community 334 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | MBZ |C|P|B| (MBZ = MUST Be Zero) 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 2: EVPN Layer 2 attributes Control Flags 341 The following bits in the Control Flags are defined; the remaining 342 bits MUST be set to zero when sending and MUST be ignored when 343 receiving this community. 345 Name Meaning 347 P If set to 1 in multihoming single-active scenarios, it 348 indicates that the advertising PE is the Primary PE. 349 MUST be set to 1 for multihoming all-active scenarios by 350 all active PE(s). 352 B If set to 1 in multihoming single-active scenarios, it 353 indicates that the advertising PE is the Backup PE. 355 C If set to 1, a Control word [RFC4448] MUST be present 356 when sending EVPN packets to this PE. It is recommended to 357 include the control word in the absence of Entropy Label. 359 L2 MTU (Maximum Transmission Unit) is a 2-octet value indicating the 360 MTU in bytes. 362 A received L2 MTU of zero means no MTU checking against local MTU is 363 needed. A received non-zero MTU MUST be checked against local MTU and 364 if there is a mismatch, the local PE MUST NOT add the remote PE as 365 the EVPN destination for the corresponding VPWS service instance. 367 The usage of the Per ES Ethernet A-D route is unchanged from its 368 usage in [RFC7432], i.e., the "Single-Active" bit in the flags of the 369 ESI Label extended community will indicate if single-active or all- 370 active redundancy is used for this ES. 372 In multihoming scenarios, the B and P flags MUST be cleared. A PE 373 that receives an update with both B and P flags set MUST treat the 374 route as a withdrawal. If the PE receives a route with both B and P 375 clear, it MUST treat the route as a withdrawal from the sender PE. 377 In a multihoming all-active scenario, there is no Designated 378 Forwarder (DF) election, and all the PEs in the ES that are active 379 and ready to forward traffic to/from the CE will set the P Flag. A 380 remote PE will do per-flow load-balancing to the PEs that set the P 381 Flag for the same Ethernet Tag and ESI. The B Flag in control flags 382 SHOULD NOT be set in the multihoming all-active scenario and MUST be 383 ignored by receiving PE(s) if set. 385 In multihoming single-active scenario for a given VPWS service 386 instance, the DF election should result in the Primary-elected PE for 387 the VPWS service instance advertising the P Flag set and the B Flag 388 clear, the Backup elected PE should advertise the P Flag clear and 389 the B Flag set, and the rest of the PEs in the same ES should signal 390 both P and B Flags clear. When the primary PE/ES fails, the primary 391 PE will withdraw the associated Ethernet A-D routes for the VPWS 392 service instance from the remote PE and the remote PEs should then 393 send traffic associated with the VPWS instance to the backup PE. DF 394 re-election will happen between the PE(s) in the same ES, and there 395 will be a newly elected primary PE and newly elected backup PE that 396 will signal the P and B Flags as described. A remote PE SHOULD 397 receive the P Flag set from only one Primary PE and the B Flag set 398 from only one Backup PE. However during transient situations, a 399 remote PE receiving a P Flag set from more than one PE will select 400 the last advertising PE as the primary PE when forwarding traffic. A 401 remote PE receiving a B Flag set from more than one PE will select 402 the last advertising PE as the backup PE. A remote PE MUST receive P 403 Flag set from at least one PE before forwarding traffic. 405 If a network uses entropy labels per [RFC6790] then the C Flag MUST 406 NOT be set and control word MUST NOT be used when sending EVPN- 407 encapsulated packets over a P2P LSP. 409 4 Operation 411 The following figure shows an example of a P2P service deployed with 412 EVPN. 413 Ethernet Ethernet 414 Native |<--------- EVPN Instance ----------->| Native 415 Service | | Service 416 (AC) | |<-PSN1->| |<-PSN2->| | (AC) 417 | V V V V V V | 418 | +-----+ +-----+ +-----+ +-----+ | 419 +----+ | | PE1 |======|ASBR1|==|ASBR2|===| PE3 | | +----+ 420 | |-------+-----+ +-----+ +-----+ +-----+-------| | 421 | CE1| | | |CE2 | 422 | |-------+-----+ +-----+ +-----+ +-----+-------| | 423 +----+ | | PE2 |======|ASBR3|==|ASBR4|===| PE4 | | +----+ 424 ^ +-----+ +-----+ +-----+ +-----+ ^ 425 | Provider Edge 1 ^ Provider Edge 2 | 426 | | | 427 | | | 428 | EVPN Inter-provider point | 429 | | 430 |<---------------- Emulated Service -------------------->| 432 Figure 3: EVPN-VPWS Deployment Model 433 iBGP sessions are established between PE1, PE2, ASBR1 and ASBR3, 434 possibly via a BGP route-reflector. Similarly, iBGP sessions are 435 established between PE3, PE4, ASBR2 and ASBR4. eBGP sessions are 436 established among ASBR1, ASBR2, ASBR3, and ASBR4. 438 All PEs and ASBRs are enabled for the EVPN SAFI and exchange per-EVI 439 Ethernet A-D routes, one route per VPWS service instance. For inter- 440 AS option B, the ASBRs re-advertise these routes with the NEXT_HOP 441 attribute set to their IP addresses as per [RFC4271]. The link 442 between the CE and the PE is either a C-tagged or S-tagged interface, 443 as described in [802.1Q], that can carry a single VLAN tag or two 444 nested VLAN tags and it is configured as a trunk with multiple VLANs, 445 one per VPWS service instance. It should be noted that the VLAN ID 446 used by the customer at either end of a VPWS service instance to 447 identify that service instance may be different and EVPN doesn't 448 perform that translation between the two values. Rather, the MPLS 449 label will identify the VPWS service instance and if translation is 450 needed, it should be done by the Ethernet interface for each service. 452 For single-homed CE, in an advertised per-EVI Ethernet A-D route the 453 ESI field is set to 0 and the Ethernet Tag ID is set to the VPWS 454 service instance identifier that identifies the EVPL or EPL service. 456 For a multi-homed CE, in an advertised per-EVI Ethernet A-D route the 457 ESI field is set to the CE's ESI and the Ethernet Tag ID is set to 458 the VPWS service instance identifier, which MUST have the same value 459 on all PEs attached to that ES. This allows an ingress PE in a 460 multihoming all-active scenario to perform flow-based load-balancing 461 of traffic flows to all of the PEs attached to that ES. In all cases 462 traffic follows the transport paths, which may be asymmetric. 464 The VPWS service instance identifier encoded in the Ethernet Tag ID 465 in an advertised per-EVI Ethernet A-D route MUST either be unique 466 across all ASs, or an ASBR needs to perform a translation when the 467 per-EVI Ethernet A-D route is re-advertised by the ASBR from one AS 468 to the other AS. 470 A per-ES Ethernet A-D route can be used for mass withdraw to withdraw 471 all per-EVI Ethernet A-D routes associated with the multi-home site 472 on a given PE. 474 5 EVPN Comparison to PW Signaling 476 In EVPN, service endpoint discovery and label signaling are done 477 concurrently using BGP. Whereas, with VPWS based on [RFC4448], label 478 signaling is done via LDP and service endpoint discovery is either 479 through manual provisioning or through BGP. 481 In existing implementations of VPWS using pseudowires(PWs), 482 redundancy is limited to single-active mode, while with EVPN 483 implementation of VPWS both single-active and all-active redundancy 484 modes can be supported. 486 In existing implementations with PWs, backup PWs are not used to 487 carry traffic, while with EVPN, traffic can be load-balanced among 488 different PEs multi-homed to a single CE. 490 Upon link or node failure, EVPN can trigger failover with the 491 withdrawal of a single BGP route per EVPL service or multiple EVPL 492 services, whereas with VPWS PW redundancy, the failover sequence 493 requires exchange of two control plane messages: one message to 494 deactivate the group of primary PWs and a second message to activate 495 the group of backup PWs associated with the access link. 497 Finally, EVPN may employ data plane egress link protection mechanisms 498 not available in VPWS. This can be done by the primary PE (on local 499 AC down) using the label advertised in the per-EVI Ethernet A-D route 500 by the backup PE to encapsulate the traffic and direct it to the 501 backup PE. 503 6 Failure Scenarios 505 On a link or port failure between the CE and the PE for both single 506 and multi-homed CEs, unlike [RFC7432] the PE MUST withdraw all the 507 associated Ethernet A-D routes for the VPWS service instances on the 508 failed port or link. 510 6.1 Single-Homed CEs 511 Unlike [RFC7432], EVPN-VPWS uses Ethernet A-D route advertisements 512 for single-homed Ethernet Segments. Therefore, upon a link/port 513 failure of this single-homed Ethernet Segment, the PE MUST withdraw 514 the associated per-EVI Ethernet A-D routes. 516 6.2 Multi-Homed CEs 518 For a faster convergence in multi-homed scenarios with either Single- 519 Active Redundancy or All-active redundancy, a mass withdraw technique 520 is used. A PE previously advertising a per-ES Ethernet A-D route, can 521 withdraw this route by signaling to the remote PEs to switch all the 522 VPWS service instances associated with this multi-homed ES to the 523 backup PE. 525 7 Acknowledgements 527 The authors would like to acknowledge Jeffrey Zhang, Wen Lin, Nitin 528 Singh, Senthil Sathappan, Vinod Prabhu, Himanshu Shah, Iftekhar 529 Hussain, Alvaro Retana and Acee Lindem for their feedback and 530 contributions to this document. 532 8 Security Considerations 534 The mechanisms in this document use EVPN control plane as defined in 535 [RFC7432]. Security considerations described in [RFC7432] are equally 536 applicable. 538 This document uses MPLS and IP-based tunnel technologies to support 539 data plane transport. Security considerations described in [RFC7432] 540 and in [ietf-evpn-overlay] are equally applicable. 542 9 IANA Considerations 544 IANA has allocated the following EVPN Extended Community sub-type: 545 SUB-TYPE VALUE NAME Reference 546 0x04 EVPN Layer 2 Attributes [RFCXXXX] 548 This document creates a registry called "EVPN Layer 2 Attributes 549 Control Flags". New registrations will be made through the "RFC 550 Required" procedure defined in [RFC5226]. 552 Initial registrations are as follows: 554 P Advertising PE is the Primary PE. 555 B Advertising PE is the Backup PE. 556 C Control word [RFC4448] MUST be present. 558 10 References 559 10.1 Normative References 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 563 1997, . 565 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 566 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 567 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 570 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 571 "Encapsulation Methods for Transport of Ethernet over MPLS Networks", 572 RFC 4448, April 2006. 574 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. 575 Yong, "The Use of Entropy Labels in MPLS Forwarding", November 2012. 577 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 578 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, . 581 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 582 Communities Attribute", RFC 4360, February 2006, . 585 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 586 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, 587 . 589 [RFC7348] Mahalingam, M., et al, "VXLAN: A Framework for Overlaying 590 Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August 591 2014 593 10.2 Informative References 595 [MEF] Metro Ethernet Forum, "Ethernet Services Definitions - Phase 596 2", Technical Specification MEF 6.1, April 2008, 597 https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.1.pdf 599 [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for 600 Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006, 601 . 603 [ietf-evpn-overlay] Sajassi-Drake et al., "A Network Virtualization 604 Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-07.txt, 605 work in progress, December, 2016 607 Contributors 609 In addition to the authors listed on the front page, the following 610 co-authors have also contributed to this document: 612 Daniel Voyer Bell Canada 614 Authors' Addresses 616 Sami Boutros 617 VMware, Inc. 618 Email: sboutros@vmware.com 620 Ali Sajassi 621 Cisco 622 Email: sajassi@cisco.com 624 Samer Salam 625 Cisco 626 Email: ssalam@cisco.com 628 John Drake 629 Juniper Networks 630 Email: jdrake@juniper.net 632 Jeff Tantsura 633 Individual 634 Email: jefftant@gmail.com 636 Dirk Steinberg 637 Steinberg Consulting 638 Email: dws@steinbergnet.net 640 Patrice Brissette 641 Cisco 642 Email: pbrisset@cisco.com 644 Thomas Beckhaus 645 Deutsche Telecom 646 Email: Thomas.Beckhaus@telekom.de 648 Jorge Rabadan 649 Nokia 650 Email: jorge.rabadan@nokia.com 652 Ryan Bickhart 653 Juniper Networks 654 Email: rbickhart@juniper.net