Virtual Ethernet Segments for EVPN and Provider Backbone Bridge EVPN
Extracted elements (25)
A Grouping Ethernet A-D per ES route (EVPN) and Grouping B-MAC route (PBB-EVPN) were introduced because a single ENNI can aggregate thousands of vESes; without grouping, port failure would require one BGP withdrawal per vES, causing significant DF election and convergence delay. A single Grouping route withdrawal allows all impacted vESes to be resolved in a single BGP message.
For PBB-EVPN, a shared B-MAC per PE is recommended for single-homed vESes (minimizing B-MAC table size), a shared B-MAC per PE per ENNI for Single-Active vESes (scoping failure propagation to the ENNI), and a dedicated B-MAC per vES for All-Active vESes (required for aliasing and split-horizon). A single B-MAC per vES per PE is an alternative allowed for Single-Active scenarios.
Standard PBB-EVPN C-MAC flushing via MAC Mobility on a per-port B-MAC is too coarse for vES: a single physical port aggregates thousands of EVCs, so port-level flushing invalidates C-MACs across all EVCs when only one EVC failed. RFC 9541's per-I-SID B-MAC/I-SID route was chosen to limit flushing blast radius to the single impacted service instance.
The scope of this document explicitly includes PBB-EVPN (RFC 7623), EVPN over MPLS (RFC 7432), and EVPN over IP (RFC 8365), but excludes EVPN over SRv6 (RFC 9252). The extension of vES to support All-Active multihoming in MPLS/IP access networks is also explicitly out of scope.
A PE device MUST handle single-homed vESes on a single physical port such as a single ENNI (R1a), and MUST support a combination of single-homed vESes and Single-Active multihomed vESes simultaneously on a single physical port (R1b).
A PE device that supports the vES function MUST support local switching among different vESes associated with the same service instance on a single physical port. For Single-Active vESes, local switching is performed among active EVCs associated with the same service instance on the same ENNI.
A PE supporting vES MUST handle a vES with m EVCs among n ENNIs belonging to p PEs in any arbitrary order, where n >= p >= m >= 2 (R4a). Each vES MUST be identified by its own virtual ESI (vESI) (R4b).
Each EVC SHOULD be independently monitored for its operational health (R5a). A failure in a single EVC, among many aggregated on a single physical port or ENNI, MUST trigger a DF election for its associated vES (R5b).
Failure and recovery of an EVC for a single-homed or All-Active vES SHALL NOT impact any other EVCs or service instances; for PBB-EVPN, it SHALL NOT trigger MAC flushing in any I-SID (R6a, R6b). For a Single-Active vES, MAC flushing MUST be limited to C-MACs associated with the multihomed device for that single service instance only (R6d).
For an EVC failure impacting a Single-Active vES in PBB-EVPN, the B-MAC/I-SID route C-MAC flushing mechanism from RFC 9541 SHOULD be used to limit flushing to only the impacted I-SID(s). When an EVC carries multiple VLANs each with its own broadcast domain, a separate B-MAC/I-SID route must be advertised per VLAN.
For LSP-based and PW-based vES, the non-DF PE SHOULD signal PW-status 'standby' to the Aggregation PE, applicable where there is a one-to-one mapping between EVI and the PW. A new DF PE MAY send an LDP MAC withdraw message as a MAC address flush notification.
In a Single-Active scenario, when a service moves to a newly elected DF PE, that PE MUST trigger a MAC address flush notification towards the associated vES if the multihoming device is a bridge or the multihoming network is an Ethernet bridged network.
The DF election timer (default value 3 seconds) MUST be the same across all PEs connected to the same vES.
The port 'color' encoded in the EVPN Router's MAC Extended Community MUST be unique. The ESI label extended community MUST NOT be added to a Grouping Ethernet A-D per ES route, and MUST be ignored on receipt; it is not used for BUM split-horizon on this route type.
There SHOULD be a mechanism equivalent to EVPN mass withdraw such that upon an ENNI failure, only a single BGP message to the PEs is needed to trigger DF election for all impacted vESes associated with that ENNI.
Upon port failure in PBB-EVPN: if the physical port MAC is used as B-MAC SA, the PE MUST use EVPN MAC route withdrawal to signal the flush; if the PE's shared MAC is used as B-MAC SA, the PE MUST re-advertise the MAC route with the MAC Mobility extended community. The first method is recommended as it minimizes flushing scope.
When the number of I-SIDs associated with a failed EVC is large, it is RECOMMENDED to assign a B-MAC per vES; upon EVC failure, the affected PE withdraws this B-MAC route to signal remote PEs to flush all associated C-MACs.
A Grouping Ethernet A-D per ES route represents all vESes associated with a physical port. It uses a Type 3 ESI (RFC 7432 Section 5) with the MAC field set to the port color (MAC address) and the 3-octet local discriminator set to 0xFFFFFF. It is advertised with Route Targets for all affected service instances; if Route Targets exceed capacity, multiple routes are advertised.
A virtual ESI (vESI) is the per-vES identifier that replaces the physical ESI in all EVPN control-plane operations: ES routes, Ethernet A-D per ES routes, aliasing, and mass-withdraw operations are all advertised using the vESI instead of a physical ESI. Each vES must carry its own unique vESI.
A virtual Ethernet Segment (vES) extends the traditional ES concept by associating an ES with a set of Ethernet Virtual Circuits (EVCs) such as VLANs, MPLS LSPs, or pseudowires instead of physical links. A multihomed vES can span across two or more ENNIs on any two or more PEs and operates in either Single-Active or All-Active redundancy mode.
DF election for vES follows RFC 7432 Section 8.5 service carving with ESI replaced by vESI: PEs advertise ES routes, wait 3 seconds for convergence, build an ordered list of PE IP addresses from the Originator Router's IP address field, and assign DF for EVPN instance with Ethernet Tag V using the rule (V mod N) = i, where N is the redundancy group size and i is the PE's ordinal.
Fast convergence upon ENNI failure (optional) uses Grouping routes: the failing PE withdraws its Grouping Ethernet A-D per ES route (EVPN) or Grouping B-MAC route (PBB-EVPN) before individual vES route withdrawals. Receiving multihoming PEs use the color-to-vES list to initiate DF election for all affected vESes; individual vES withdrawals subsequently clean up BGP tables but do not re-trigger DF election if the Grouping route withdrawal was already received.
In PBB-EVPN, a Grouping B-MAC route represents all vESes associated with a physical port, with the port color encoded directly into the route. A PE MAY also color individual vES B-MAC routes with the associated port's EVPN Router's MAC Extended Community to enable port-level grouping.
Physical ports (ENNIs) are 'colored' to group associated vESes using the EVPN Router's MAC Extended Community (RFC 9135), with the port MAC address as the default color. For EVPN this community is advertised with Ethernet A-D per ES routes; for PBB-EVPN it is advertised with B-MAC routes.
All security considerations from RFC 7432 (BGP MPLS-Based EVPN) and RFC 7623 (PBB-EVPN) apply directly to this document. No new security considerations are introduced because vES advertisements and processing of ES routes follow the same procedures as physical ESs in those RFCs.