rfc9744v1.txt		rfc9744.txt
	Internet Engineering Task Force (IETF) A. Sajassi, Ed.		Internet Engineering Task Force (IETF) A. Sajassi, Ed.
	Request for Comments: 9744 P. Brissette		Request for Comments: 9744 P. Brissette
	Category: Standards Track Cisco Systems		Category: Standards Track Cisco Systems
	ISSN: 2070-1721 J. Uttaro		ISSN: 2070-1721 J. Uttaro
	AT&T		Individual
	J. Drake		J. Drake
	Juniper Networks		Independent
	S. Boutros		S. Boutros
	Ciena		Ciena
	J. Rabadan		J. Rabadan
	Nokia		Nokia
	February 2025		February 2025
	EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC)		EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC)
	Service		Service
	Abstract		Abstract
	This document describes a new EVPN Virtual Private Wire Service		This document describes a new EVPN Virtual Private Wire Service
	(VPWS) service type specifically for multiplexing multiple attachment		(VPWS) service type specifically for multiplexing multiple attachment
	circuits across different Ethernet Segments and physical interfaces		circuits across different Ethernet Segments (ESs) and physical
	into a single EVPN VPWS service tunnel and still providing Single-		interfaces into a single EVPN-VPWS service tunnel and still providing
	Active and All-Active multi-homing. This new service is referred to		Single-Active and All-Active multi-homing. This new service is
	as the EVPN VPWS Flexible Cross-Connect (FXC) service. This document		referred to as the EVPN-VPWS Flexible Cross-Connect (FXC) service.
	specifies a solution based on extensions to EVPN VPWS (RFC 8214),		This document specifies a solution based on extensions to EVPN-VPWS
	which in turn is based on extensions to EVPN (RFC 7432). Therefore,		(RFC 8214), which in turn is based on extensions to EVPN (RFC 7432).
	a thorough understanding of RFCs 7432 and 8214 are prerequisites for		Therefore, a thorough understanding of RFCs 7432 and 8214 are
	this document.		prerequisites for this document.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 68 ¶		skipping to change at line 68 ¶
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. Terminology		1.1. Terminology
	1.2. Requirements Language		1.2. Requirements Language
	2. Requirements		2. Requirements
	3. Solution		3. Solution
	3.1. VPWS Service Identifiers		3.1. VPWS Service Identifiers
	3.2. Default Flexible Xconnect		3.2. Default Flexible Cross-Connect
	3.2.1. Multi-homing		3.2.1. Multi-homing
	3.3. VLAN-Signaled Flexible Xconnect		3.3. VLAN-Signaled FXC
	3.3.1. Local Switching		3.3.1. Local Switching
	3.4. Service Instantiation		3.4. Service Instantiation
	4. BGP Extensions		4. BGP Extensions
	5. Failure Scenarios		5. Failure Scenarios
	5.1. EVPN VPWS Service Failure		5.1. EVPN-VPWS Service Failure
	5.2. Attachment Circuit Failure		5.2. Attachment Circuit Failure
	5.3. PE Port Failure		5.3. PE Port Failure
	5.4. PE Node Failure		5.4. PE Node Failure
	6. Security Considerations		6. Security Considerations
	7. IANA Considerations		7. IANA Considerations
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	8.2. Informative References		8.2. Informative References
	Contributors		Contributors
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	[RFC8214] describes a solution to deliver point-to-point (P2P)		[RFC8214] describes a solution to deliver point-to-point (P2P)
	services using BGP constructs defined in [RFC7432]. It delivers this		services using BGP constructs defined in [RFC7432]. It delivers this
	P2P service between a pair of Attachment Circuits (ACs), where an AC		P2P service between a pair of Attachment Circuits (ACs), where an AC
	can designate on a Provider Edge (PE), a port, a VLAN on a port, or a		on a PE can represent a port, a VLAN on a port, or a group of VLANs
	group of VLANs on a port. It also leverages multi-homing and fast		on a port. It also leverages multi-homing and fast convergence
	convergence capabilities of [RFC7432] in delivering these VPWS		capabilities of [RFC7432] in delivering these VPWS services. Multi-
	services. Multi-homing capabilities include the support of single-		homing capabilities include the support of Single-Active and All-
	active and all-active redundancy mode, and fast convergence is		Active redundancy mode, and fast convergence is provided using a
	provided using a "mass withdrawal" message in control plane and fast		"mass withdrawal" message in control plane and fast protection
	protection switching using prefix-independent convergence in a data		switching using prefix-independent convergence in a data plane upon
	plane upon node or link failure [BGP-PIC]. Furthermore, the use of		node or link failure [BGP-PIC]. Furthermore, the use of EVPN BGP
	EVPN BGP constructs eliminates the need for multi-segment pseudowire		constructs eliminates the need for multi-segment pseudowire auto-
	auto-discovery and signaling if the VPWS service need to span across		discovery and signaling if the VPWS service need to span across
	multiple Autonomous Systems (ASes) [RFC5659].		multiple Autonomous Systems (ASes) [RFC5659].
	Service providers have a 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 ESs) onto a single VPWS service tunnel in order to a) reduce
	to a) reduce the number of EVPN service labels associated with EVPN-		the number of EVPN service labels associated with EVPN-VPWS service
	VPWS service tunnels and thus the associated Operations,		tunnels and thus the associated Operations, Administration, and
	Administration, and Maintenance (OAM) monitoring and b) reduce EVPN		Maintenance (OAM) monitoring and b) reduce EVPN BGP signaling (e.g.,
	BGP signaling (e.g., not to signal each AC as it is the case in		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 all-		any of the capabilities of [RFC8214] including Single-Active and 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] is		[RFC8214] to meet the above requirements. Furthermore, [RFC8214] is
	itself based on extensions to EVPN [RFC7432]. Therefore, a thorough		itself based on extensions to EVPN [RFC7432]. Therefore, a thorough
	understanding of [RFC7432] and [RFC8214] are prerequisites for this		understanding of [RFC7432] and [RFC8214] are prerequisites 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 Identifier		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 per EVI and Ethernet A-D per		Ethernet A-D: Ethernet Auto-Discovery (per EVI or per Ethernet A-D
	ESI routes, as defined in [RFC7432] and [RFC8214].		per 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: Multiprotocol Label Switching		MPLS: Multiprotocol Label Switching
	OAM: Operations, Administration, and Maintenance		OAM: Operations, Administration, and Maintenance
	PE: Provider Edge device		PE: Provider Edge
	VCCV: Virtual Circuit Connection Verification		VCCV: Virtual Circuit Connectivity 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
	IP-VRF: VPN Routing and Forwarding table, for IP lookup		IP-VRF: VPN Routing and Forwarding for IP lookup
	MAC-VRF: VPN Routing and Forwarding table, for MAC lookup		MAC-VRF: VPN Routing and Forwarding for MAC lookup
	VID-VRF: VPN Routing and Forwarding table, for Normalized VID lookup		VID-VRF: VPN Routing and Forwarding for normalized VID 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 A-D per EVI route. The downstream label identifies		an Ethernet A-D per EVI route. The downstream label identifies
	the endpoint on the disposition PE. A VPWS service tunnel can be		the endpoint on the disposition PE. A VPWS service tunnel can be
	associated with many VPWS service identifiers where each		associated with many VPWS service identifiers where each
	identifier is a normalized VID.		identifier is a normalized VID.
	Single-Active Redundancy Mode: When a device or a network is multi-		Single-Active Redundancy Mode: When a device or a network is multi-
	skipping to change at line 208 ¶		skipping to change at line 207 ¶
	interfaces instead of having one VPWS service tunnel per AC and 2) to		interfaces instead of having one VPWS service tunnel per AC and 2) to
	reduce 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 the 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 an Ethernet A-D per EVI route		signaling the VPWS service tunnel via an Ethernet A-D per EVI route
	with the 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 the ESI field set to		identifier (which is unique within the EVI) and the ESI field set to
	a 10-octet identifier of the Ethernet Segment corresponding to that		a 10-octet identifier of the ES corresponding to that AC.
	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 ES using the ESI field.
	field. Additionally, when the remote ES fails and the PE receives		Additionally, when the remote ES fails and the PE receives the "mass
	the "mass withdrawal" message associated with the failed ES per		withdrawal" message associated with the failed ES per [RFC7432], a PE
	[RFC7432], a PE device can quickly update its BGP list of available		device can quickly update its next-hop adjacency list (adjacency
	remote entries to invalidate all VPWS service tunnels sharing the ESI		list) for all VPWS service tunnels sharing the ESI field and achieve
	field and achieve fast convergence for multi-homing scenarios. Even		fast convergence for multi-homing scenarios. Even if fast
	if fast convergence was not needed, there would still be a need for		convergence were 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 adjacency list gets updated
	them gets updated accordingly and the packets are sent to a backup PE		and the packets are sent to a backup PE (in case of Single-Active
	(in case of single-active multi-homing) or to other PEs in the		multi-homing) or to other PEs in the redundancy group (in case of
	redundancy group (in case of all-active multi-homing). In the		All-Active multi-homing). In the absence of updating the adjacency
	absence of updating the BGP path list, the traffic for that VPWS		list properly, the traffic for that VPWS service tunnel will be
	service tunnel will be black-holed.		dropped by the egress PE with a failed ES/AC.
	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		ESs (physical interfaces) without signaling the ACs via EVPN BGP to
	EVPN BGP to remote PE devices, those remote PE devices lack the		remote PE devices, those remote PE devices lack the information to
	information to associate the received Ethernet Segment with these ACs		associate the received ES with these ACs or with their local ACs.
	or with their local ACs. They also lack the association between the		They also lack the association between the VPWS service tunnel (e.g.,
	VPWS service tunnel (e.g., EVPN service label) and the far-end ACs.		EVPN service label) and the far-end ACs. This means that, while the
	This means that, while the remote PEs can associate their local ACs		remote PEs can associate their local ACs with the VPWS service
	with the VPWS service tunnel, they cannot make similar associations		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
	skipping to change at line 265 ¶		skipping to change at line 262 ¶
	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. Signal each AC via BGP, allowing the path list to be updated upon		1. Signal each AC via BGP, allowing the adjacency list to be updated
	a failure affecting those ACs. This solution is described in		upon a failure affecting those ACs. This solution is described
	Section 3.3 and is referred to as the "VLAN-signaled flexible		in Section 3.3 and is referred to as the "VLAN-signaled FXC
	cross-connect service".		service".
	2. 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		(e.g., ES, MAC-VRF, etc.) and associate such a bundle with a
	single VPWS service tunnel. This approach is similar to the		single VPWS service tunnel. This approach is similar to the VLAN
	VLAN-bundle service interface described in [RFC8214]. This		bundle service interface described in [RFC8214]. This solution
	solution is described in Section 3.2.1.		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 ESs (physical interfaces) on each PE are multiplexed
	are multiplexed onto a single P2P EVPN service tunnel. Since the		onto a single P2P EVPN service tunnel. Since the multiplexing
	multiplexing involves several physical interfaces, there can be		involves several physical interfaces, there can be overlapping VLAN
	overlapping VLAN IDs (VIDs) across these interfaces. In such cases,		IDs (VIDs) across these interfaces. In such cases, the VIDs must be
	the VIDs must be translated into unique VIDs to prevent collisions.		translated into unique VIDs to prevent collisions. Furthermore, if
	Furthermore, if the number of VLANs being multiplexed onto a single		the number of VLANs being multiplexed onto a single VPWS service
	VPWS service tunnel exceeds 4095, then a single tag to double tag		tunnel exceeds 4095, then a single tag to double tag translation must
	translation must be performed. This translation of VIDs into unique		be performed. This translation of VIDs into unique VIDs (either
	VIDs (either single or double) results in a "Normalized VID".		single or double) results in a "normalized 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. 24-bit VPWS service instance identifiers
	service instance identifiers representing normalized VIDs MUST be		[RFC8214] as well as 12-bit VPWS service instance identifiers
	right-aligned.		representing normalized VIDs MUST be 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
	VIDs within that table identifies the appropriate egress endpoint or		VIDs within that table identifies the appropriate egress endpoint or
	interface. The tag manipulation (translation from normalized VIDs to		interface. The tag manipulation (translation from normalized VIDs to
	the local VID) SHOULD be performed either as part of the VID table		the local VID) SHOULD be performed either as part of the VID table
	skipping to change at line 332 ¶		skipping to change at line 329 ¶
	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 that		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 individual		* VLAN-Aware Bundle Service Interface: a unique value for individual
	VLANs and is considered the 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		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		instance identifier is the same as the single-tag normalized VID and
	will be the same on both VPWS service endpoints. Similarly in the		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		case of a 24-bit ID, the VPWS service instance identifier is the same
	as the double-tag normalized VID.		as the double-tag normalized VID.
	3.2. Default Flexible Xconnect		3.2. Default Flexible Cross-Connect
	In this mode of operation, many ACs across several Ethernet Segments		In this mode of operation, many ACs across several ESs are
	are multiplexed into a single EVPN VPWS service tunnel represented by		multiplexed into a single EVPN-VPWS service tunnel represented by a
	a single VPWS service ID. This is the default mode of operation for		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 PE		Regarding the data plane aspects of this solution, the imposition PE
	performs VID normalization, and the disposition PE carries out VID		performs VID normalization, and the disposition PE carries out VID
	lookup and translation. Both imposition and disposition PE devices		lookup and translation. Both imposition and disposition PE devices
	MUST be aware of the VLANs through configuration. There should		MUST be aware of the VLANs through configuration. There should
	ideally be a single point-to-point (P2P) EVPN VPWS service tunnel		ideally be a single point-to-point (P2P) EVPN-VPWS service tunnel
	between a pair of PEs for a specific set of ACs.		between a pair of PEs for a specific set of 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 ESs or physical interfaces,
	physical interfaces, the EVPN label alone is not sufficient for		the EVPN label alone is not sufficient for accurate forwarding of the
	accurate forwarding of the received packets over the MPLS/IP network		received packets over the MPLS/IP network to egress interfaces.
	to egress interfaces. Therefore, normalized VID lookup is REQUIRED		Therefore, normalized VID lookup is REQUIRED in the disposition
	in the disposition direction to forward packets to their proper		direction to forward packets to their proper egress endpoints; the
	egress endpoints; the EVPN label lookup identifies a VID-VRF, and a		EVPN label lookup identifies a VID-VRF, and a subsequent normalized
	subsequent normalized VID lookup in that table identifies the egress		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, the Ethernet Tag field		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		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		to a dynamically generated EVPN service label representing the EVPN-
	VPWS service tunnel. This route is sent with a Route Target (RT)		VPWS service tunnel. This route is sent with a Route Target (RT)
	that 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 Attributes Extended Community defined
	Section 3.1 of [RFC8214] with two new flags (outlined in Section 4)		in Section 3.1 of [RFC8214] with two new flags (outlined in
	that indicate: 1) this VPWS service tunnel for the default Flexible		Section 4) that indicate: 1) the VPW service tunnel (set to default
	Cross-Connect and 2) the normalized VID type (single versus double).		Flexible Cross-Connect) and 2) the normalized VID type (set to
	The receiving PE uses these new flags for a consistency check and MAY		normalized single VID or double VID). The receiving PE uses these
	generate an alarm if it detects inconsistencies, but it will not		new flags for a consistency check and MAY generate an alarm if it
	disrupt the VPWS service.		detects inconsistencies, but it will not disrupt the VPWS service.
	It should be noted that in this mode of operation, a single Ethernet		It should be noted that in this mode of operation, a single Ethernet
	A-D per EVI route is transmitted upon the configuration of the first		A-D per-EVI route is transmitted upon the configuration of the first
	AC with the normalized VID. As additional ACs are configured and		AC with the normalized VID. As additional ACs are configured and
	associated with this EVPN VPWS service tunnel, the PE does not		associated with this EVPN-VPWS service tunnel, the PE does not
	advertise any additional EVPN BGP routes and only locally associates		advertise any additional EVPN BGP routes and only locally associates
	these ACs with the pre-established VPWS service tunnel.		these ACs with the pre-established 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 ES, all
	Ethernet Segment, all destined to a single endpoint, are multiplexed		destined to a single endpoint, are multiplexed into a single EVPN-
	into a single EVPN VPWS service tunnel, which is identified by a		VPWS service tunnel, which is identified by a unique VPWS service ID.
	unique VPWS service ID. When employing the default FXC mode for		When employing the default FXC mode for multi-homing, rather than
	multi-homing, rather than using a single EVPN VPWS service tunnel,		using a single EVPN-VPWS service tunnel, there may be multiple
	there may be multiple service tunnels per pair of PEs. Specifically,		service tunnels per pair of PEs. Specifically, there is one tunnel
	there is one tunnel for each group of VIDs per pair of PEs, and there		for each group of VIDs per pair of PEs, and there can be many such
	can be many such groups between a pair of PEs, resulting in numerous		groups between a pair of PEs, resulting in numerous EVPN service
	EVPN service tunnels.		tunnels.
	3.3. VLAN-Signaled Flexible Xconnect		3.3. VLAN-Signaled FXC
	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 and interfaces are multiplexed into a single EVPN		ESs and interfaces are multiplexed into a single EVPN-VPWS service
	VPWS service tunnel. However, this single tunnel is represented by		tunnel. However, this single tunnel is represented by multiple VPWS
	multiple VPWS service IDs (one per normalized VID), and these		service IDs (one per normalized VID), and these normalized VIDs are
	normalized VIDs are signaled using EVPN BGP.		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		ES, the PE generates an Ethernet A-D per-EVI route where the ESI
	where the ESI field represents the ES ID, the Ethernet Tag field is		field represents the ES ID, the Ethernet Tag field is set to the
	set to the normalized VID, and the MPLS label field is set to a		normalized VID, and the MPLS label field is set to a dynamically
	dynamically generated EVPN label representing the P2P EVPN service		generated EVPN label representing the P2P EVPN service tunnel. This
	tunnel. This label is the same for all ACs multiplexed into a single		label is the same for all ACs multiplexed into a single EVPN-VPWS
	EVPN VPWS service tunnel. This route is sent with an RT representing		service tunnel. This route is sent with an RT representing the EVI.
	the EVI. As before, this RT can be auto-generated from the EVI per		As before, this RT can be auto-generated from the EVI per
	Section 5.1.2.1 of [RFC8365]. Additionally, this route includes the		Section 5.1.2.1 of [RFC8365]. Additionally, this route includes the
	EVPN Layer 2 Extended Community defined in Section 3.1 of [RFC8214]		EVPN Layer 2 Attributes Extended Community defined in Section 3.1 of
	with two new flags (outlined in Section 4) that indicate: 1) this		[RFC8214] with two new flags (outlined in Section 4) that indicate:
	VPWS service tunnel for VLAN-signaled Flexible Cross-Connect and 2)		1) this VPWS service tunnel for VLAN-signaled FXC and 2) the
	the normalized VID type (single versus double). The receiving PE		normalized VID type (single versus double). The receiving PE uses
	uses these new flags for a consistency check and may generate an		these new flags for a consistency check and may generate an alarm if
	alarm if it detects inconsistency, but it will not disrupt the VPWS		it detects inconsistency, but it 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
	the same EVI, then when a PE receives the second remote Ethernet A-D		the same EVI, then when a PE receives the second remote Ethernet A-D
	per EVI route, it generates an error message unless the two Ethernet		per EVI route, it generates an error message unless the two Ethernet
	A-D per EVI routes include the same ESI. Such cross-checking is not		A-D per EVI routes include the same ESI. Such cross-checking is not
	feasible in the default FXC mode because the normalized VIDs are not		feasible in the default FXC mode because the normalized VIDs are not
	signaled.		signaled.
	3.3.1. Local Switching		3.3.1. Local Switching
	When cross-connection occurs between two ACs belonging to two multi-		When cross-connection occurs between two ACs belonging to two multi-
	homed Ethernet Segments on the same set of multi-homing PEs, the		homed ESs on the same set of multi-homing PEs, the forwarding between
	forwarding between the two ACs must be performed locally during		the two ACs must be performed locally during normal operation (e.g.,
	normal operation (e.g., in absence of a local link failure). This		in absence of a local link failure). This means that traffic between
	means that traffic between the two ACs MUST be locally switched		the two ACs MUST be locally switched within the PE.
	within the PE.
	In terms of control plane processing, this means that when the		In terms of control plane processing, this means that when the
	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
	AC or with the destination Ethernet Segment in order to avoid any		AC or with the destination ES in order to avoid any ambiguity in
	ambiguity in forwarding. In other words, the MPLS label cannot		forwarding. In other words, the MPLS label cannot represent the same
	represent the same VID-VRF outlined in Section 3.3, as the same		VID-VRF outlined in Section 3.3, as the same normalized VID can be
	normalized VID can be reachable via two Ethernet Segments. In the		reachable via two ESs. In the case of using an MPLS label per
	case of using an MPLS label per destination AC, this approach can		destination AC, this approach can also be applied to VLAN-based VPWS
	also be applied to VLAN-based VPWS or VLAN-bundle VPWS services as		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
	Normalized 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, then the signaling of the		tag mode and the other in double-tag mode, then the signaling of the
	V-bit 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 the data plane is operating based on double tags, the		(12 bits), yet the data plane is operating based on double tags, the
	VID normalization applies only to the outer tag. Conversely, if		VID normalization applies only to the outer tag. Conversely, if
	double VID normalization is signaled in the Ethernet Tag ID field (24		double VID normalization is signaled in the Ethernet Tag ID field (24
	bits), VID 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 document uses the EVPN Layer 2 attribute extended community as		This document uses the EVPN Layer 2 Attributes 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 line 554 ¶		skipping to change at line 547 ¶
	Table 1		Table 1
	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
	The two following examples analyze the failure scenarios.		The two following examples analyze the failure scenarios.
	The first scenario is a default Flexible Xconnect with a multi-homing		The first scenario is a default Flexible Cross-Connect with a multi-
	solution, and it is depicted in Figure 1. In this case, VID		homing solution, and it is depicted in Figure 1. In this case, VID
	normalization is performed, and a single Ethernet A-D per EVI route		normalization is performed, and a single Ethernet A-D per-EVI route
	is sent for the bundle of ACs on an ES. That is, PE1 will advertise		is sent for the bundle of ACs on an ES. That is, PE1 will advertise
	two Ethernet A-D per EVI routes: The first one will identify the ACs		two Ethernet A-D per-EVI routes: The first one will identify the ACs
	on port p1's ES, and the second one will identify the AC2 in port		on port p1's ES, and the second one will identify the AC2 in port
	p2's ES. Similarly, PE2 will advertise two Ethernet A-D per EVI		p2's ES. Similarly, PE2 will advertise two Ethernet A-D per-EVI
	routes.		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\ / ||---| |=====+ \ | +-----+ | / +-----+
	skipping to change at line 585 ¶		skipping to change at line 578 ¶
	/ / \p3 | +-----+ sv.T3 / +====| | | +-----+		/ / \p3 | +-----+ sv.T3 / +====| | | +-----+
	VIDs1,2 / +----| FXC |=======+ / | | |---+		VIDs1,2 / +----| FXC |=======+ / | | |---+
	+-----+ / /\ | | | | / | +-----+ |\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 Cross-Connect
	The second scenario, depicted in Figure 2, illustrates the VLAN-		The second scenario, depicted in Figure 2, illustrates the 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 value 2.		cross-connect CE2 to CE4's VID 2 and are normalized to 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 value 3.		cross-connect CE2 to CE5's VID 3 and are normalized to 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: 1) VPWS Service Tunnel 1 (sv.T1)		Service Tunnels are required: 1) VPWS Service Tunnel 1 (sv.T1)
	between PE1's FXC service and PE3's FXC and 2) VPWS Service Tunnel 2		between PE1's FXC and PE3's FXC and 2) VPWS Service Tunnel 2 (sv.T2)
	(sv.T2) between PE2's FXC and PE3's FXC.		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 line 630 ¶		skipping to change at line 623 ¶
	/ / \p3 | +-----+ | / | | | | +-----+		/ / \p3 | +-----+ | / | | | | +-----+
	VIDs1,2 / +----| FXC | / | | |---+		VIDs1,2 / +----| FXC | / | | |---+
	+-----+ / /\ | | |======+ | +-----+ |\3 +-----+		+-----+ / /\ | | |======+ | +-----+ |\3 +-----+
	| CE2 |-----||-----| | | sv.T2 | | \ | CE5 |		| CE2 |-----||-----| | | sv.T2 | | \ | CE5 |
	| |-----||-----| | | +----------+ +---| |		| |-----||-----| | | +----------+ +---| |
	+-----+ \/ | +-----+ | | +-----+		+-----+ \/ | +-----+ | | +-----+
	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 FXC
	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 Bidirectional Forwarding Detection (BFD) for
	for the Pseudowire Virtual Circuit Connectivity Verification)		the pseudowire Virtual Circuit Connectivity Verification (VCCV)
	[RFC5885], and upon such failure detection, the switchover procedure		[RFC5885], and upon such failure detection, the switch over procedure
	to the backup Switching Provider Edge (S-PE) is the same as the one		to the backup PE is the same as the one described above.
	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 packet loss at the
	Application layer OAM may be utilized if per-VLAN fault		egress PE with a failed AC. Application layer OAM may be utilized
	propagation is necessary in this scenario.		if per-VLAN fault propagation is necessary 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, this triggers the withdrawal of the Ethernet		such as VID1 on CE2, this triggers the withdrawal of the Ethernet
	A-D per EVI route for the corresponding Normalized VID,		A-D per-EVI route for the corresponding Normalized VID,
	specifically Ethernet-Tag 2. Upon receiving the route withdrawal,		specifically Ethernet-Tag 2. Upon receiving the route withdrawal,
	PE3 will remove PE1 from its outgoing path list for traffic		PE3 will remove PE1 from its outgoing adjacency list for traffic
	originating 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.		adjacency list for traffic originating from CE4 and CE5.
	* VLAN-Signaled FXC (Figure 2): A port failure, such as p2, triggers		* VLAN-Signaled FXC (Figure 2): A port failure, such as p2, triggers
	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 adjacency list for the traffic
	from CE4 and CE5.		originating 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 that leverages		Since this document describes a muxing capability that leverages
	skipping to change at line 770 ¶		skipping to change at line 762 ¶
	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
	James Uttaro		James Uttaro
	AT&T		Individual
	Email: uttaro@att.com		Email: juttaro@ieee.org
	John Drake		John Drake
	Juniper Networks		Independent
	Email: jdrake@juniper.net		Email: je_drake@yahoo.com
	Sami Boutros		Sami Boutros
	Ciena		Ciena
	Email: sboutros@ciena.com		Email: sboutros@ciena.com
	Jorge Rabadan		Jorge Rabadan
	Nokia		Nokia
	Email: jorge.rabadan@nokia.com		Email: jorge.rabadan@nokia.com
End of changes. 66 change blocks.
	187 lines changed or deleted		179 lines changed or added
This html diff was produced by rfcdiff 1.48.