rfc9744.original   rfc9744.txt 
BESS Working Group A. Sajassi, Ed. Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Internet-Draft P. Brissette Request for Comments: 9744 P. Brissette
Intended status: Standards Track Cisco Systems Category: Standards Track Cisco Systems
Expires: 21 June 2025 J. Uttaro ISSN: 2070-1721 J. Uttaro
AT&T AT&T
J. Drake J. Drake
Juniper Networks Juniper Networks
S. Boutros S. Boutros
Ciena Ciena
J. Rabadan J. Rabadan
Nokia Nokia
18 December 2024 February 2025
EVPN VPWS Flexible Cross-Connect Service EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC)
draft-ietf-bess-evpn-vpws-fxc-12 Service
Abstract Abstract
This document describes a new EVPN VPWS service type specifically for This document describes a new EVPN Virtual Private Wire Service
multiplexing multiple attachment circuits across different Ethernet (VPWS) service type specifically for multiplexing multiple attachment
Segments and physical interfaces into a single EVPN VPWS service circuits across different Ethernet Segments and physical interfaces
tunnel and still providing Single-Active and All-Active multi-homing. into a single EVPN VPWS service tunnel and still providing Single-
This new service is referred to as EVPN VPWS flexible cross-connect Active and All-Active multi-homing. This new service is referred to
service. This document specifies a solution based on extensions to as the EVPN VPWS Flexible Cross-Connect (FXC) service. This document
EVPN VPWS(RFC8214) which in turn is based on extensions to EVPN specifies a solution based on extensions to EVPN VPWS (RFC 8214),
(RFC7432). Therefore, a thorough understanding of RFC7432 and which in turn is based on extensions to EVPN (RFC 7432). Therefore,
RFC8214 are prerequisites for this document. a thorough understanding of RFCs 7432 and 8214 are prerequisites for
this document.
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 21 June 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9744.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Requirements
3.1. VPWS Service Identifiers . . . . . . . . . . . . . . . . 7 3. Solution
3.2. Default Flexible Xconnect . . . . . . . . . . . . . . . . 8 3.1. VPWS Service Identifiers
3.2.1. Multi-homing . . . . . . . . . . . . . . . . . . . . 9 3.2. Default Flexible Xconnect
3.3. VLAN-Signaled Flexible Xconnect . . . . . . . . . . . . . 9 3.2.1. Multi-homing
3.3.1. Local Switching . . . . . . . . . . . . . . . . . . . 10 3.3. VLAN-Signaled Flexible Xconnect
3.4. Service Instantiation . . . . . . . . . . . . . . . . . . 11 3.3.1. Local Switching
4. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Service Instantiation
5. Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . 12 4. BGP Extensions
5.1. EVPN VPWS Service Failure . . . . . . . . . . . . . . . . 14 5. Failure Scenarios
5.2. Attachment Circuit Failure . . . . . . . . . . . . . . . 14 5.1. EVPN VPWS Service Failure
5.3. PE Port Failure . . . . . . . . . . . . . . . . . . . . . 15 5.2. Attachment Circuit Failure
5.4. PE Node Failure . . . . . . . . . . . . . . . . . . . . . 15 5.3. PE Port Failure
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5.4. PE Node Failure
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8. References
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.1. Normative References
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Contributors
Authors' Addresses
1. Introduction 1. Introduction
[RFC8214] describes a solution to deliver P2P services using BGP [RFC8214] describes a solution to deliver point-to-point (P2P)
constructs defined in [RFC7432]. It delivers this P2P service services using BGP constructs defined in [RFC7432]. It delivers this
between a pair of Attachment Circuits (ACs), where an AC can P2P service between a pair of Attachment Circuits (ACs), where an AC
designate on a PE, a port, a VLAN on a port, or a group of VLANs on a can designate on a Provider Edge (PE), a port, a VLAN on a port, or a
port. It also leverages multi-homing and fast convergence group of VLANs on a port. It also leverages multi-homing and fast
capabilities of [RFC7432] in delivering these VPWS services. convergence capabilities of [RFC7432] in delivering these VPWS
Multi-homing capabilities include the support of single-active and services. Multi-homing capabilities include the support of single-
all-active redundancy mode and fast convergence is provided using active and all-active redundancy mode, and fast convergence is
"mass withdrawal" message in control-plane and fast protection provided using a "mass withdrawal" message in control plane and fast
switching using prefix independent convergence in data-plane upon protection switching using prefix-independent convergence in a data
node or link failure [I-D.ietf-rtgwg-bgp-pic]. Furthermore, the use plane upon node or link failure [BGP-PIC]. Furthermore, the use of
of EVPN BGP constructs eliminates the need for multi-segment EVPN BGP constructs eliminates the need for multi-segment pseudowire
pseudowire auto-discovery and signaling if the VPWS service need to auto-discovery and signaling if the VPWS service need to span across
span across multiple ASes [RFC5659]. multiple Autonomous Systems (ASes) [RFC5659].
Service providers have very large number of ACs (in millions) that Service providers have a very large number of ACs (in millions) that
need to be backhauled across their MPLS/IP network. These ACs may or need to be backhauled across their MPLS/IP network. These ACs may or
may not require tag manipulation (e.g., VLAN translation). These may not require tag manipulation (e.g., VLAN translation). These
service providers want to multiplex a large number of ACs across service providers want to multiplex a large number of ACs across
several physical interfaces spread across one or more PEs (e.g., several physical interfaces spread across one or more PEs (e.g.,
several Ethernet Segments) onto a single VPWS service tunnel in order several Ethernet Segments) onto a single VPWS service tunnel in order
to a) reduce number of EVPN service labels associated with EVPN-VPWS to a) reduce the number of EVPN service labels associated with EVPN-
service tunnels and thus the associated OAM monitoring, and b) reduce VPWS service tunnels and thus the associated Operations,
EVPN BGP signaling (e.g., not to signal each AC as it is the case in Administration, and Maintenance (OAM) monitoring and b) reduce EVPN
BGP signaling (e.g., not to signal each AC as it is the case in
[RFC8214]). [RFC8214]).
Service providers want the above functionality without sacrificing Service providers want the above functionality without sacrificing
any of the capabilities of [RFC8214] including single- active and any of the capabilities of [RFC8214] including single-active and all-
all-active multi-homing, and fast convergence. active multi-homing and fast convergence.
This document specifies a solution based on extensions to EVPN VPWS This document specifies a solution based on extensions to EVPN VPWS
([RFC8214]) to meet the above requirements. Furthermore, [RFC8214] [RFC8214] to meet the above requirements. Furthermore, [RFC8214] is
is itself based on extensions to EVPN ([RFC7432]). Therefore, a itself based on extensions to EVPN [RFC7432]. Therefore, a thorough
thorough understanding of [RFC7432] and [RFC8214] are prerequisites understanding of [RFC7432] and [RFC8214] are prerequisites for this
for this document. document.
1.1. Terminology 1.1. Terminology
AC: Attachment Circuit AC: Attachment Circuit
ES: Ethernet Segment ES: Ethernet Segment
ESI: Ethernet Segment Identififer ESI: Ethernet Segment Identifier
EVI: EVPN Instance Identifier
EVI: EVPN Instance Identifier
EVPN: Ethernet Virtual Private Network EVPN: Ethernet Virtual Private Network
Ethernet A-D: Ethernet Auto-Discovery (A-D) per EVI and Ethernet A-D Ethernet A-D: Ethernet Auto-Discovery per EVI and Ethernet A-D per
per ESI routes, as defined in [RFC7432] and [RFC8214]. ESI routes, as defined in [RFC7432] and [RFC8214].
FXC: Flexible Cross Connect FXC: Flexible Cross Connect
MAC: Media Access Control MAC: Media Access Control
MPLS: Multi Protocol Label Switching MPLS: Multiprotocol Label Switching
OAM: Operations, Administration and Maintenance OAM: Operations, Administration, and Maintenance
PE: Provider Edge device PE: Provider Edge device
VCCV: Virtual circuit connection verification VCCV: Virtual Circuit Connection Verification
VID: Vlan ID VID: VLAN ID
VPWS: Virtual private wire service VPWS: Virtual Private Wire Service
VRF: VPN Routing and Forwarding table VRF: VPN Routing and Forwarding table
IP-VRF: VPN Routing and Forwarding table, for IP lookup IP-VRF: VPN Routing and Forwarding table, for IP lookup
MAC-VRF: VPN Routing and Forwarding table, for MAC lookup MAC-VRF: VPN Routing and Forwarding table, for MAC lookup
VID-VRF: VPN Routing and Forwarding table, for Normalized VID VID-VRF: VPN Routing and Forwarding table, for Normalized VID lookup
lookup
VPWS Service Tunnel: It is represented by a pair of EVPN service VPWS Service Tunnel: It is represented by a pair of EVPN service
labels associated with a pair of endpoints. Each label is labels associated with a pair of endpoints. Each label is
downstream assigned and advertised by the disposition PE through downstream assigned and advertised by the disposition PE through
an Ethernet Auto-Discovery (A-D) per EVI route. The downstream an Ethernet A-D per EVI route. The downstream label identifies
label identifies the endpoint on the disposition PE. A VPWS the endpoint on the disposition PE. A VPWS service tunnel can be
service tunnel can be associated with many VPWS service associated with many VPWS service identifiers where each
identifiers where each identifier is a normalized VID. identifier is a normalized VID.
Single-Active Redundancy Mode: When a device or a network is Single-Active Redundancy Mode: When a device or a network is multi-
multi-homed to two or more PEs and when only a single PE in such homed to two or more PEs and when only a single PE in such
redundancy group can forward traffic to/from the multi-homed redundancy group can forward traffic to/from the multi-homed
device or network for a given VLAN, then such multi-homing or device or network for a given VLAN, then such multi-homing or
redundancy is referred to as "Single-Active". redundancy is referred to as "Single-Active".
All-Active Redundancy Mode: When a device or a network is All-Active Redundancy Mode: When a device or a network is multi-
multi-homed to two or more PEs and when all PEs in such redundancy homed to two or more PEs and when all PEs in such redundancy group
group can forward traffic to/from the multi-homed device or can forward traffic to/from the multi-homed device or network for
network for a given VLAN, then such multi-homing or redundancy is a given VLAN, then such multi-homing or redundancy is referred to
referred to as "All-Active". 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.
2. Requirements 2. Requirements
Two of the main motivations for service providers seeking a new Two of the main motivations for service providers seeking a new
solution are: 1) to reduce number of VPWS service tunnels by solution are: 1) to reduce the number of VPWS service tunnels by
multiplexing large number of ACs across different physical interfaces multiplexing a large number of ACs across different physical
instead of having one VPWS service tunnel per AC, and 2) to reduce interfaces instead of having one VPWS service tunnel per AC and 2) to
the signaling of ACs as much as possible. Besides these two reduce the signaling of ACs as much as possible. Besides these two
requirements, they also want multi-homing and fast convergence requirements, they also want the multi-homing and fast convergence
capabilities of [RFC8214]. capabilities of [RFC8214].
In [RFC8214], a PE signals an AC indirectly by first associating that In [RFC8214], a PE signals an AC indirectly by first associating that
AC to a VPWS service tunnel (e.g., a VPWS service instance) and then AC to a VPWS service tunnel (e.g., a VPWS service instance) and then
signaling the VPWS service tunnel via a Ethernet A-D per EVI route signaling the VPWS service tunnel via an Ethernet A-D per EVI route
with Ethernet Tag field set to a 24-bit VPWS service instance with the Ethernet Tag field set to a 24-bit VPWS service instance
identifier (which is unique within the EVI) and ESI field set to a identifier (which is unique within the EVI) and the ESI field set to
10-octet identifier of the Ethernet Segment corresponding to that AC. a 10-octet identifier of the Ethernet Segment corresponding to that
AC.
Therefore, a PE device that receives such EVPN routes, can associate Therefore, a PE device that receives such EVPN routes can associate
the VPWS service tunnel to the remote Ethernet Segment using the ESI the VPWS service tunnel to the remote Ethernet Segment using the ESI
field, and when the remote ES fails and the PE receives the "mass field. Additionally, when the remote ES fails and the PE receives
withdrawal" message associated with the failed ES per [RFC7432], it the "mass withdrawal" message associated with the failed ES per
can quickly update its BGP list of available remote entries to [RFC7432], a PE device can quickly update its BGP list of available
invalidate all VPWS service tunnels sharing the ESI field and achieve remote entries to invalidate all VPWS service tunnels sharing the ESI
fast convergence for multi-homing scenarios. Even if fast field and achieve fast convergence for multi-homing scenarios. Even
convergence were not needed, there would still be a need for if fast convergence was not needed, there would still be a need for
signaling each AC failure (via its corresponding VPWS service tunnel) signaling each AC failure (via its corresponding VPWS service tunnel)
associated with the failed ES, so that the BGP path list for each of associated with the failed ES so that the BGP path list for each of
them gets updated accordingly and the packets are sent to backup PE them gets updated accordingly and the packets are sent to a backup PE
(in case of single- active multi-homing) or to other PEs in the (in case of single-active multi-homing) or to other PEs in the
redundancy group (in case of all-active multi-homing). In absence of redundancy group (in case of all-active multi-homing). In the
updating the BGP path list, the traffic for that VPWS service tunnel absence of updating the BGP path list, the traffic for that VPWS
will be black-holed. service tunnel will be black-holed.
When a single VPWS service tunnel carries multiple ACs across various When a single VPWS service tunnel carries multiple ACs across various
Ethernet Segments (physical interfaces) without signaling the ACs via Ethernet Segments (physical interfaces) without signaling the ACs via
EVPN BGP to remote PE devices, those remote PE devices lack the EVPN BGP to remote PE devices, those remote PE devices lack the
information to associate the received Ethernet Segment with these ACs information to associate the received Ethernet Segment with these ACs
or with their local ACs. They also lack the association between the or with their local ACs. They also lack the association between the
VPWS service tunnel (e.g., EVPN service label) and the far-end ACs. VPWS service tunnel (e.g., EVPN service label) and the far-end ACs.
This means that while the remote PEs can associate their local ACs This means that, while the remote PEs can associate their local ACs
with the VPWS service tunnel, they cannot make similar associations with the VPWS service tunnel, they cannot make similar associations
for the far-end ACs. for the far-end ACs.
Consequently, in case of a connectivity failure to the ES, the remote Consequently, in case of a connectivity failure to the ES, the remote
PEs are unable to redirect traffic via another multi-homing PE to PEs are unable to redirect traffic via another multi-homing PE to
that ES. In other words, even if an ES failure is signaled via EVPN that ES. In other words, even if an ES failure is signaled via EVPN
to the remote PE devices, they cannot effectively respond because to the remote PE devices, they cannot effectively respond because
they do not know the relationship between the remote ES, the remote they do not know the relationship between the remote ES, the remote
ACs, and the VPWS service tunnel. ACs, and the VPWS service tunnel.
To address this issue when multiplexing a large number of ACs onto a To address this issue when multiplexing a large number of ACs onto a
single VPWS service tunnel, two mechanisms have been developed: one single VPWS service tunnel, two mechanisms have been developed: one
to support VPWS services between two single-homed endpoints, and to support VPWS services between two single-homed endpoints and
another to support VPWS services where one of the endpoints is multi- another one to support VPWS services where one of the endpoints is
homed. multi-homed.
For single-homed endpoints, it is acceptable not to signal each AC in For single-homed endpoints, it is acceptable not to signal each AC in
BGP because, in the event of a connection failure to the ES, there is BGP because, in the event of a connection failure to the ES, there is
no alternative path to that endpoint. However, the implication of no alternative path to that endpoint. However, the implication of
not signaling an AC failure is that the traffic destined for the not signaling an AC failure is that the traffic destined for the
failed AC is sent over the MPLS/IP core and then discarded at the failed AC is sent over the MPLS/IP core and then discarded at the
destination PE, thereby potentially wasting network resources. destination PE, thereby potentially wasting network resources.
This waste of network resources during a connection failure may be This waste of network resources during a connection failure may be
transient, as it can be detected and prevented at the application transient, as it can be detected and prevented at the application
layer in certain cases. Section 3.2 outlines a solution for such layer in certain cases. Section 3.2 outlines a solution for such
single-homing VPWS services. single-homing VPWS services.
For VPWS services where one of the endpoints is multi-homed, there For VPWS services where one of the endpoints is multi-homed, there
are two options: are two options:
1) to signal each AC via BGP, allowing the path list to be updated 1. Signal each AC via BGP, allowing the path list to be updated upon
upon a failure affecting those ACs. This solution is described in a failure affecting those ACs. This solution is described in
Section 3.3 and is referred to as the VLAN-signaled flexible cross- Section 3.3 and is referred to as the "VLAN-signaled flexible
connect service. cross-connect service".
2) to bundle several ACs on an ES together per destination endpoint 2. Bundle several ACs on an ES together per destination endpoint
(e.g., ES, MAC-VRF, etc.) and associate such a bundle with a single (e.g., ES, MAC-VRF, etc.) and associate such a bundle with a
VPWS service tunnel. This approach is similar to the VLAN-bundle single VPWS service tunnel. This approach is similar to the
service interface described in [RFC8214]. This solution is described VLAN-bundle service interface described in [RFC8214]. This
in Section 3.2.1. solution is described in Section 3.2.1.
3. Solution 3. Solution
This section specifies how to provide a new VPWS service between two This section specifies how to provide a new VPWS service between two
PE devices where a large number of ACs (such as VLANs) that span PE devices where a large number of ACs (such as VLANs) that span
across multiple Ethernet Segments (physical interfaces) on each PE across multiple Ethernet Segments (physical interfaces) on each PE
are multiplexed onto a single P2P EVPN service tunnel. Since the are multiplexed onto a single P2P EVPN service tunnel. Since the
multiplexing involves several physical interfaces, there can be multiplexing involves several physical interfaces, there can be
overlapping VLAN IDs across these interfaces. In such cases, the overlapping VLAN IDs (VIDs) across these interfaces. In such cases,
VLAN IDs (VIDs) must be translated into unique VIDs to prevent the VIDs must be translated into unique VIDs to prevent collisions.
collisions. Furthermore, if the number of VLANs being multiplexed Furthermore, if the number of VLANs being multiplexed onto a single
onto a single VPWS service tunnel exceeds 4095, then a single tag to VPWS service tunnel exceeds 4095, then a single tag to double tag
double tag translation must be performed. This translation of VIDs translation must be performed. This translation of VIDs into unique
into unique VIDs (either single or double) results in a "Normalized VIDs (either single or double) results in a "Normalized VID".
VID".
When a single normalized VID is used, the lower 12 bits of the 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 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 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 ID field MUST be set to the inner VID, while the higher 12 bits are
set to the outer VID. As stated in [RFC8214], 12-bit and 24-bit VPWS set to the outer VID. As stated in [RFC8214], 12-bit and 24-bit VPWS
service instance identifiers representing normalized VIDs MUST be service instance identifiers representing normalized VIDs MUST be
right-aligned. right-aligned.
Since there is only a single EVPN VPWS service tunnel associated with Since there is only a single EVPN VPWS service tunnel associated with
many normalized VIDs (either single or double) across multiple many normalized VIDs (either single or double) across multiple
physical interfaces, an MPLS lookup at the disposition PE is no physical interfaces, an MPLS lookup at the disposition PE is no
longer sufficient to forward the packet to the correct egress longer sufficient to forward the packet to the correct egress
endpoint or interface. Therefore, in addition to an EVPN label endpoint or interface. Therefore, in addition to an EVPN label
lookup corresponding to the VPWS service tunnel, a VID lookup (either lookup corresponding to the VPWS service tunnel, a VID lookup (either
single or double) is also required. At the disposition PE, the EVPN single or double) is also required. At the disposition PE, the EVPN
label lookup identifies a VID-VRF, and the lookup of the normalized label lookup identifies a VID-VRF, and the lookup of the normalized
VID(s) within that table identifies the appropriate egress endpoint VIDs within that table identifies the appropriate egress endpoint or
or interface. The tag manipulation (translation from normalized interface. The tag manipulation (translation from normalized VIDs to
VID(s) to the local VID) SHOULD be performed either as part of the the local VID) SHOULD be performed either as part of the VID table
VID table lookup or at the egress interface itself. lookup or at the egress interface itself.
Since the VID lookup (single or double) needs to be performed at the Since the VID lookup (single or double) needs to be performed at the
disposition PE, VID normalization MUST be completed prior to MPLS disposition PE, VID normalization MUST be completed prior to MPLS
encapsulation on the ingress PE. This requires that both the encapsulation on the ingress PE. This requires that both the
imposition and disposition PE devices be capable of VLAN tag imposition and disposition PE devices be capable of VLAN tag
manipulation, such as rewriting (single or double), addition, or manipulation, such as rewriting (single or double), adding, or
deletion (single or double) at their endpoints (e.g., their ESs, MAC- deleting (single or double) at their endpoints (e.g., their ESs, MAC-
VRFs, IP-VRFs, etc.). Operators should be informed of potential VRFs, IP-VRFs, etc.). Operators should be informed of potential
trade-offs from a performance standpoint, compared to typical trade-offs from a performance standpoint, compared to typical
pseudowire processing. pseudowire processing.
3.1. VPWS Service Identifiers 3.1. VPWS Service Identifiers
In [RFC8214], a unique value identifying the service is signaled in 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 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 be set to this VPWS service instance identifier value. Translation
at an Autonomous System Border Router (ASBR) is needed if re- at an Autonomous System Border Router (ASBR) is needed if re-
advertising to another AS affects uniqueness. advertising to another AS affects uniqueness.
For FXC, this same Ethernet Tag ID field value is an identifier which For FXC, this same Ethernet Tag ID field value is an identifier that
may represent: may represent:
* VLAN-Bundle Service Interface: a unique value for a group of VLANs * VLAN-Bundle Service Interface: a unique value for a group of VLANs
;
* VLAN-Aware Bundle Service Interface : a unique value for * VLAN-Aware Bundle Service Interface: a unique value for individual
individual VLANs, and is considered same as the normalized VID. VLANs and is considered the same as the normalized VID
Both the VPWS service instance identifier and normalized VID are Both the VPWS service instance identifier and normalized VID are
carried in the Ethernet Tag ID field of the Ethernet A-D per EVI 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 route. For FXC, in the case of a 12-bit ID, the VPWS service
identifier is the same as the single-tag normalized VID and will be instance identifier is the same as the single-tag normalized VID and
the same on both VPWS service endpoints. Similarly in the case of a will be the same on both VPWS service endpoints. Similarly in the
24-bit ID, the VPWS service instance identifier is the same as the case of a 24-bit ID, the VPWS service instance identifier is the same
double-tag normalized VID. as the double-tag normalized VID.
3.2. Default Flexible Xconnect 3.2. Default Flexible Xconnect
In this mode of operation, many ACs across several Ethernet Segments In this mode of operation, many ACs across several Ethernet Segments
are multiplexed into a single EVPN VPWS service tunnel represented by are multiplexed into a single EVPN VPWS service tunnel represented by
a single VPWS service ID. This is the default mode of operation for a single VPWS service ID. This is the default mode of operation for
FXC and the participating PEs do not need to signal the VLANs FXC, and the participating PEs do not need to signal the VLANs
(normalized VIDs) in EVPN BGP. (normalized VIDs) in EVPN BGP.
Regarding the data-plane aspects of this solution, the imposition Regarding the data plane aspects of this solution, the imposition PE
Provider Edge (PE) performs VID normalization and the disposition PE performs VID normalization, and the disposition PE carries out VID
carries out VID lookup and translation. Both imposition and lookup and translation. Both imposition and disposition PE devices
disposition PE devices MUST be aware of the VLANs through MUST be aware of the VLANs through configuration. There should
configuration. There should ideally be a single point-to-point (P2P) ideally be a single point-to-point (P2P) EVPN VPWS service tunnel
EVPN VPWS service tunnel between a pair of PEs for a specific set of between a pair of PEs for a specific set of ACs.
Attachment Circuits (ACs).
As previously mentioned, because the EVPN VPWS service tunnel is As previously mentioned, because the EVPN VPWS service tunnel is
employed to multiplex ACs across various Ethernet Segments (ESs) or employed to multiplex ACs across various Ethernet Segments (ESs) or
physical interfaces, the EVPN label alone is not sufficient for physical interfaces, the EVPN label alone is not sufficient for
accurate forwarding of the received packets over the MPLS/IP network accurate forwarding of the received packets over the MPLS/IP network
to egress interfaces. Therefore, normalized VID lookup is REQUIRED to egress interfaces. Therefore, normalized VID lookup is REQUIRED
in the disposition direction to forward packets to their proper in the disposition direction to forward packets to their proper
egress end-points; the EVPN label lookup identifies a VID-VRF, and a egress endpoints; the EVPN label lookup identifies a VID-VRF, and a
subsequent normalized VID lookup in that table identifies the egress subsequent normalized VID lookup in that table identifies the egress
interface. interface.
In this solution, for each PE, the single-homing ACs represented by In this solution, for each PE, the single-homing ACs represented by
their normalized VIDs are associated with a single VPWS service their normalized VIDs are associated with a single VPWS service
instance within a specific EVI. The generated EVPN route is an instance within a specific EVI. The generated EVPN route is an
Ethernet A-D per EVI route with an ESI of 0, and Ethernet Tag field Ethernet A-D per EVI route with an ESI of 0, the Ethernet Tag field
set to the VPWS service instance ID, and the MPLS label field set to is set to a VPWS service instance ID, and the MPLS label field is set
a dynamically generated EVPN service label representing the EVPN VPWS to a dynamically generated EVPN service label representing the EVPN
service tunnel. This route is sent with a Route Target (RT) that VPWS service tunnel. This route is sent with a Route Target (RT)
represents the EVI, which can be auto-generated from the EVI that represents the EVI, which can be auto-generated from the EVI
according to Section 5.1.2.1 of [RFC8365]. Additionally, this route according to Section 5.1.2.1 of [RFC8365]. Additionally, this route
is sent with the EVPN Layer-2 Extended Community defined in is sent with the EVPN Layer 2 Extended Community defined in
Section 3.1 of [RFC8214] with two new flags (outlined in Section 4) Section 3.1 of [RFC8214] with two new flags (outlined in Section 4)
that indicate: 1) this VPWS service tunnel is for the default that indicate: 1) this VPWS service tunnel for the default Flexible
Flexible Cross-Connect, and 2) the normalized VID type (single versus Cross-Connect and 2) the normalized VID type (single versus double).
double). The receiving PE uses these new flags for a consistency The receiving PE uses these new flags for a consistency check and MAY
check and MAY generate an alarm if it detects inconsistencies, but it generate an alarm if it detects inconsistencies, but it will not
will not disrupt the VPWS service. disrupt the VPWS service.
It should be noted that in this mode of operation, a single It should be noted that in this mode of operation, a single Ethernet
Ethernet A-D per EVI route is transmitted upon the configuration of A-D per EVI route is transmitted upon the configuration of the first
the first Attachment Circuit (AC) with the normalized VID. As AC with the normalized VID. As additional ACs are configured and
additional ACs are configured and associated with this EVPN VPWS associated with this EVPN VPWS service tunnel, the PE does not
service tunnel, the PE does not advertise any additional EVPN BGP advertise any additional EVPN BGP routes and only locally associates
routes and only associates locally these ACs with the pre-established these ACs with the pre-established VPWS service tunnel.
VPWS service tunnel.
3.2.1. Multi-homing 3.2.1. Multi-homing
The default FXC mode can also be used for multi-homing. In this The default FXC mode can also be used for multi-homing. In this
mode, a group of normalized VIDs representing ACs on a single mode, a group of normalized VIDs representing ACs on a single
Ethernet Segment, all destined to a single endpoint, are multiplexed Ethernet Segment, all destined to a single endpoint, are multiplexed
into a single EVPN VPWS service tunnel which is identified by a into a single EVPN VPWS service tunnel, which is identified by a
unique VPWS service ID. When employing the default FXC mode for unique VPWS service ID. When employing the default FXC mode for
multi-homing, rather than using a single EVPN VPWS service tunnel multi-homing, rather than using a single EVPN VPWS service tunnel,
there may be multiple service tunnels per pair of PEs. Specifically, 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 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 can be many such groups between a pair of PEs, resulting in numerous
EVPN service tunnels. EVPN service tunnels.
3.3. VLAN-Signaled Flexible Xconnect 3.3. VLAN-Signaled Flexible Xconnect
In this mode of operation, similar to the default FXC mode described In this mode of operation, similar to the default FXC mode described
in Section 3.2, many normalized VIDs representing ACs across several in Section 3.2, many normalized VIDs representing ACs across several
Ethernet Segments/interfaces are multiplexed into a single EVPN VPWS Ethernet Segments and interfaces are multiplexed into a single EVPN
service tunnel. However, this single tunnel is represented by VPWS service tunnel. However, this single tunnel is represented by
multiple VPWS service IDs (one per normalized VID) and these multiple VPWS service IDs (one per normalized VID), and these
normalized VIDs are signaled using EVPN BGP. normalized VIDs are signaled using EVPN BGP.
In this solution, on each PE, the multi-homing ACs represented by In this solution, on each PE, the multi-homing ACs represented by
their normalized VIDs are configured with a single EVI. There is no their normalized VIDs are configured with a single EVI. There is no
need to configure a separate VPWS service instance ID in here, as it need to configure a separate VPWS service instance ID in here, as it
corresponds to the normalized VID. For each normalized VID on each corresponds to the normalized VID. For each normalized VID on each
Ethernet Segment, the PE generates an Ethernet A-D per EVI route Ethernet Segment, the PE generates an Ethernet A-D per EVI route
where the ESI field represents the ES ID, the Ethernet Tag field is where the ESI field represents the ES ID, the Ethernet Tag field is
set to the normalized VID, and the MPLS label field is set to a set to the normalized VID, and the MPLS label field is set to a
dynamically generated EVPN label representing the P2P EVPN service dynamically generated EVPN label representing the P2P EVPN service
tunnel. This label is the same for all ACs multiplexed into a single tunnel. This label is the same for all ACs multiplexed into a single
EVPN VPWS service tunnel. This route is sent with a Route Target EVPN VPWS service tunnel. This route is sent with an RT representing
(RT) representing the EVI. As before, this RT can be auto-generated the EVI. As before, this RT can be auto-generated from the EVI per
from the EVI per section Section 5.1.2.1 of [RFC8365]. Additionally, Section 5.1.2.1 of [RFC8365]. Additionally, this route includes the
this route includes the EVPN Layer-2 Extended Community defined in EVPN Layer 2 Extended Community defined in Section 3.1 of [RFC8214]
Section 3.1 of [RFC8214] with two new flags (outlined in Section 4) with two new flags (outlined in Section 4) that indicate: 1) this
that indicate: 1) this VPWS service tunnel is for VLAN-signaled VPWS service tunnel for VLAN-signaled Flexible Cross-Connect and 2)
Flexible Cross-Connect, and 2) the normalized VID type (single versus the normalized VID type (single versus double). The receiving PE
double). The receiving PE uses these new flags for a consistency uses these new flags for a consistency check and may generate an
check and may generate an alarm if it detects inconsistency, but it alarm if it detects inconsistency, but it will not disrupt the VPWS
will not disrupt the VPWS service. service.
It should be noted that in this mode of operation, the PE sends a It should be noted that in this mode of operation, the PE sends a
single Ethernet A-D per EVI route for each AC that is configured. single Ethernet A-D per EVI route for each AC that is configured.
Each normalized VID that is configured per ES results in generation Each normalized VID that is configured per ES results in generation
of an Ethernet A-D per EVI. of an Ethernet A-D per EVI.
This mode of operation enabled automatic cross-checking of normalized This mode of operation enabled automatic cross-checking of normalized
VIDs used for Ethernet Virtual Private Line (EVPL) services because VIDs used for Ethernet Virtual Private Line (EVPL) services because
these VIDs are signaled in EVPN BGP. For instance, if the same these VIDs are signaled in EVPN BGP. For instance, if the same
normalized VID is configured on three PE devices (instead of two) for normalized VID is configured on three PE devices (instead of two) for
skipping to change at page 11, line 7 skipping to change at line 471
receiving PE processes an Ethernet A-D per EVI route whose ESI is a receiving PE processes an Ethernet A-D per EVI route whose ESI is a
local ESI, the PE does not modify its forwarding state based on the local ESI, the PE does not modify its forwarding state based on the
received route. This approach ensures that local switching takes received route. This approach ensures that local switching takes
precedence over forwarding via the MPLS/IP network. This method of precedence over forwarding via the MPLS/IP network. This method of
prioritizing locally switched traffic aligns with the baseline EVPN prioritizing locally switched traffic aligns with the baseline EVPN
principles described in [RFC7432], where locally switched preference principles described in [RFC7432], where locally switched preference
is specified for MAC/IP routes. is specified for MAC/IP routes.
In such scenarios, the Ethernet A-D per EVI route should be In such scenarios, the Ethernet A-D per EVI route should be
advertised with the MPLS label either associated with the destination advertised with the MPLS label either associated with the destination
Attachment Circuit or with the destination Ethernet Segment in order AC or with the destination Ethernet Segment in order to avoid any
to avoid any ambiguity in forwarding. In other words, the MPLS label ambiguity in forwarding. In other words, the MPLS label cannot
cannot represent the same VID-VRF outlined in Section 3.3, as the represent the same VID-VRF outlined in Section 3.3, as the same
same normalized VID can be reachable via two Ethernet Segments. In normalized VID can be reachable via two Ethernet Segments. In the
the case of using an MPLS label per destination AC, this approach can case of using an MPLS label per destination AC, this approach can
also be applied to VLAN-based VPWS or VLAN-bundle VPWS services as also be applied to VLAN-based VPWS or VLAN-bundle VPWS services as
per [RFC8214]. per [RFC8214].
3.4. Service Instantiation 3.4. Service Instantiation
The V field defined in Section 4 is OPTIONAL. However, if The V field defined in Section 4 is OPTIONAL. However, if
transmitted, its value may indicate an error condition that could transmitted, its value may indicate an error condition that could
lead to operational issues. In such cases, merely notifying the lead to operational issues. In such cases, merely notifying the
operator of an error is insufficient; the VPWS service tunnel must operator of an error is insufficient; the VPWS service tunnel must
not be established. not be established.
If both endpoints of a VPWS tunnel are signaling a matching If both endpoints of a VPWS tunnel are signaling a matching
Normalised VID in the control plane, but one is operating in single- Normalized VID in the control plane, but one is operating in single-
tag mode and the other in double-tag mode, the signaling of the V-bit tag mode and the other in double-tag mode, then the signaling of the
facilitates the detection and prevention of this tunnel's V-bit facilitates the detection and prevention of this tunnel's
instantiation. instantiation.
If single VID normalization is signaled in the Ethernet Tag ID field If single VID normalization is signaled in the Ethernet Tag ID field
(12 bits) yet dataplane is operating based on double tags, the VID (12 bits), yet the data plane is operating based on double tags, the
normalization applies only to outer tag. Conversely, if double VID VID normalization applies only to the outer tag. Conversely, if
normalization is signaled in the Ethernet Tag ID field (24 bits), VID double VID normalization is signaled in the Ethernet Tag ID field (24
normalization applies to both the inner and outer tags. bits), VID normalization applies to both the inner and outer tags.
4. BGP Extensions 4. BGP Extensions
This draft uses the EVPN Layer-2 attribute extended community as This document uses the EVPN Layer 2 attribute extended community as
defined in [RFC8214] with two additional flags incorporated into this defined in [RFC8214] with two additional flags incorporated into this
Extended Community (EC) as detailed below. This EC is sent with Extended Community (EC) as detailed below. This EC is sent with
Ethernet A-D per EVI route per Section 3, and SHOULD be sent for both Ethernet A-D per EVI route per Section 3 and SHOULD be sent for both
Single-Active and All-Active redundancy modes. Single-Active and All-Active redundancy modes.
+-------------------------------------------+ +-------------------------------------------+
| Type (0x06) / Sub-type (0x04) (2 octets) | | Type (0x06) / Sub-type (0x04) (2 octets) |
+-------------------------------------------+ +-------------------------------------------+
| Control Flags (2 octets) | | Control Flags (2 octets) |
+-------------------------------------------+ +-------------------------------------------+
| L2 MTU (2 octets) | | L2 MTU (2 octets) |
+-------------------------------------------+ +-------------------------------------------+
| Reserved (2 octets) | | Reserved (2 octets) |
skipping to change at page 12, line 25 skipping to change at line 527
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 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) | MBZ | V | M | |C|P|B| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bits in the Control Flags are defined; the remaining The following bits in the Control Flags are defined; the remaining
bits MUST be set to zero when sending and MUST be ignored when bits MUST be set to zero when sending and MUST be ignored when
receiving this community. receiving this community.
Name Meaning +=======+==============================================+
--------------------------------------------------------------- | Name | Meaning |
B,P,C per definition in [RFC8214] +=======+==============================================+
| B,P,C | per definition in [RFC8214] |
M 00 mode of operation as defined in [RFC8214] +-------+----------------------------------------------+
01 VLAN-Signaled FXC | M | 00 mode of operation as defined in [RFC8214] |
10 Default FXC | +----------------------------------------------+
| | 01 VLAN-Signaled FXC |
| +----------------------------------------------+
| | 10 Default FXC |
+-------+----------------------------------------------+
| V | 00 operating per [RFC8214] |
| +----------------------------------------------+
| | 01 single-VID normalization |
| +----------------------------------------------+
| | 10 double-VID normalization |
+-------+----------------------------------------------+
V 00 operating per [RFC8214] Table 1
01 single-VID normalization
10 double-VID normalization
The M and V fields are OPTIONAL. The M field is ignored at reception The M and V fields are OPTIONAL. The M field is ignored at reception
for forwarding purposes and is used for error notifications. for forwarding purposes and is used for error notifications.
5. Failure Scenarios 5. Failure Scenarios
Two examples will be used as an example to analyze the failure The two following examples analyze the failure scenarios.
scenarios.
The first scenario is a default Flexible Xconnect with Multi-Homing The first scenario is a default Flexible Xconnect with a multi-homing
solution and it is depicted in Figure 1. In this case, VID solution, and it is depicted in Figure 1. In this case, VID
Normalization is performed and a single Ethernet A-D per EVI route is normalization is performed, and a single Ethernet A-D per EVI route
sent for the bundle of ACs on an ES. That is, PE1 will advertise two is sent for the bundle of ACs on an ES. That is, PE1 will advertise
Ethernet A-D per EVI routes: the first one will identify the ACs on two Ethernet A-D per EVI routes: The first one will identify the ACs
port p1's ES and the second one will identify the AC2 in port p2's on port p1's ES, and the second one will identify the AC2 in port
ES. Similarly, PE2 will advertise two Ethernet A-D per EVI routes. p2's ES. Similarly, PE2 will advertise two Ethernet A-D per EVI
routes.
N.VID 1,2,3 +---------------------+ N.VID 1,2,3 +---------------------+
PE1 | | PE1 | |
+---------+ IP/MPLS | +---------+ IP/MPLS |
+-----+ VID1 p1 | +-----+ | sv.T1 + +-----+ VID1 p1 | +-----+ | sv.T1 +
| CE1 |-------------| FXC |======+ PE3 +-----+ | CE1 |-------------| FXC |======+ PE3 +-----+
| | /\ | | | | \ +----------+ +--| CE3 | | | /\ | | | | \ +----------+ +--| CE3 |
+-----+\ +||---| | sv.T2 \ | | 1/ | | +-----+\ +||---| | sv.T2 \ | | 1/ | |
VID3\ / ||---| |=====+ \ | +-----+ | / +-----+ VID3\ / ||---| |=====+ \ | +-----+ | / +-----+
\ // \/ | +-----+ | \ +====| FXC |----+ \ // \/ | +-----+ | \ +====| FXC |----+
skipping to change at page 13, line 37 skipping to change at line 587
+-----+ / /\ | | | | / | +-----+ |\3 +-----+ +-----+ / /\ | | | | / | +-----+ |\3 +-----+
| CE2 |-----||---| | | sv.T4 / | | \ | CE5 | | CE2 |-----||---| | | sv.T4 / | | \ | CE5 |
| |-----||---| | |======+ +----------+ +---| | | |-----||---| | |======+ +----------+ +---| |
+--VIDs3,4 \/ | +-----+ | | +-----+ +--VIDs3,4 \/ | +-----+ | | +-----+
p4 +---------+ | p4 +---------+ |
PE2 | | PE2 | |
N.VID 1,2,3 +-------------------+ N.VID 1,2,3 +-------------------+
Figure 1: Default Flexible Xconnect Figure 1: Default Flexible Xconnect
The second scenario, depicted in Figure 2, illustrates the The second scenario, depicted in Figure 2, illustrates the VLAN-
VLAN-signaled FXC mode with Multi-Homing. In this example: signaled FXC mode with multi-homing. In this example:
* CE1 is connected to PE1 and PE2 via (port,VID)=(p1,1) and (p3,3), * 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, 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. 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: * 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 - The combinations (p2,1) and (p4,3) identify the ACs used to
cross-connect CE2 to CE4's VID 2, and are normalized to cross-connect CE2 to CE4's VID 2 and are normalized to value 2.
value 2.
- The combinations (p2,2) and (p4,4) identify the ACs used to - The combinations (p2,2) and (p4,4) identify the ACs used to
cross-connect CE2 to CE5's VID 3, and are normalized to cross-connect CE2 to CE5's VID 3 and are normalized to value 3.
value 3.
In this scenario, PE1 and PE2 advertise an Ethernet A-D per EVI route In this scenario, PE1 and PE2 advertise an Ethernet A-D per EVI route
for each normalized VID (values 1, 2 and 3). However, only two VPWS for each normalized VID (values 1, 2, and 3). However, only two VPWS
Service Tunnels are required: VPWS Service Tunnel 1 (sv.T1) between service tunnels are required: 1) VPWS Service Tunnel 1 (sv.T1)
PE1's FXC service and PE3's FXC, and VPWS Service Tunnel 2 (sv.T2) between PE1's FXC service and PE3's FXC and 2) VPWS Service Tunnel 2
between PE2's FXC and PE3's FXC. (sv.T2) between PE2's FXC and PE3's FXC.
N.VID 1,2,3 +---------------------+ N.VID 1,2,3 +---------------------+
PE1 | | PE1 | |
+---------+ IP/MPLS | +---------+ IP/MPLS |
+-----+ VID1 p1 | +-----+ | + +-----+ VID1 p1 | +-----+ | +
| CE1 |------------| FXC | | sv.T1 PE3 +-----+ | CE1 |------------| FXC | | sv.T1 PE3 +-----+
| | /\ | | |=======+ +----------+ +--| CE3 | | | /\ | | |=======+ +----------+ +--| CE3 |
+-----+\ +||---| | | \ | | 1/ | | +-----+\ +||---| | | \ | | 1/ | |
VID3\ / ||---| | | \ | +-----+ | / +-----+ VID3\ / ||---| | | \ | +-----+ | / +-----+
\ / /\/ | +-----+ | +=====| FXC |----+ \ / /\/ | +-----+ | +=====| FXC |----+
skipping to change at page 14, line 43 skipping to change at line 636
VIDs3,4 p4 +---------+ | VIDs3,4 p4 +---------+ |
PE2 | | PE2 | |
N.VID 1,2,3 +------------------+ N.VID 1,2,3 +------------------+
Figure 2: VLAN-Signaled Flexible Xconnect Figure 2: VLAN-Signaled Flexible Xconnect
5.1. EVPN VPWS Service Failure 5.1. EVPN VPWS Service Failure
The failure detection of an EVPN VPWS service can be performed via The failure detection of an EVPN VPWS service can be performed via
OAM mechanisms such as VCCV-BFD (Bidirectional Forwarding Detection OAM mechanisms such as VCCV-BFD (Bidirectional Forwarding Detection
for the Pseudowire Virtual Circuit Connectivity Verification, for the Pseudowire Virtual Circuit Connectivity Verification)
[RFC5885]) and upon such failure detection, the switch over procedure [RFC5885], and upon such failure detection, the switchover procedure
to the backup S-PE is the same as the one described above. to the backup Switching Provider Edge (S-PE) is the same as the one
described above.
5.2. Attachment Circuit Failure 5.2. Attachment Circuit Failure
In the event of an AC failure, the VLAN-Signaled and default FXC In the event of an AC failure, the VLAN-Signaled and default FXC
modes exhibit distinct behaviors: modes exhibit distinct behaviors:
* Default FXC (Figure 1): in the default mode, a VLAN or AC failure * Default FXC (Figure 1): In the default mode, a VLAN or AC failure
is not signaled. Consequently, in case of an AC failure such as is not signaled. Consequently, in case of an AC failure, such as
VID1 on CE2, there is nothing to prevent PE3 from directing VID1 on CE2, there is nothing to prevent PE3 from directing
traffic from CE4 to PE1, leading to a potential black hole. traffic from CE4 to PE1, leading to a potential black hole.
Application layer Operations, Administration, and Maintenance Application layer OAM may be utilized if per-VLAN fault
(OAM) may be utilized if per-VLAN fault propagation is necessary propagation is necessary in this scenario.
in this scenario.
* VLAN-Signaled FXC (Figure 2): in the case of a VLAN or AC failure * VLAN-Signaled FXC (Figure 2): In the case of a VLAN or AC failure,
such as VID1 on CE2, triggers the withdrawal of the Ethernet A-D such as VID1 on CE2, this triggers the withdrawal of the Ethernet
per EVI route for the corresponding Normalized VID, specifically A-D per EVI route for the corresponding Normalized VID,
Ethernet-Tag 2. Upon receiving the route withdrawal, PE3 will specifically Ethernet-Tag 2. Upon receiving the route withdrawal,
remove PE1 from its outgoing path list for traffic originating PE3 will remove PE1 from its outgoing path list for traffic
from CE4. originating from CE4.
5.3. PE Port Failure 5.3. PE Port Failure
In the event of a PE port failure, the failure will be signaled, and In the event of a PE port failure, the failure will be signaled, and
the other PE will assume forwarding in both scenarios: the other PE will assume forwarding in both scenarios:
* Default FXC (Figure 1): In the case of a port failure, such as p2, * Default FXC (Figure 1): In the case of a port failure, such as p2,
the route for Service Tunnel 2 (sv.T2) will be withdrawn. Upon the route for Service Tunnel 2 (sv.T2) will be withdrawn. Upon
receiving the fault notification, PE3 will remove PE1 from its receiving the fault notification, PE3 will remove PE1 from its
path list for traffic originating from CE4 and CE5. path list for traffic originating from CE4 and CE5.
skipping to change at page 15, line 41 skipping to change at line 681
the withdrawal of the Ethernet A-D per EVI routes for Normalized the withdrawal of the Ethernet A-D per EVI routes for Normalized
VIDs 2 and 3, along with the withdrawal of the Ethernet A-D per ES VIDs 2 and 3, along with the withdrawal of the Ethernet A-D per ES
route for p2's ES. Upon receiving the fault notification, PE3 route for p2's ES. Upon receiving the fault notification, PE3
will remove PE1 from its path list for the traffic originating will remove PE1 from its path list for the traffic originating
from CE4 and CE5. from CE4 and CE5.
5.4. PE Node Failure 5.4. PE Node Failure
In the case of PE node failure, the operation is similar to the steps In the case of PE node failure, the operation is similar to the steps
described above, albeit that EVPN route withdrawals are performed by described above, albeit that EVPN route withdrawals are performed by
the Route Reflector instead of the PE. the route reflector instead of the PE.
6. Security Considerations 6. Security Considerations
Since this document describes a muxing capability which leverages Since this document describes a muxing capability that leverages
EVPN-VPWS signaling, no additional functionality beyond the muxing EVPN-VPWS signaling, no additional functionality beyond the muxing
service is added and thus no additional security considerations are service is added, and thus no additional security considerations are
needed beyond what is already specified in [RFC8214]. needed beyond what is already specified in [RFC8214].
7. IANA Considerations 7. IANA Considerations
This document requests allocation of bits 8-11 in the "EVPN Layer 2 This document has allocated bits 8-11 in the "EVPN Layer 2 Attributes
Attributes Control Flags" registry with names M and V: Control Flags" registry with names M and V:
M Signaling mode of operation (bits 10-11) M Signaling mode of operation (bits 10-11)
V VLAN-ID normalization (bits 8-9) V VLAN-ID normalization (bits 8-9)
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 16, line 38 skipping to change at line 723
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>. <https://www.rfc-editor.org/info/rfc8214>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-rtgwg-bgp-pic] [BGP-PIC] Bashandy, A., Ed., Filsfils, C., and P. Mohapatra, "BGP
Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix Prefix Independent Convergence", Work in Progress,
Independent Convergence", Work in Progress, Internet- Internet-Draft, draft-ietf-rtgwg-bgp-pic-21, 7 July 2024,
Draft, draft-ietf-rtgwg-bgp-pic-21, 7 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg- <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
bgp-pic-21>. bgp-pic-21>.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
DOI 10.17487/RFC5659, October 2009, DOI 10.17487/RFC5659, October 2009,
<https://www.rfc-editor.org/info/rfc5659>. <https://www.rfc-editor.org/info/rfc5659>.
[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
Forwarding Detection (BFD) for the Pseudowire Virtual Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)", RFC 5885, Circuit Connectivity Verification (VCCV)", RFC 5885,
DOI 10.17487/RFC5885, June 2010, DOI 10.17487/RFC5885, June 2010,
<https://www.rfc-editor.org/info/rfc5885>. <https://www.rfc-editor.org/info/rfc5885>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018, DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>. <https://www.rfc-editor.org/info/rfc8365>.
Appendix A. Contributors Contributors
In addition to the authors listed on the front page, the following In addition to the authors listed on the front page, the following
co-authors have also contributed substantially to this document: co-authors have also contributed substantially to this document:
Wen Lin Wen Lin
Juniper Networks Juniper Networks
Email: wlin@juniper.net
EMail: wlin@juniper.net
Luc Andre Burdet Luc Andre Burdet
Cisco Cisco
Email: lburdet@cisco.com
EMail: lburdet@cisco.com
Authors' Addresses Authors' Addresses
Ali Sajassi (editor) Ali Sajassi (editor)
Cisco Systems Cisco Systems
Email: sajassi@cisco.com Email: sajassi@cisco.com
Patrice Brissette Patrice Brissette
Cisco Systems Cisco Systems
Email: pbrisset@cisco.com Email: pbrisset@cisco.com
 End of changes. 91 change blocks. 
294 lines changed or deleted 297 lines changed or added

This html diff was produced by rfcdiff 1.48.