Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents
Extracted elements (25)
All logic for seamless integration between (PBB-)EVPN and (PBB-)VPLS resides on the EVPN PEs, not the VPLS PEs. This allows VPLS PEs to remain unchanged — no software or hardware upgrade required — enabling brownfield deployment of EVPN into existing VPLS networks.
PBB-VPLS integration with EVPN and VPLS integration with PBB-EVPN are explicitly out of scope because no service provider requirements exist for these cross-technology combinations. The expected migration path is VPLS→EVPN and PBB-VPLS→PBB-EVPN, not cross-PBB integration.
The same Route Target may be used to identify a VPN on both EVPN and VPLS networks, relying on VPLS PEs to silently ignore unknown SAFIs (EVPN IMET). Alternatively, separate RTs combined with RT Constrain (RFC 4684) can prevent EVPN routes from reaching VPLS PEs entirely, providing a cleaner separation.
When ingress replication is used in the integrated network, the solution reduces MMRP scope (a soft-state protocol) to only existing VPLS PEs and uses the more robust BGP-based mechanism for multicast pruning among EVPN PEs. This avoids extending the fragile MMRP soft state into the new EVPN domain.
B-MAC address mobility anomalies in PBB-EVPN/PBB-VPLS integration: when the same B-MAC appears behind both a remote PBB-VPLS PE (learned in the data plane) and a PBB-EVPN PE (learned via BGP), the local PE SHOULD notify the operator, since there is no legitimate B-MAC mobility in this context.
VPLS PEs must support VPLS A-D per RFC 6074 for seamless integration; if a VPLS instance was provisioned without VPLS A-D, EVPN PEs can still integrate it but must manually configure PWs to all VPLS PEs in that instance, making the integration non-seamless.
When a C-MAC moves from a VPLS PE to an EVPN PE and only known unicast traffic follows, VPLS PEs (but not EVPN PEs) will black-hole traffic to the moved C-MAC until BUM traffic is originated with the moved MAC as source. This asymmetric black-holing is characteristic of VPLS behavior.
When a C-MAC moves from an EVPN PE to a VPLS PE, traffic black-holing can occur if only known unicast traffic is initiated from the moved MAC, because EVPN PEs do not re-advertise C-MACs learned over PWs. Black-holing persists until BUM traffic with the moved C-MAC as source is flooded (e.g., after MAC age-out).
A PBB-EVPN PE MUST establish a PW to each remote PBB-VPLS PE from which it has received only a VPLS A-D route. The PW is established between the B-components of PBB-EVPN and PBB-VPLS PEs per Section 4 of RFC 7041.
An EVPN PE MUST enable split horizon over all entries in the replication list — spanning both PWs to VPLS PEs and MP2P service tunnels to EVPN PEs — when using ingress replication for BUM traffic delivery.
An EVPN PE MUST establish a pseudowire (PW) to each remote PE from which it has received only a VPLS A-D route, and MUST set up the corresponding PW FEC label stack. The PW is set up between the VSI of the VPLS PE and the MAC-VRF of the EVPN PE.
An EVPN PE MUST set up the label stack for the MP2P VPN unicast FEC to any remote PE that has advertised an EVPN IMET route. This establishes the EVPN forwarding path between EVPN-capable PEs.
B-MAC addresses learned over PBB-VPLS PWs MUST be injected into the bridge table of the associated MAC-VRF on the PBB-EVPN PE and MUST NOT be advertised in the control plane to remote PBB-EVPN PEs, since every PBB-EVPN PE can learn them directly over its own PW to each PBB-VPLS PE.
C-MAC addresses learned over local Attachment Circuits by an EVPN PE MUST be injected into the corresponding MAC-VRF and MUST be advertised in the control plane using BGP EVPN routes. This distinguishes AC-learned MACs from PW-learned MACs in the integration model.
C-MAC addresses learned over VPLS PWs MUST be injected into the bridge table of the associated MAC-VRF on the EVPN PE. Because these PWs belong to the same split-horizon group as MP2P EVPN service tunnels, such C-MAC addresses MUST NOT be advertised in the control plane to remote EVPN PEs.
EVPN PEs MUST advertise both the BGP VPLS auto-discovery (A-D) route and the BGP EVPN Inclusive Multicast Ethernet Tag (IMET) route for a given VPN instance. VPLS PEs advertise only the BGP VPLS A-D route.
On a link failure in a single-active Ethernet segment, PBB-EVPN PEs MUST both (1) send a BGP B-MAC withdraw or MAC advertisement with MAC Mobility extended community to PBB-EVPN peers, and (2) follow VPLS MAC Flush procedures with PBB-VPLS peers.
When a VPLS PE receives an EVPN IMET route, it MUST ignore it on the basis that it belongs to an unknown SAFI. This ensures VPLS PEs remain unaffected by EVPN control-plane advertisements.
When an EVPN PE receives both a VPLS A-D route and an EVPN IMET route from the same remote PE for the same VPN instance, it MUST give preference to the EVPN route for discovery purposes. This ensures EVPN-capable PEs are distinguished from VPLS-only PEs.
When EVPN or PBB-EVPN PEs must operate seamlessly with VPLS or PBB-VPLS PEs, they MUST use Single-Active redundancy mode. All-Active redundancy is not applicable to VPLS and PBB-VPLS, making it out of scope for seamless integration.
In PBB-EVPN/PBB-VPLS integration, C-MAC addresses learned over local ACs are processed in the I-component of PBB-EVPN PEs and are not advertised in the control plane, per RFC 7623. Only B-MAC addresses are exchanged in the BGP control plane.
The BUM replication list for a PBB-EVPN PE is maintained per I-SID and is the union of sub-list A (MP2P service tunnels to PBB-EVPN PEs from EVPN IMET routes) and sub-list B (PWs to PBB-VPLS PEs), or sub-list A and sub-list C (MMRP-pruned subset of sub-list B per I-SID) when MMRP is used.
The BUM replication list maintained per VPN instance on an EVPN PE is the union of two sub-lists: sub-list A (MP2P service tunnels to remote EVPN PEs, derived from EVPN IMET route exchange) and sub-list B (PWs to all remote VPLS PEs in the same VPLS instance).
This document introduces no new security considerations. All security considerations from RFC 4761, RFC 4762, RFC 7080, RFC 7432, and RFC 7623 apply directly, as the document leverages the control-plane and data-plane procedures defined in those RFCs without modification.
An EVPN PE manages PW operational state based on route advertisement order: (1) if it first receives a VPLS A-D route then an EVPN IMET route from the same PE, it MUST bring the existing PW operationally down; (2) if it receives EVPN IMET first then VPLS A-D from the same PE, it sets up the PW but MUST keep it operationally down.