RFC 9744
EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC) Service
RFC 9744: EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC) Service 🎀
Okay bestie, let's get into it! 💖 This one is by A. Sajassi (editor), P. Brissette, J. Uttaro, J. Drake, S. Boutros, and J. Rabadan, published in March 2025. ✨ It's a Standards Track document, which means it's an official Internet standard, not just a suggestion. 👑 The status is ISSN 2070-1721. 🌸
Okay, so the vibe of this RFC is multiplexing. 🦋 It's about shoving tons of attachment circuits from different Ethernet Segments and physical ports into one EVPN-VPWS service tunnel, and it still keeps Single-Active and All-Active multi-homing working. 💅 It builds on RFC 8214, which builds on RFC 7432, so you need to know those two first. 🧚 No cap, it's the sequel to the sequel. 😭
Title block facts 🌈
- Author facts: A. Sajassi (Ed.), P. Brissette (Cisco Systems), J. Uttaro (Individual), J. Drake (Independent), S. Boutros (Ciena), J. Rabadan (Nokia).
- Category: Standards Track. 👑
- Date: March 2025. 🗓️
- Obsoletes and updates: this RFC doesn't obsolete or update anything. It builds on RFC 8214 and RFC 7432 instead. 🫶
Status of This Memo 📜
This is an Internet Standards Track document. 💖
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. ✨
Info about the current status, errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9744. 🔥
Copyright Notice ©️
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions for this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. 💜
Table of Contents 🗺️
1. Introduction
1.1. Terminology
1.2. Requirements Language
2. Requirements
3. Solution
3.1. VPWS Service Identifiers
3.2. Default Flexible Cross-Connect
3.2.1. Multi-homing
3.3. VLAN-Signaled FXC
3.3.1. Local Switching
3.4. Service Instantiation
4. BGP Extensions
5. Failure Scenarios
5.1. EVPN-VPWS Service Failure
5.2. Attachment Circuit Failure
5.3. PE Port Failure
5.4. PE Node Failure
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Contributors
Authors' Addresses1. Introduction 🎀
[RFC8214] is the one that describes how to deliver point-to-point (P2P) services using the BGP constructs from [RFC7432]. 💅 It delivers that P2P service between a pair of Attachment Circuits (ACs). An AC on a PE can be a port, a VLAN on a port, or a group of VLANs on a port. 🦋
It also uses the multi-homing and fast convergence features of [RFC7432]. Multi-homing includes Single-Active and All-Active redundancy modes. Fast convergence comes from a "mass withdrawal" message in the control plane, plus fast protection switching with prefix-independent convergence in the data plane when a node or link fails [BGP-PIC]. ⚡ And because EVPN BGP constructs exist, you don't need multi-segment pseudowire auto-discovery and signaling when a VPWS service has to span multiple Autonomous Systems (ASes) [RFC5659]. No more extra work, periodt! 🙌
Okay, so here's the problem. 😭 Service providers have a huge number of ACs (we're talking millions) that need to get backhauled across their MPLS/IP network. Some of these ACs need tag manipulation (like VLAN translation) and some don't. 🍓 The providers want to multiplex lots of ACs across several physical interfaces, spread over one or more PEs (for example, several ESs), onto a single VPWS service tunnel. Why? Two big reasons: a) to cut down the number of EVPN service labels on each EVPN-VPWS service tunnel, which also cuts the Operations, Administration, and Maintenance (OAM) monitoring work, and b) to cut down EVPN BGP signaling. They don't want to signal each AC one by one, like [RFC8214] does. 🧚
The providers want all of this without giving up anything [RFC8214] offers, including Single-Active and All-Active multi-homing and fast convergence. 💖
So this document specifies a solution based on extensions to EVPN-VPWS [RFC8214] to meet those requirements. 🫶 [RFC8214] is itself based on extensions to EVPN [RFC7432], so a thorough understanding of [RFC7432] and [RFC8214] is a prerequisite for this document. Read those first, bestie! 📚
1.1. Terminology 🌸
AC: Attachment Circuit
ES: Ethernet Segment
ESI: Ethernet Segment Identifier
EVI: EVPN Instance Identifier
EVPN: Ethernet Virtual Private Network
Ethernet A-D: Ethernet Auto-Discovery (per EVI or per Ethernet A-D
per ESI routes, as defined in [RFC7432] and [RFC8214])
FXC: Flexible Cross-Connect
MAC: Media Access Control
MPLS: Multiprotocol Label Switching
OAM: Operations, Administration, and Maintenance
PE: Provider Edge
VCCV: Virtual Circuit Connectivity Verification
VID: VLAN ID
VPWS: Virtual Private Wire Service
VRF: VPN Routing and Forwarding
IP-VRF: VPN Routing and Forwarding for IP lookup
MAC-VRF: VPN Routing and Forwarding for MAC lookup
VID-VRF: VPN Routing and Forwarding for normalized VID lookup
VPWS Service Tunnel: It 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 through
an Ethernet A-D per EVI route. The downstream label identifies
the endpoint on the disposition PE. A VPWS service tunnel can be
associated with many VPWS service identifiers where each
identifier is a normalized VID.
Single-Active Redundancy Mode: When a device or a network is multi-
homed to two or more PEs and when only a single PE in such
redundancy group can forward traffic to/from the multi-homed
device or network for a given VLAN, then such multi-homing or
redundancy is referred to as "Single-Active".
All-Active Redundancy Mode: When a device or a network is multi-
homed to two or more PEs and when all PEs in such redundancy group
can forward traffic to/from the multi-homed device or network for
a given VLAN, then such multi-homing or redundancy is referred to
as "All-Active".1.2. Requirements Language 🦋
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💜 Basically, these words only count as requirements when they're in ALL CAPS, bestie. 🙈
(Part 1 of 4. More to come, so stay tuned! 💅✨)
2. Requirements ✨
Okay so the two big reasons service providers want a new solution are: 1) cutting down on how many VPWS service tunnels they need by multiplexing a huge pile of ACs across different physical interfaces, instead of giving every single AC its own tunnel, and 2) reducing the signaling of ACs as much as humanly possible 💅. On top of that, they also want the multi-homing and fast convergence capabilities of [RFC8214]. Main character energy, fr 🦋.
Here's how [RFC8214] does it. A PE signals an AC indirectly. First it ties that AC to a VPWS service tunnel (e.g., a VPWS service instance), and then it signals that tunnel with an Ethernet A-D per EVI route. The Ethernet Tag field gets set to a 24-bit VPWS service instance identifier (unique within the EVI), and the ESI field gets set to a 10-octet identifier of the ES for that AC 🎀.
So a PE that receives these EVPN routes can link the VPWS service tunnel to the remote ES using the ESI field 🔗. Now, when the remote ES fails and the PE gets the "mass withdrawal" message for that failed ES per [RFC7432], it can quickly update its next-hop adjacency list (adjacency list) for every VPWS service tunnel sharing that ESI field. That's how you get fast convergence for multi-homing scenarios 🚀. But even if fast convergence weren't a priority, you'd still need to signal each AC failure (through its VPWS service tunnel) tied to the failed ES. That way the adjacency list gets updated and packets head to a backup PE (in Single-Active multi-homing) or to the other PEs in the redundancy group (in All-Active multi-homing). If the adjacency list isn't updated properly, the egress PE with the failed ES/AC drops the traffic for that VPWS service tunnel 💀.
Now the tricky bit 🙈. When one VPWS service tunnel carries several ACs across various ESs (physical interfaces) without signaling those ACs via EVPN BGP to remote PE devices, the remote PEs don't have the info to link the received ES to those ACs, or to their own local ACs. They also don't know the link between the VPWS service tunnel (e.g., the EVPN service label) and the far-end ACs. So the remote PEs can match their local ACs to the VPWS service tunnel, but they can't do the same for the far-end ACs. Lowkey messy.
That means if the ES loses connectivity, the remote PEs can't redirect traffic through another multi-homing PE to that ES. Even if an ES failure gets signaled to them via EVPN, they can't really respond, because they don't know how the remote ES, the remote ACs, and the VPWS service tunnel are related 😭.
To fix this when you're multiplexing a large number of ACs onto a single VPWS service tunnel, two mechanisms were developed. One supports VPWS services between two single-homed endpoints. The other supports VPWS services where one of the endpoints is multi-homed 🌈.
For single-homed endpoints, it's acceptable not to signal each AC in BGP. Why? Because if the connection to the ES fails, there's no alternative path to that endpoint anyway ✨. The catch is that not signaling an AC failure means traffic for the failed AC still rides the MPLS/IP core, then gets discarded at the destination PE, which potentially wastes network resources 🍓.
This waste during a connection failure may be temporary, since in certain cases it can be detected and prevented at the application layer 🧚. Section 3.2 outlines a solution for such single-homing VPWS services.
For VPWS services where one of the endpoints is multi-homed, there are two options:
- Signal each AC via BGP, so the adjacency list can be updated when a failure hits those ACs. This is described in Section 3.3 and is referred to as the "VLAN-signaled FXC service" 👑.
- Bundle several ACs on an ES together per destination endpoint (e.g., ES, MAC-VRF, etc.) and associate that bundle with a single VPWS service tunnel. This is similar to the VLAN bundle service interface described in [RFC8214]. This solution is described in Section 3.2.1 💜.
3. Solution
Okay bestie, this section explains how to set up a brand-new VPWS service between two PE devices, where a big crowd of ACs (like VLANs) spanning multiple ESs (physical interfaces) on each PE gets multiplexed onto one single P2P EVPN service tunnel 🦋. Since the multiplexing involves several physical interfaces, you can end up with overlapping VLAN IDs (VIDs) across them. In that case, the VIDs must be translated into unique VIDs to prevent collisions 🙅♀️. Also, if the number of VLANs multiplexed onto a single VPWS service tunnel goes past 4095, then a single tag to double tag translation must be performed. This translation of VIDs into unique VIDs (either single or double) results in a "normalized VID" 💖.
When a single normalized VID is used, the lower 12 bits of the Ethernet Tag ID field in EVPN routes MUST be set to that VID. When a double normalized VID is used, the lower 12 bits of the Ethernet Tag ID field MUST be set to the inner VID, while the higher 12 bits are set to the outer VID. 24-bit VPWS service instance identifiers [RFC8214] as well as 12-bit VPWS service instance identifiers representing normalized VIDs MUST be right-aligned 📐.
Since there's only a single EVPN-VPWS service tunnel tied to many normalized VIDs (single or double) across multiple physical interfaces, an MPLS lookup at the disposition PE is no longer enough to forward the packet to the correct egress endpoint or interface 😵. So on top of an EVPN label lookup for the VPWS service tunnel, a VID lookup (either single or double) is also required 🔥. At the disposition PE, the EVPN label lookup identifies a VID-VRF, and then looking up the normalized VIDs within that table identifies the right egress endpoint or interface. The tag manipulation (translation from normalized VIDs to the local VID) SHOULD be performed either as part of the VID table lookup or at the egress interface itself 🎯.
Since the VID lookup (single or double) needs to happen at the disposition PE, VID normalization MUST be completed prior to MPLS encapsulation on the ingress PE 🧠. This requires both the imposition and disposition PE devices to be capable of VLAN tag manipulation, like rewriting (single or double), adding, or deleting (single or double) at their endpoints (e.g., their ESs, MAC-VRFs, IP-VRFs, etc.). Operators should be informed of potential trade-offs from a performance standpoint, compared to typical pseudowire processing ⚠️.
3.1. VPWS Service Identifiers
In [RFC8214], a unique value identifying the service is signaled in the context of each PE's EVI 🪪. The 32-bit Ethernet Tag ID field MUST be set to this VPWS service instance identifier value. Translation at an Autonomous System Border Router (ASBR) is needed if re-advertising to another AS affects uniqueness 🌸.
For FXC, this same Ethernet Tag ID field value is an identifier that may represent:
- VLAN Bundle Service Interface: a unique value for a group of VLANs
- VLAN-Aware Bundle Service Interface: a unique value for individual VLANs, and is considered the same as the normalized VID
Both the VPWS service instance identifier and the normalized VID are carried in the Ethernet Tag ID field of the Ethernet A-D per EVI route. For FXC, in the case of a 12-bit ID, the VPWS service instance identifier is the same as the single-tag normalized VID, and it will be the same on both VPWS service endpoints 👯. Similarly, in the case of a 24-bit ID, the VPWS service instance identifier is the same as the double-tag normalized VID ✨.
3.2. Default Flexible Cross-Connect
In this mode of operation, many ACs across several ESs are multiplexed into a single EVPN-VPWS service tunnel represented by a single VPWS service ID 🧺. This is the default mode of operation for FXC, and the participating PEs don't need to signal the VLANs (normalized VIDs) in EVPN BGP 🙌.
On the data plane side, the imposition PE does the VID normalization, and the disposition PE does the VID lookup and translation. Both imposition and disposition PE devices MUST be aware of the VLANs through configuration. There should ideally be a single point-to-point (P2P) EVPN-VPWS service tunnel between a pair of PEs for a specific set of ACs 🫶.
As mentioned before, because the EVPN-VPWS service tunnel is used to multiplex ACs across various ESs or physical interfaces, the EVPN label alone isn't enough to accurately forward received packets over the MPLS/IP network to egress interfaces 🙃. So normalized VID lookup is REQUIRED in the disposition direction to forward packets to their proper egress endpoints. The EVPN label lookup identifies a VID-VRF, and a subsequent normalized VID lookup in that table identifies the egress interface 🗺️.
In this solution, for each PE, the single-homing ACs represented by their normalized VIDs are associated with a single VPWS service instance within a specific EVI 💅. The generated EVPN route is an Ethernet A-D per-EVI route with an ESI of 0. The Ethernet Tag field is set to a VPWS service instance ID, and the MPLS label field is set to a dynamically generated EVPN service label representing the EVPN-VPWS service tunnel. This route is sent with a Route Target (RT) that represents the EVI, which can be auto-generated from the EVI according to Section 5.1.2.1 of [RFC8365]. Additionally, this route is sent with the EVPN Layer 2 Attributes Extended Community defined in Section 3.1 of [RFC8214], with two new flags (outlined in Section 4) that indicate: 1) the VPW service tunnel (set to default Flexible Cross-Connect) and 2) the normalized VID type (set to normalized single VID or double VID). The receiving PE uses these new flags for a consistency check, and it MAY generate an alarm if it detects inconsistencies, but it will not disrupt the VPWS service 🚨.
It should be noted that in this mode of operation, a single Ethernet A-D per-EVI route is transmitted when the first AC with the normalized VID is configured. As additional ACs are configured and associated with this EVPN-VPWS service tunnel, the PE doesn't advertise any additional EVPN BGP routes. It only locally associates those ACs with the pre-established VPWS service tunnel 🦋✨.
3.2.1. Multi-homing
The default FXC mode can also be used for multi-homing 💜. In this mode, a group of normalized VIDs representing ACs on a single ES, all destined to a single endpoint, are multiplexed into a single EVPN-VPWS service tunnel, which is identified by a unique VPWS service ID. When employing the default FXC mode for multi-homing, rather than using a single EVPN-VPWS service tunnel, there may be multiple service tunnels per pair of PEs. Specifically, there is one tunnel for each group of VIDs per pair of PEs, and there can be many such groups between a pair of PEs, resulting in numerous EVPN service tunnels 🌈🎀.
3.3. VLAN-Signaled FXC ✨
This mode is basically the default FXC mode from Section 3.2, but with a glow-up 💅. Lots of normalized VIDs representing ACs across several ESs and interfaces get multiplexed into one EVPN-VPWS service tunnel. The twist is that this single tunnel shows up as multiple VPWS service IDs (one per normalized VID), and those normalized VIDs get signaled using EVPN BGP 🦋.
In this solution, each PE configures the multi-homing ACs, represented by their normalized VIDs, with a single EVI 🌸. You don't need a separate VPWS service instance ID here, because it just matches the normalized VID. For each normalized VID on each ES, the PE generates an Ethernet A-D per-EVI route where the ESI field holds the ES ID, the Ethernet Tag field is set to the normalized VID, and the MPLS label field is set to a dynamically generated EVPN label for the P2P EVPN service tunnel. That label is the same for every AC multiplexed into one EVPN-VPWS service tunnel 🎀. The route goes out with an RT that represents the EVI. Same as before, this RT can be auto-generated from the EVI per Section 5.1.2.1 of [RFC8365] 💖.
The route also carries the EVPN Layer 2 Attributes Extended Community from Section 3.1 of [RFC8214], plus two new flags (spelled out in Section 4) that tell the receiver two things: 1) this VPWS service tunnel is for VLAN-signaled FXC, and 2) what type of normalized VID it is (single versus double). The receiving PE uses these flags for a consistency check, and if it spots an inconsistency it may raise an alarm, but it will not disrupt the VPWS service 🙈.
Quick note: in this mode the PE sends a single Ethernet A-D per-EVI route for each AC that's configured. Every normalized VID configured per ES ends up generating one Ethernet A-D per EVI 🍓.
Why is this so iconic? Because the VIDs are signaled in EVPN BGP, this mode can automatically cross-check the normalized VIDs used for Ethernet Virtual Private Line (EVPL) services 😭. For example, say the same normalized VID is configured on three PE devices (instead of two) for the same EVI. When a PE receives the second remote Ethernet A-D per EVI route, it generates an error message unless both routes include the same ESI. That kind of cross-checking just isn't possible in the default FXC mode, because there the normalized VIDs aren't signaled at all 🔥.
3.3.1. Local Switching 🏠
When a cross-connection happens between two ACs that belong to two multi-homed ESs on the same set of multi-homing PEs, the forwarding between those two ACs must be done locally during normal operation (e.g., when there's no local link failure). So traffic between the two ACs MUST be locally switched within the PE 👑.
On the control plane side, this means that when the receiving PE processes an Ethernet A-D per-EVI route whose ESI is a local ESI, the PE does not change its forwarding state based on that received route. This keeps local switching ahead of forwarding over the MPLS/IP network, which is the main character move here ✨. It lines up with the baseline EVPN principles in [RFC7432], where locally switched preference is specified for MAC/IP routes 🌈.
In these scenarios, the Ethernet A-D per-EVI route should be advertised with an MPLS label that's tied either to the destination AC or to the destination ES, so forwarding stays unambiguous 🧚. The MPLS label can't represent the same VID-VRF described in Section 3.3, because the same normalized VID can be reachable through two ESs (iykyk, it gets messy fast 💀). If you use an MPLS label per destination AC, this approach can also be applied to VLAN-based VPWS or VLAN bundle VPWS services, as per [RFC8214] 💜.
3.4. Service Instantiation 🌱
The V field defined in Section 4 is OPTIONAL. But if it's transmitted, its value may point to an error condition that could cause operational issues. In that case, just telling the operator about the error isn't enough; the VPWS service tunnel must not be established 🚫.
If both endpoints of a VPWS tunnel are signaling a matching normalized VID in the control plane, but one is running single-tag mode and the other is running double-tag mode, then signaling the V-bit helps detect and prevent that tunnel from being instantiated 🫶.
If single VID normalization is signaled in the Ethernet Tag ID field (12 bits) but the data plane is working with double tags, the VID normalization only applies to the outer tag. On the flip side, if double VID normalization is signaled in the Ethernet Tag ID field (24 bits), the VID normalization applies to both the inner and outer tags 💅.
4. BGP Extensions 🎀
This document uses the EVPN Layer 2 Attributes Extended Community as defined in [RFC8214], with two additional flags built into this Extended Community (EC), as detailed below. This EC is sent with the Ethernet A-D per-EVI route per Section 3, and it SHOULD be sent for both Single-Active and All-Active redundancy modes 🦋.
+-------------------------------------------+
| Type (0x06) / Sub-type (0x04) (2 octets) |
+-------------------------------------------+
| Control Flags (2 octets) |
+-------------------------------------------+
| L2 MTU (2 octets) |
+-------------------------------------------+
| Reserved (2 octets) |
+-------------------------------------------+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | V | M | |C|P|B| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the rundown on the Control Flags. The bits listed below are the defined ones. Every other bit MUST be set to zero when sending, and MUST be ignored when receiving this community 🙏.
+=======+==============================================+
| Name | Meaning |
+=======+==============================================+
| B,P,C | per definition in [RFC8214] |
+-------+----------------------------------------------+
| M | 00 mode of operation as defined in [RFC8214] |
| +----------------------------------------------+
| | 01 VLAN-Signaled FXC |
| +----------------------------------------------+
| | 10 Default FXC |
+-------+----------------------------------------------+
| V | 00 operating per [RFC8214] |
| +----------------------------------------------+
| | 01 single-VID normalization |
| +----------------------------------------------+
| | 10 double-VID normalization |
+-------+----------------------------------------------+
Table 1The M and V fields are OPTIONAL. The M field is ignored at reception for forwarding purposes, and it's used for error notifications 📣.
5. Failure Scenarios 🌩️
Let's look at two failure scenarios, shall we? 👀
The first one is a default Flexible Cross-Connect with a multi-homing solution, shown in Figure 1. Here VID normalization is performed, and a single Ethernet A-D per-EVI route is sent for the bundle of ACs on an ES. So PE1 advertises two Ethernet A-D per-EVI routes: the first identifies the ACs on port p1's ES, and the second identifies AC2 in port p2's ES. PE2 does the same thing and advertises two Ethernet A-D per-EVI routes too 💖.
N.VID 1,2,3 +---------------------+
PE1 | |
+---------+ IP/MPLS |
+-----+ VID1 p1 | +-----+ | sv.T1 +
| CE1 |-------------| FXC |======+ PE3 +-----+
| | /\ | | | | \ +----------+ +--| CE3 |
+-----+\ +||---| | sv.T2 \ | | 1/ | |
VID3\ / ||---| |=====+ \ | +-----+ | / +-----+
\ // \/ | +-----+ | \ +====| FXC |----+
\ / p2 +---------+ +======| | | 2 +-----+
/\ | | |----------| CE4 |
/ /\ +---------+ +=====| | | | |
/ / \p3 | +-----+ sv.T3 / +====| | | +-----+
VIDs1,2 / +----| FXC |=======+ / | | |---+
+-----+ / /\ | | | | / | +-----+ |\3 +-----+
| CE2 |-----||---| | | sv.T4 / | | \ | CE5 |
| |-----||---| | |======+ +----------+ +---| |
+--VIDs3,4 \/ | +-----+ | | +-----+
p4 +---------+ |
PE2 | |
N.VID 1,2,3 +-------------------+
Figure 1: Default Flexible Cross-ConnectThe second scenario, shown in Figure 2, illustrates VLAN-signaled FXC mode with multi-homing. In this example:
- CE1 is connected to PE1 and PE2 via (port,VID)=(p1,1) and (p3,3), respectively. CE1's VIDs are normalized to value 1 on both PEs, and CE1 is cross-connected to CE3's VID 1 at the remote end 🧩.
- CE2 is connected to PE1 and PE2 via ports p2 and p4, respectively:
- The combinations (p2,1) and (p4,3) identify the ACs used to cross-connect CE2 to CE4's VID 2, and they're normalized to value 2 💫.
- The combinations (p2,2) and (p4,4) identify the ACs used to cross-connect CE2 to CE5's VID 3, and they're normalized to value 3 🌷.
In this scenario, PE1 and PE2 advertise an Ethernet A-D per EVI route for each normalized VID (values 1, 2, and 3). Only two VPWS Service Tunnels are needed, though: 1) VPWS Service Tunnel 1 (sv.T1) between PE1's FXC and PE3's FXC, and 2) VPWS Service Tunnel 2 (sv.T2) between PE2's FXC and PE3's FXC 🦋.
N.VID 1,2,3 +---------------------+
PE1 | |
+---------+ IP/MPLS |
+-----+ VID1 p1 | +-----+ | +
| CE1 |------------| FXC | | sv.T1 PE3 +-----+
| | /\ | | |=======+ +----------+ +--| CE3 |
+-----+\ +||---| | | \ | | 1/ | |
VID3\ / ||---| | | \ | +-----+ | / +-----+
\ / /\/ | +-----+ | +=====| FXC |----+
\ / p2 +---------+ | | | | 2 +-----+
/\ | | |----------| CE4 |
/ /\ +---------+ +======| | | | |
/ / \p3 | +-----+ | / | | | | +-----+
VIDs1,2 / +----| FXC | / | | |---+
+-----+ / /\ | | |======+ | +-----+ |\3 +-----+
| CE2 |-----||-----| | | sv.T2 | | \ | CE5 |
| |-----||-----| | | +----------+ +---| |
+-----+ \/ | +-----+ | | +-----+
VIDs3,4 p4 +---------+ |
PE2 | |
N.VID 1,2,3 +------------------+
Figure 2: VLAN-Signaled FXC5.1. EVPN-VPWS Service Failure ✨
okay so failure detection for an EVPN-VPWS service can be done with OAM stuff like Bidirectional Forwarding Detection (BFD) for the pseudowire Virtual Circuit Connectivity Verification (VCCV) [RFC5885] 🔍 and once a failure gets detected, the switch over to the backup PE works exactly the same way we already went over above 💅
5.2. Attachment Circuit Failure 🎀
bestie, when an AC fails, the VLAN-Signaled mode and the default FXC mode act totally different 😭
- Default FXC (Figure 1): in default mode, a VLAN or AC failure is not signaled 🙈 So if something like
VID1onCE2goes down, nothing stopsPE3from sending traffic fromCE4over toPE1. That can cause packet loss at the egress PE with the failed AC 💀 If you need per-VLAN fault propagation in this situation, application layer OAM may be used. - VLAN-Signaled FXC (Figure 2): when a VLAN or AC fails, like
VID1onCE2, that kicks off a withdrawal of the Ethernet A-D per-EVI route for the matching Normalized VID, which is Ethernet-Tag 2 🦋 WhenPE3gets that route withdrawal, it removesPE1from its outgoing adjacency list for traffic coming fromCE4✨
5.3. PE Port Failure 🌸
if a PE port fails, the failure gets signaled and the other PE takes over forwarding in both scenarios 🧚
- Default FXC (Figure 1): if a port like
p2fails, the route for Service Tunnel 2 (sv.T2) gets withdrawn 🫶 WhenPE3hears about the fault, it removesPE1from its adjacency list for traffic fromCE4andCE5👑 - VLAN-Signaled FXC (Figure 2): a port failure like
p2triggers withdrawal of the Ethernet A-D per EVI routes for normalized VIDs 2 and 3, plus withdrawal of the Ethernet A-D per-ES route forp2's ES 😭 OncePE3gets the fault notification, it removesPE1from its adjacency list for the traffic fromCE4andCE5💅
5.4. PE Node Failure 🌈
for a PE node failure it's basically the same steps as above, except the EVPN route withdrawals get done by the route reflector instead of the PE itself 🦋
6. Security Considerations 🔐
okay this one is serious bestie 😭🔥 Since this document describes a muxing capability that leverages EVPN-VPWS signaling, no extra functionality beyond the muxing service gets added. That means no additional security considerations are needed beyond what's already specified in [RFC8214] 🫶
7. IANA Considerations 📋
this document allocated bits 8-11 in the "EVPN Layer 2 Attributes Control Flags" registry, with the names M and V 💜
M Signaling mode of operation (bits 10-11)
V VLAN-ID normalization (bits 8-9)8. References 📚
8.1. Normative References ✨
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.8.2. Informative References 🦋
[BGP-PIC] Bashandy, A., Ed., Filsfils, C., and P. Mohapatra, "BGP
Prefix Independent Convergence", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-bgp-pic-21, 7 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
bgp-pic-21>.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
DOI 10.17487/RFC5659, October 2009,
<https://www.rfc-editor.org/info/rfc5659>.
[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)", RFC 5885,
DOI 10.17487/RFC5885, June 2010,
<https://www.rfc-editor.org/info/rfc5885>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.Contributors 🫶
In addition to the authors listed on the front page, these coauthors also contributed a lot to this document 💖
Wen Lin
Juniper Networks
Email: wlin@juniper.net
Luc Andre Burdet
Cisco
Email: lburdet@cisco.comAuthors' Addresses 💌
Ali Sajassi (editor)
Cisco Systems
Email: sajassi@cisco.com
Patrice Brissette
Cisco Systems
Email: pbrisset@cisco.com
James Uttaro
Individual
Email: juttaro@ieee.org
John Drake
Independent
Email: je_drake@yahoo.com
Sami Boutros
Ciena
Email: sboutros@ciena.com
Jorge Rabadan
Nokia
Email: jorge.rabadan@nokia.com📦 where this page comes from
- ietf: rfc9744 2025-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms