Virtual Private Wire Service Support in Ethernet VPN
Extracted elements (29)
Because VPWS traffic from an originating Ethernet Segment can only be forwarded to a single destination Ethernet Segment, no MAC lookup is required; the MPLS label associated with the per-EVI Ethernet A-D route alone is sufficient to identify the destination AC and perform forwarding.
EVPN-VPWS eliminates the need for traditional PW signaling (LDP-based per RFC 4448) by using BGP to perform service endpoint discovery and label signaling concurrently, and additionally enables All-Active redundancy with flow-based load-balancing, which was not possible with PW-based VPWS.
EVPN-VPWS enables faster failover than PW redundancy: a single BGP route withdrawal per EVPL service triggers convergence, whereas PW redundancy requires two control-plane messages (deactivate primary group, then activate backup group). Additionally, EVPN can use data-plane egress link protection via the backup PE's label.
The VLAN-Aware Bundle Service Interface is explicitly not used in EVPN-VPWS because it would map identically to the VLAN-based service interface (Section 2.1); defining separate data-plane and control-plane behavior for it would yield no distinction from the VLAN-based service.
For EVPL service, Ethernet frames transported over MPLS/IP SHOULD remain tagged with the originating VID, and any VID translation MUST be performed at the disposition PE. For EPL service, frames are transported as-is and tags are not altered.
The MPLS label value in the Ethernet A-D route can be set to a VXLAN VNI for VXLAN encapsulation per RFC 7348, with the BGP Encapsulation extended community included in the route; the EVPN-VPWS techniques have no dependency on the tunneling technology.
A given EVPN instance MUST NOT be configured with both VPWS service instances and standard EVPN multipoint services; the two service types must be kept in separate EVPN instances.
A received non-zero L2 MTU value MUST be checked against the local MTU; if there is a mismatch, the local PE MUST NOT add the remote PE as the EVPN destination for the corresponding VPWS service instance.
A remote PE MUST receive the P Flag set from at least one PE before forwarding traffic; undefined bits in Control Flags MUST be set to zero on send and MUST be ignored on receive.
Either the VPWS service instance identifier encoded in the Ethernet Tag ID MUST be unique across all Autonomous Systems, or an ASBR must perform translation when re-advertising the per-EVI Ethernet A-D route between ASes.
For a multihomed CE, the VPWS service instance identifier in the per-EVI Ethernet A-D route MUST have the same value on all PEs attached to that Ethernet Segment, enabling ingress PEs to perform flow-based load-balancing in All-Active scenarios.
For EVPN-VPWS, the Ethernet Tag ID in the Ethernet A-D route MUST be set to a non-zero value for all four service interface types, in contrast to standard EVPN where port-based, VLAN-based, and VLAN bundle modes use zero.
For VLAN-based service interface, VID translation MUST be supported in the data path and MUST be performed on the disposition PE when frames are tagged with different VIDs on different PEs or Ethernet Segments.
For VLAN bundle service interface, MPLS-encapsulated frames MUST remain tagged with the originating VID; no VLAN translation is allowed since each VLAN is presented by a single VID.
If a network uses entropy labels per RFC 6790, the C Flag MUST NOT be set and the control word MUST NOT be used when sending EVPN-encapsulated packets over a P2P LSP.
If the C Flag is set to 1 in the EVPN Layer 2 Attributes Control Flags, a control word per RFC 4448 MUST be present when sending EVPN packets to the advertising PE.
The 32-bit Ethernet Tag ID field in the per-EVI Ethernet A-D route MUST be set to the VPWS service instance identifier; a 24-bit value MAY be used and MUST then be right-aligned within the 32-bit field.
The Ethernet A-D per-EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per-ES routes, consistent with RFC 7432 baseline behavior.
Unlike RFC 7432, EVPN-VPWS uses Ethernet A-D route advertisements for single-homed Ethernet Segments; upon a link/port failure of a single-homed ES, the PE MUST withdraw the associated per-EVI Ethernet A-D routes.
Upon a link or port failure between the CE and PE, the PE MUST withdraw all associated Ethernet A-D routes for the VPWS service instances on the failed port or link, for both single-homed and multihomed CEs.
A VPWS service instance is represented by a pair of EVPN service labels associated with a pair of endpoints; each label is downstream-assigned and advertised by the disposition PE via a per-EVI Ethernet A-D route, and a VPWS service instance can be associated with only one VPWS service identifier.
The EVPN Layer 2 Attributes Extended Community is mandatory when multihoming is enabled and is carried with per-EVI Ethernet A-D routes. Sub-type value 0x04 is allocated by IANA under EVPN Extended Community sub-types.
The MPLS label in the per-EVI Ethernet A-D route represents both the EVI and the VPWS service instance, allowing the disposition PE to identify the egress AC from the label and perform any required tag translation without a MAC lookup.
IANA allocated EVPN Extended Community sub-type value 0x04 for 'EVPN Layer 2 Attributes' under the existing EVPN Extended Community sub-types registry.
This document creates the 'EVPN Layer 2 Attributes Control Flags' registry with 'RFC Required' registration policy. Initial registrations are: P (advertising PE is primary), B (advertising PE is backup), C (control word per RFC 4448 MUST be present).
The mechanisms in this document use the EVPN control plane as defined in RFC 7432; the security considerations of RFC 7432 and the EVPN overlay solution are equally applicable, covering MPLS and IP-based tunnel technologies used for data-plane transport.
In All-Active multihoming, all active PEs set P=1 and the B Flag SHOULD NOT be set. A remote PE performs per-flow load-balancing across all PEs advertising P=1 for the same Ethernet Tag and ESI. If multiple PEs advertise P=1 in transient scenarios, the last advertising PE is selected as primary.
In Single-Active multihoming, the DF-elected primary PE sets P=1/B=0, the backup PE sets P=0/B=1, and remaining PEs set both to 0. On primary failure, the primary withdraws its Ethernet A-D routes, the remote PE switches traffic to the backup PE, and DF re-election selects a new primary and backup.
The EVPN Layer 2 Attributes Extended Community is 8 octets: Type/Sub-type (0x06/0x04, 2 octets), Control Flags (2 octets), L2 MTU (2 octets), Reserved (2 octets). Control Flags define bits P (primary PE), B (backup PE), and C (control word required); remaining bits MUST be zero.