rfc9744xml2.original.xml		rfc9744.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='UTF-8'?>
	<?xml-model href="rfc7991bis.rnc"?>
	<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
	<!-- This third-party XSLT can be enabled for direct transformations in XML proc
	essors, including most browsers -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?rfc strict="yes" ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	<!-- give errors regarding ID-nits and DTD validation -->		tf-bess-evpn-vpws-fxc-12" number="9744" consensus="true" submissionType="IETF" i
	<!-- control the table of contents (ToC) -->		pr="trust200902" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" v
	<?rfc toc="yes"?>		ersion="3" xml:lang="en" updates="" obsoletes="">
	<!-- generate a ToC -->
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="no" ?>
	<!-- keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->
	<rfc category="std"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	docName="draft-ietf-bess-evpn-vpws-fxc-12"
	consensus="true"
	submissionType="IETF"
	ipr="trust200902"
	tocInclude="true"
	tocDepth="4"
	symRefs="true"
	sortRefs="true">
	<!-- ***** FRONT MATTER ***** -->
	<front>		<front>
	<!-- The abbreviated title is used in the page header - it is only necessary		<title abbrev="EVPN-VPWS FXC Service">EVPN Virtual Private Wire
	if the		Service (VPWS) Flexible Cross-Connect (FXC) Service</title>
	full title is longer than 39 characters -->		<seriesInfo name="RFC" value="9744"/>
	<title abbrev="EVPN VPWS Flexible Cross-Connect">EVPN VPWS Flexible Cross-Con		<author fullname="Ali Sajassi" initials="A." surname="Sajassi" role="editor"
	nect Service</title>		>
	<seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-vpws-fxc-12"/>		<organization>Cisco Systems</organization>
			<address>
	<!-- add 'role="editor"' below for the editors if appropriate -->		<email>sajassi@cisco.com</email>
			</address>
	<!-- Another author who claims to be an editor -->		</author>
	<author fullname="Ali Sajassi" initials="A." surname="Sajassi" role="editor">		<author fullname="Patrice Brissette" initials="P." surname="Brissette">
	<organization>Cisco Systems</organization>		<organization>Cisco Systems</organization>
	<address>		<address>
	<email>sajassi@cisco.com</email>		<email>pbrisset@cisco.com</email>
	</address>		</address>
	</author>		</author>
			<author fullname="James Uttaro" initials="J." surname="Uttaro">
	<author fullname="Patrice Brissette" initials="P." surname="Brissette">		<organization>Individual</organization>
	<organization>Cisco Systems</organization>		<address>
	<address>		<email>juttaro@ieee.org</email>
	<email>pbrisset@cisco.com</email>		</address>
	</address>		</author>
	</author>		<author fullname="John Drake" initials="J." surname="Drake">
			<organization>Independent</organization>
	<author fullname="James Uttaro" initials="J." surname="Uttaro">		<address>
	<organization>AT&amp;T</organization>		<email>je_drake@yahoo.com</email>
	<address>		</address>
	<email>uttaro@att.com</email>		</author>
	</address>		<author fullname="Sami Boutros" initials="S." surname="Boutros">
	</author>		<organization>Ciena</organization>
			<address>
	<author fullname="John Drake" initials="J." surname="Drake">		<email>sboutros@ciena.com</email>
	<organization>Juniper Networks</organization>		</address>
	<address>		</author>
	<email>jdrake@juniper.net</email>		<author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
	</address>		<organization>Nokia</organization>
	</author>		<address>
			<email>jorge.rabadan@nokia.com</email>
	<author fullname="Sami Boutros" initials="S." surname="Boutros">		</address>
	<organization>Ciena</organization>		</author>
	<address>		<date year="2025" month="February"/>
	<email>sboutros@ciena.com</email>
	</address>
	</author>
	<author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
	<organization>Nokia</organization>
	<address>
	<email>jorge.rabadan@nokia.com</email>
	</address>
	</author>
	<date year="2024" />
	<!-- Meta-data Declarations -->
	<area>General</area>
	<workgroup>BESS Working Group</workgroup>
	<!-- WG name at the upperleft corner of the doc,
	IETF is fine for individual submissions.
	If this element is not present, the default is "Network Working Group
	",
	which is used by the RFC Editor as a nod to the history of the IETF. -->
	<keyword>EVPN</keyword>
	<keyword>VPWS</keyword>
	<keyword>Flexible Cross Connect</keyword>
	<keyword>FXC</keyword>
	<abstract>
	<t>This document describes a new EVPN VPWS service type specifically for
	multiplexing multiple attachment circuits across different Ethernet
	Segments and physical interfaces into a single EVPN VPWS service
	tunnel and still providing Single-Active and All-Active multi-homing.
	This new service is referred to as EVPN VPWS flexible cross-connect service.
	This document specifies a solution based on extensions to EVPN VPWS(RFC8214)
	which in turn is based on extensions to EVPN (RFC7432). Therefore,
	a thorough understanding of RFC7432 and RFC8214 are prerequisites for this
	document. </t>
	</abstract>
	<note title="Requirements Language">
	<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when
	,
	and only when, they appear in all capitals, as shown here.
	</t>
	</note>
	</front>
	<middle>
	<section title="Introduction" anchor="intro">
	<t><xref target="RFC8214"/> describes a solution to deliver P2P services usin
	g BGP
	constructs defined in <xref target="RFC7432"/>. It delivers this P2P service
	between
	a pair of Attachment Circuits (ACs), where an AC can designate on a
	PE, a port, a VLAN on a port, or a group of VLANs on a port. It also
	leverages multi-homing and fast convergence capabilities of <xref target="RFC
	7432"/>
	in delivering these VPWS services. Multi&nbhy;homing capabilities include
	the support of single-active and all&nbhy;active redundancy mode and fast
	convergence is provided using "mass withdrawal" message in control-plane and
	fast protection switching using prefix independent
	convergence in data-plane upon node or link failure <xref target="I-D.ietf-rt
	gwg-bgp-pic"/>.
	Furthermore, the use of EVPN BGP constructs eliminates the need for
	multi-segment pseudowire auto&nbhy;discovery and signaling if the VPWS servic
	e
	need to span across multiple ASes <xref target="RFC5659"/>.</t>
	<t>Service providers have very large number of ACs (in millions)
	that need to be backhauled across their MPLS/IP network. These ACs
	may or may not require tag manipulation (e.g., VLAN translation).
	These service providers want to multiplex a large number of ACs
	across several physical interfaces spread across one or more PEs
	(e.g., several Ethernet Segments) onto a single VPWS service tunnel
	in order to a) reduce number of EVPN service labels associated with
	EVPN-VPWS service tunnels and thus the associated OAM monitoring, and
	b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is
	the case in <xref target="RFC8214"/>).</t>
	<t>Service providers want the above functionality without
	sacrificing any of the capabilities of <xref target="RFC8214"/> including sin
	gle-
	active and all-active multi-homing, and fast convergence.</t>
	<t>This document specifies a solution based on extensions to EVPN VPWS
	(<xref target="RFC8214"/>) to meet the above requirements. Furthermore,
	<xref target="RFC8214"/> is itself based on extensions to EVPN (<xref target=
	"RFC7432"/>).
	Therefore, a thorough understanding of <xref target="RFC7432"/> and
	<xref target="RFC8214"/> are prerequisites for this document. </t>
	<section title="Terminology" anchor="terminology">
	<t>
	<list style="hanging" hangIndent="3">
	<t hangText="AC:&nbsp;&nbsp;">Attachment Circuit</t>
	<t hangText="ES:&nbsp;&nbsp;">Ethernet Segment</t>
	<t hangText="ESI:&nbsp;">Ethernet Segment Identififer</t>
	<t hangText="EVI:&nbsp;">EVPN Instance Identifier</t>
	<t hangText="EVPN:">Ethernet Virtual Private Network</t>
	<t hangText="Ethernet A-D:">Ethernet Auto-Discovery (A-D) per EVI and Ethe
	rnet A-D per ESI routes, as
	defined in <xref target="RFC7432"/> and <xref target="RFC8214"/>.</t>
	<t hangText="FXC:&nbsp;">Flexible Cross Connect</t>
	<t hangText="MAC:&nbsp;">Media Access Control</t>
	<t hangText="MPLS:">Multi Protocol Label Switching</t>
	<t hangText="OAM:&nbsp;">Operations, Administration and Maintenance</t>
	<t hangText="PE:&nbsp;">Provider Edge device</t>
	<t hangText="VCCV:">Virtual circuit connection verification</t>
	<t hangText="VID:&nbsp;">Vlan ID</t>
	<t hangText="VPWS:">Virtual private wire service</t>
	<t hangText="VRF:&nbsp;">VPN Routing and Forwarding table</t>
	<t hangText="IP-VRF:&nbsp;">VPN Routing and Forwarding table, for IP looku
	p</t>
	<t hangText="MAC-VRF:&nbsp;">VPN Routing and Forwarding table, for MAC loo
	kup</t>
	<t hangText="VID-VRF:&nbsp;">VPN Routing and Forwarding table, for Normali
	zed VID lookup</t>
	<t hangText="VPWS Service Tunnel:">It is represented by a pair of EVPN ser
	vice
	labels associated with a pair of endpoints. Each label is downstream
	assigned and advertised by the disposition PE through an Ethernet Auto-Dis
	covery (A-D)
	per EVI route. The downstream label identifies the endpoint on the
	disposition PE. A VPWS service tunnel can be associated with many
	VPWS service identifiers where each identifier is a normalized VID.</t>
	<t hangText="Single-Active Redundancy Mode:">When a device or a network
	is multi&nbhy;homed to two
	or more PEs and when only a single PE in such redundancy group can
	forward traffic to/from the multi-homed device or network for a given
	VLAN, then such multi-homing or redundancy is referred to as
	"Single-Active".</t>
	<t hangText="All-Active Redundancy Mode:">When a device or a network is mu
	lti&nbhy;homed to
	two or more PEs and when
	all PEs in such redundancy group can forward traffic to/from the
	multi-homed device or network for a given VLAN, then such multi-homing or
	redundancy is referred to as "All-Active".</t>
	</list>
	</t>
	</section>
	</section>
	<section title="Requirements" anchor="requirements">
	<t>Two of the main motivations for service providers seeking a new
	solution are: 1) to reduce number of VPWS service tunnels by
	multiplexing large number of ACs across different physical 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
	requirements, they also want multi-homing and fast convergence
	capabilities of <xref target="RFC8214"/>.</t>
	<t>In <xref target="RFC8214"/>, a PE signals an AC indirectly by first associ
	ating that
	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
	with Ethernet Tag field set to a 24-bit VPWS service instance
	identifier (which is unique within the EVI) and ESI field set to a
	10-octet identifier of the Ethernet Segment corresponding to that AC.</t>
	<t>Therefore, a PE device that receives such EVPN routes, can associate
	the VPWS service tunnel to the remote Ethernet Segment using the ESI field, a
	nd when the
	remote ES fails and the PE receives the "mass withdrawal" message
	associated with the failed ES per <xref target="RFC7432"/>, it can quickly up
	date its BGP
	list of available remote entries to invalidate all VPWS service tunnels shari
	ng the ESI field and achieve fast
	convergence for multi-homing scenarios. Even if fast convergence were
	not needed, there would still be a need for signaling each AC failure
	(via its corresponding VPWS service tunnel) 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 (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 updating the BGP path
	list, the traffic for that VPWS service tunnel will be black&nbhy;holed.</t>
	<t>
	When a single VPWS service tunnel carries multiple ACs across various
	Ethernet Segments (physical interfaces) without signaling the ACs via
	EVPN BGP to remote PE devices, those remote PE devices lack the
	information to associate the received Ethernet Segment with these
	ACs 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. This means that while the remote PEs can associate their local
	ACs with the VPWS service tunnel, they cannot make similar associations
	for the far-end ACs.
	<br/>
	Consequently, in case of a connectivity failure to the ES, the
	remote 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 to the remote PE devices, they cannot effectively respond because
	they do not know the relationship between the remote ES, the
	remote ACs, and the VPWS service tunnel.</t>
	<t>To address this issue when multiplexing a large number of ACs
	onto a single VPWS service tunnel, two mechanisms have been
	developed: one to support VPWS services between two single-homed
	endpoints, and another to support VPWS services where one of
	the endpoints is multi-homed.</t>
	<t>
	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 no alternative path to that endpoint. However, the implication
	of 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 destination PE, thereby potentially wasting network resources.
	<br/>
	This waste of network resources during a connection failure may
	be transient, as it can be detected and prevented at the application
	layer in certain cases. <xref target="fxc"/> outlines a solution for such
	single-homing VPWS services.</t>
	<t>
	For VPWS services where one of the endpoints is multi-homed, there
	are two options: </t>
	<t>1) to signal each AC via BGP, allowing the path list to be updated upon a
	failure affecting those ACs. This solution is described in <xref target="vlan_si
	g_fxc"/> and
	is referred to as the VLAN-signaled flexible cross-connect service.</t>
	<t>2) to bundle several ACs on an ES together per destination endpoint
	(e.g., ES, MAC-VRF, etc.) and associate such a bundle with a single
	VPWS service tunnel. This approach is similar to the VLAN-bundle
	service interface described in <xref target="RFC8214"/>. This solution is descri
	bed
	in <xref target="fxc_mh"/>.</t>
	</section>
	<section title="Solution" anchor="solution">
	<t>
	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 across multiple Ethernet Segments (physical interfaces) on each
	PE are multiplexed onto a single P2P EVPN service tunnel. Since the
	multiplexing involves several physical interfaces, there can be
	overlapping VLAN IDs across these interfaces. In such cases, the
	VLAN IDs (VIDs) must be translated into unique VIDs to prevent collisions.
	Furthermore, if the number of VLANs being multiplexed onto a single
	VPWS service tunnel exceeds 4095, then a single tag to double tag
	translation must be performed. This translation of VIDs into unique
	VIDs (either single or double) results in a "Normalized VID".</t>
	<t>
	When a single normalized VID is used, the lower 12 bits of the Ethernet
	Tag ID field in EVPN routes MUST be set to that VID. When a double normalized
	VID is used, the lower 12 bits of the Ethernet Tag ID field MUST be set to
	the inner VID, while the higher 12 bits are set to the outer VID. As
	stated in <xref target="RFC8214"/>, 12-bit and 24-bit VPWS service instance iden
	tifiers
	representing normalized VIDs MUST be right-aligned.</t>
	<t>
	Since there is only a single EVPN VPWS service tunnel associated with
	many normalized VIDs (either single or double) across multiple
	physical interfaces, an MPLS lookup at the disposition PE is no
	longer sufficient to forward the packet to the correct egress
	endpoint or interface. Therefore, in addition to an EVPN label
	lookup corresponding to the VPWS service tunnel, a VID lookup
	(either single or double) is also required. At the disposition
	PE, the EVPN label lookup identifies a VID-VRF, and the lookup
	of the normalized VID(s) within that table identifies the appropriate
	egress endpoint or interface. The tag manipulation (translation from
	normalized VID(s) to the local VID) SHOULD be performed either as
	part of the VID table lookup or at the egress interface itself.</t>
	<t>
	Since the VID lookup (single or double) needs to be performed at the
	disposition PE, VID normalization MUST be completed prior to MPLS
	encapsulation on the ingress PE. This requires that both the imposition
	and disposition PE devices be capable of VLAN tag manipulation, such
	as rewriting (single or double), addition, or deletion (single or
	double) at their endpoints (e.g., their ESs, MAC-VRFs, IP-VRFs, etc.).
	Operators should be informed of potential trade-offs from a performance
	standpoint, compared to typical pseudowire processing.</t>
	<section title="VPWS Service Identifiers" anchor="svc_ids">
	<t>In <xref target="RFC8214"/>, a unique value identifying the service is si
	gnaled in the context of each PE's
	EVI. The 32-bit Ethernet Tag ID field MUST be set to this
	VPWS service instance identifier value. Translation at an Autonomous System
	Border Router (ASBR) is needed if re-advertising to
	another AS affects uniqueness.</t>
	<t>For FXC, this same Ethernet Tag ID field value is an identifier which may
	represent:
	<list style="symbols">
	<t>VLAN-Bundle Service Interface: a unique value for a group of VLANs ;</t>
	<t>VLAN-Aware Bundle Service Interface : a unique value for individual VLAN
	s, and is
	considered same as the normalized VID.</t>
	</list>
	</t>
	<t>Both the VPWS service instance identifier and normalized VID are
	carried in the Ethernet Tag ID field of the Ethernet A-D per EVI route.
	For FXC, in the case of a 12-bit ID the VPWS service instance identifier
	is the same as the single-tag normalized VID and will be the same
	on both VPWS service endpoints. Similarly in the case of a 24-bit ID, the VP
	WS service
	instance identifier is the same as the double-tag normalized VID.</t>
	</section>
	<section title="Default Flexible Xconnect" anchor="fxc">
	<t>In this mode of operation, many ACs across several Ethernet Segments
	are multiplexed into a single EVPN VPWS service tunnel represented by a
	single VPWS service ID. This is the default mode of operation for FXC
	and the participating PEs do not need to signal the VLANs (normalized
	VIDs) in EVPN BGP.</t>
	<t>Regarding the data-plane aspects of this solution, the
	imposition Provider Edge (PE) performs VID normalization and the disposition
	PE carries out VID lookup and
	translation. Both imposition and disposition PE devices MUST be aware of the
	VLANs through configuration.
	There should ideally be a single point-to-point (P2P) EVPN VPWS service tunne
	l
	between a pair of PEs for a specific set of Attachment Circuits (ACs).</t>
	<t>As previously mentioned, because the EVPN VPWS service tunnel
	is employed to multiplex ACs across various Ethernet
	Segments (ESs) or physical interfaces, the EVPN label alone is not sufficient fo
	r accurate forwarding of the
	received packets over the MPLS/IP network to egress interfaces.
	Therefore, normalized VID lookup is REQUIRED in the disposition
	direction to forward packets to their proper egress end-points; the EVPN labe
	l lookup identifies
	a VID-VRF, and a subsequent normalized VID lookup in that table identifies th
	e egress
	interface.</t>
	<t>In this solution, for each PE, the single-homing ACs represented by
	their normalized VIDs are associated with a single VPWS service instance with
	in a specific EVI.
	The generated EVPN route is an
	Ethernet A-D per EVI route with an ESI of 0, and Ethernet Tag field set to th
	e
	VPWS service instance ID, and the MPLS label field set to a dynamically
	generated EVPN service label representing the EVPN VPWS service
	tunnel. This route is sent with a Route Target (RT) that represents the EVI,
	which can be
	auto&nbhy;generated from the EVI according to <relref target="RFC8365"
	section="5.1.2.1"/>.
	Additionally, this route is sent with the EVPN Layer-2
	Extended Community defined in <relref target="RFC8214" section="3.1"/> with t
	wo new
	flags (outlined in <xref target="bgp_extensions"/>) that indicate: 1) this VP
	WS service
	tunnel is for the default Flexible Cross-Connect, and 2) the normalized VID
	type (single versus double). The receiving PE uses these new flags
	for a consistency check and MAY generate an alarm if it detects
	inconsistencies, but it will not disrupt the VPWS service.</t>
	<t>It should be noted that in this mode of operation, a single Ethernet&nbsp;		<area>RTG</area>
	A-D per EVI		<workgroup>bess</workgroup>
	route is transmitted upon the configuration of the first Attachment Circuit (
	AC) with the normalized VID.
	As additional ACs are configured and
	associated with this EVPN VPWS service tunnel, the PE does not
	advertise any additional EVPN BGP routes and only associates
	locally these ACs with the pre-established VPWS service tunnel.</t>
	<section title="Multi-homing" anchor="fxc_mh">		<keyword>EVPN</keyword>
			<keyword>VPWS</keyword>
			<keyword>Flexible Cross-Connect</keyword>
			<keyword>FXC</keyword>
	<t>The default FXC mode can also be used for multi-homing. In this mode, a		<abstract>
	group of normalized VIDs representing ACs on a single Ethernet Segment, all		<t>This document describes a new EVPN Virtual Private Wire Service (VPWS)
	destined to a single endpoint, are multiplexed into a single EVPN VPWS		service type specifically for
	service tunnel which is identified by a unique VPWS service ID.		multiplexing multiple attachment circuits across different Ethernet
	When employing the default FXC mode for multi-homing, rather than using a si		Segments (ESs) and physical interfaces into a single EVPN-VPWS service tun
	ngle EVPN VPWS		nel
	service tunnel there may be multiple service tunnels per pair of		and still providing Single-Active and All-Active multi-homing. This new
	PEs. Specifically, there is one tunnel for each group of VIDs per pair of PE		service is referred to as the EVPN-VPWS Flexible Cross-Connect (FXC) servi
	s, and there can be		ce.
	many such groups between a pair of PEs, resulting in numerous EVPN service t		This document specifies a solution based on extensions to EVPN-VPWS (RFC
	unnels.</t>		8214), which in turn is based on extensions to EVPN (RFC
			7432). Therefore, a thorough understanding of RFCs 7432 and 8214 are
			prerequisites for this document.</t>
			</abstract>
			</front>
			<middle>
			<section anchor="intro">
			<name>Introduction</name>
			<t><xref target="RFC8214"/> describes a solution to deliver
			point-to-point (P2P) services using BGP constructs defined in <xref
			target="RFC7432"/>. It delivers this P2P service between a pair of
			Attachment Circuits (ACs), where an AC on a PE can represent a port, a
			VLAN on a port, or a group of VLANs on a port. It also leverages
			multi-homing and fast convergence capabilities of <xref
			target="RFC7432"/> in delivering these VPWS services. Multi-homing
			capabilities include the support of Single-Active and All-Active
			redundancy mode, and fast convergence is provided using a "mass
			withdrawal" message in control plane and fast protection switching using
			prefix-independent convergence in a data plane upon node or link failure
			<xref target="I-D.ietf-rtgwg-bgp-pic"/>. Furthermore, the use of EVPN
			BGP constructs eliminates the need for multi-segment pseudowire
			auto-discovery and signaling if the VPWS service need to span across
			multiple Autonomous Systems (ASes) <xref target="RFC5659"/>.</t>
			<t>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 may
			not require tag manipulation (e.g., VLAN translation). These service
			providers want to multiplex a large number of ACs across several
			physical interfaces spread across one or more PEs (e.g., several
			ESs) onto a single VPWS service tunnel in order to a)
			reduce the number of EVPN service labels associated with EVPN-VPWS service
			tunnels and thus the associated Operations, Administration, and Maintenanc
			e (OAM) monitoring and b) reduce EVPN BGP
			signaling (e.g., not to signal each AC as it is the case in <xref
			target="RFC8214"/>).</t>
			<t>Service providers want the above functionality without sacrificing
			any of the capabilities of <xref target="RFC8214"/> including
			Single-Active and All-Active multi-homing and fast convergence.</t>
			<t>This document specifies a solution based on extensions to EVPN-VPWS
			<xref target="RFC8214"/> to meet the above requirements. Furthermore,
			<xref target="RFC8214"/> is itself based on extensions to EVPN <xref
			target="RFC7432"/>. Therefore, a thorough understanding of <xref
			target="RFC7432"/> and <xref target="RFC8214"/> are prerequisites for
			this document. </t>
			<section anchor="terminology">
			<name>Terminology</name>
			<dl newline="false" spacing="normal" indent="3">
			<dt>AC:</dt>
			<dd>Attachment Circuit</dd>
			<dt>ES:</dt>
			<dd>Ethernet Segment</dd>
			<dt>ESI:</dt>
			<dd>Ethernet Segment Identifier</dd>
			<dt>EVI:</dt>
			<dd>EVPN Instance Identifier</dd>
			<dt>EVPN:</dt>
			<dd>Ethernet Virtual Private Network</dd>
			<dt>Ethernet A-D:</dt>
			<dd>Ethernet Auto-Discovery (per EVI or per Ethernet A-D per ESI
			routes, as defined in <xref target="RFC7432"/> and <xref
			target="RFC8214"/>)</dd>
			<dt>FXC:</dt>
			<dd>Flexible Cross-Connect</dd>
			<dt>MAC:</dt>
			<dd>Media Access Control</dd>
			<dt>MPLS:</dt>
			<dd>Multiprotocol Label Switching</dd>
			<dt>OAM:</dt>
			<dd>Operations, Administration, and Maintenance</dd>
			<dt>PE:</dt>
			<dd>Provider Edge</dd>
			<dt>VCCV:</dt>
			<dd>Virtual Circuit Connectivity Verification</dd>
			<dt>VID:</dt>
			<dd>VLAN ID</dd>
			<dt>VPWS:</dt>
			<dd>Virtual Private Wire Service</dd>
			<dt>VRF:</dt>
			<dd>VPN Routing and Forwarding</dd>
			<dt>IP-VRF:</dt>
			<dd>VPN Routing and Forwarding for IP lookup</dd>
			<dt>MAC-VRF:</dt>
			<dd>VPN Routing and Forwarding for MAC lookup</dd>
			<dt>VID-VRF:</dt>
			<dd>VPN Routing and Forwarding for normalized VID lookup</dd>
			<dt>VPWS Service Tunnel:</dt>
			<dd>It is represented by a pair of EVPN service labels associated
			with a pair of endpoints. Each label is downstream assigned and
			advertised by the disposition PE through an Ethernet A-D per EVI
			route. The downstream label identifies the endpoint on the
			disposition PE. A VPWS service tunnel can be associated with many
			VPWS service identifiers where each identifier is a normalized
			VID.</dd>
			<dt>Single-Active Redundancy Mode:</dt>
			<dd>When a device or a network is multi-homed to two or more PEs and
			when only a single PE in such redundancy group can forward traffic
			to/from the multi-homed device or network for a given VLAN, then
			such multi-homing or redundancy is referred to as
			"Single-Active".</dd>
			<dt>All-Active Redundancy Mode:</dt>
			<dd>When a device or a network is multi-homed to two or more PEs and
			when all PEs in such redundancy group can forward traffic to/from
			the multi-homed device or network for a given VLAN, then such
			multi-homing or redundancy is referred to as "All-Active".</dd>
			</dl>
			</section>
			<section>
			<name>Requirements Language</name>
			<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
			"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
			NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
			"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
			to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
			target="RFC8174"/> when, and only when, they appear in all capitals, as
			shown here.
			</t>
			</section>
	</section>		</section>
			<section anchor="requirements">
	</section>		<name>Requirements</name>
			<t>Two of the main motivations for service providers seeking a new
	<section title="VLAN-Signaled Flexible Xconnect" anchor="vlan_sig_fxc">		solution are: 1) to reduce the number of VPWS service tunnels by
	<t>In this mode of operation, similar to the default FXC mode described in <x		multiplexing a large number of ACs across different physical interfaces
	ref target="fxc"/>,		instead of having one VPWS service tunnel per AC and 2) to reduce the
	many normalized VIDs representing ACs across several Ethernet Segments/interf		signaling of ACs as much as possible. Besides these two requirements,
	aces are multiplexed into a single EVPN VPWS service		they also want the multi-homing and fast convergence capabilities of
	tunnel. However, this single tunnel is represented by multiple VPWS		<xref target="RFC8214"/>.</t>
	service IDs (one per normalized VID) and these normalized VIDs are		<t>In <xref target="RFC8214"/>, a PE signals an AC indirectly by first
	signaled using EVPN BGP.</t>		associating that AC to a VPWS service tunnel (e.g., a VPWS service
			instance) and then signaling the VPWS service tunnel via an Ethernet A-D
	<t>In this solution, on each PE, the multi-homing ACs represented by		per EVI route with the Ethernet Tag field set to a 24-bit VPWS service
	their normalized VIDs are configured with a single EVI. There is no		instance identifier (which is unique within the EVI) and the ESI field
	need to configure a separate VPWS service instance ID in here, as it correspo		set to a 10-octet identifier of the ES corresponding to
	nds to the		that AC.</t>
	normalized VID. For each normalized VID on each Ethernet Segment, the PE		<t>Therefore, a PE device that receives such EVPN routes can associate
	generates an Ethernet A-D per EVI route where the ESI field		the VPWS service tunnel to the remote ES using the ESI field.
	represents the ES ID, the Ethernet Tag field is set to the normalized		Additionally, when the remote ES fails and the PE receives the "mass
	VID, and the MPLS label field is set to a dynamically generated EVPN label		withdrawal" message associated with the failed ES per <xref
	representing the P2P EVPN service tunnel. This label is the same for		target="RFC7432" format="default"/>, a PE device can quickly update its
	all ACs multiplexed into a single EVPN VPWS service		next-hop adjacency list (adjacency list) for all VPWS service tunnels
	tunnel. This route is sent with a Route Target (RT) representing the EVI. As		sharing the ESI field and achieve fast convergence for multi-homing
	before, this RT can be auto-generated from the EVI per section		scenarios. Even if fast convergence were not needed, there would still
	<relref target="RFC8365" section="5.1.2.1"/>. Additionally, this route includ		be a need for signaling each AC failure (via its corresponding VPWS
	es the		service tunnel) associated with the failed ES so that the adjacency list
	EVPN Layer-2 Extended Community defined in <relref target="RFC8214" section="		gets updated and the packets are sent to a backup PE (in case of
	3.1"/>		Single-Active multi-homing) or to other PEs in the redundancy group (in
	with two new flags (outlined in <xref target="bgp_extensions"/>) that indicat		case of All-Active multi-homing). In the absence of updating the
	e: 1) this VPWS		adjacency list properly, the traffic for that VPWS service tunnel will
	service tunnel is for VLAN-signaled Flexible Cross-Connect, and 2)		be dropped by the egress PE with a failed ES/AC.</t>
	the normalized VID type (single versus double). The receiving PE uses		<t>When a single VPWS service tunnel carries multiple ACs across various
	these new flags for a consistency check and may generate an alarm if it		ESs (physical interfaces) without signaling the ACs via
	detects inconsistency, but it will not disrupt the VPWS service.</t>		EVPN BGP to remote PE devices, those remote PE devices lack the
			information to associate the received ES with these ACs or
	<t>It should be noted that in this mode of operation, the PE sends a		with their local ACs. They also lack the association between the VPWS
	single Ethernet A-D per EVI route for each AC that is configured. Each		service tunnel (e.g., EVPN service label) and the far-end ACs. This
	normalized VID that is configured per ES results in generation of an Ethernet		means that, while the remote PEs can associate their local ACs with the
	A-D per EVI.</t>		VPWS service tunnel, they cannot make similar associations for the
			far-end ACs.</t>
	<t>This mode of operation enabled automatic cross-checking of		<t>Consequently, in case of a connectivity failure to the ES, the remote
	normalized VIDs used for Ethernet Virtual Private Line (EVPL) services becaus		PEs are unable to redirect traffic via another multi-homing PE to that
	e these VIDs are		ES. In other words, even if an ES failure is signaled via EVPN to the
	signaled in EVPN BGP. For instance, if the same normalized VID is		remote PE devices, they cannot effectively respond because they do not
	configured on three PE devices (instead of two) for the same EVI,		know the relationship between the remote ES, the remote ACs, and the
	then when a PE receives the second remote Ethernet A-D per EVI route, it		VPWS service tunnel.</t>
	generates an error message unless the two Ethernet A-D per EVI routes		<t>To address this issue when multiplexing a large number of ACs onto a
	include the same ESI. Such cross-checking is not feasible in the default		single VPWS service tunnel, two mechanisms have been developed: one to
	FXC mode because the normalized VIDs are not signaled.</t>		support VPWS services between two single-homed endpoints and another one t
			o
	<section title="Local Switching" anchor="local_switch">		support VPWS services where one of the endpoints is multi-homed.</t>
	<t>When cross-connection occurs between two ACs belonging to two multi-homed		<t>For single-homed endpoints, it is acceptable not to signal each AC in
	Ethernet Segments on the same set of multi-homing PEs, the		BGP because, in the event of a connection failure to the ES, there is no
	forwarding between the two ACs must be performed locally during		alternative path to that endpoint. However, the implication of not
	normal operation (e.g., in absence of a local link failure). This means that		signaling an AC failure is that the traffic destined for the failed AC
	traffic between the two ACs MUST be locally switched within the		is sent over the MPLS/IP core and then discarded at the destination PE,
	PE.</t>		thereby potentially wasting network resources.</t>
			<t>This waste of network resources during a connection failure may be
	<t>In terms of control plane processing, this means that when the		transient, as it can be detected and prevented at the application layer
	receiving PE processes an Ethernet A-D per EVI route whose ESI is a		in certain cases. <xref target="fxc"/> outlines a solution for such
	local ESI, the PE does not modify its forwarding state based on the		single-homing VPWS services.</t>
	received route. This approach ensures that local switching takes		<t>For VPWS services where one of the endpoints is multi-homed, there
	precedence over forwarding via the MPLS/IP network.		are two options: </t>
	This method of prioritizing locally switched traffic aligns with the baseline		<ol spacing="normal" type="1">
	EVPN principles described in <xref target="RFC7432"/>,		<li>Signal each AC via BGP, allowing the adjacency list to be updated
	where locally switched preference is specified for MAC/&wj;IP routes.</t>		upon a failure affecting those ACs. This solution is described in
			<xref target="vlan_sig_fxc"/> and is referred to as the "VLAN-signaled
	<t>In such scenarios, the Ethernet A-D per EVI route should be		FXC service".</li>
	advertised with the MPLS label either associated with the destination		<li>Bundle several ACs on an ES together per destination endpoint
	Attachment Circuit or with the destination Ethernet Segment in order		(e.g., ES, MAC-VRF, etc.) and associate such a bundle with a single
	to avoid any ambiguity in forwarding. In other words, the MPLS label		VPWS service tunnel. This approach is similar to the VLAN bundle
	cannot represent the same VID-VRF outlined in <xref target="vlan_sig_fxc"/>,		service interface described in <xref target="RFC8214"/>. This solution
	as the same normalized VID can be reachable via two Ethernet Segments.		is described in <xref target="fxc_mh"/>.</li>
	In the case of using an MPLS label per destination AC, this approach can als		</ol>
	o be applied to
	VLAN-based VPWS or VLAN-bundle VPWS services as per
	<xref target="RFC8214"/>.</t>
	</section>		</section>
			<section anchor="solution">
			<name>Solution</name>
			<t>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 across
			multiple ESs (physical interfaces) on each PE are
			multiplexed onto a single P2P EVPN service tunnel. Since the
			multiplexing involves several physical interfaces, there can be
			overlapping VLAN IDs (VIDs) across these interfaces. In such cases, the
			VIDs must be translated into unique VIDs to prevent collisions.
			Furthermore, if the number of VLANs being multiplexed onto a single VPWS
			service tunnel exceeds 4095, then a single tag to double tag translation
			must be performed. This translation of VIDs into unique VIDs (either
			single or double) results in a "normalized VID".</t>
			<t>When a single normalized VID is used, the lower 12 bits of the
			Ethernet Tag ID field in EVPN routes <bcp14>MUST</bcp14> be set to that
			VID. When a double normalized VID is used, the lower 12 bits of the
			Ethernet Tag ID field <bcp14>MUST</bcp14> be set to the inner VID, while
			the higher 12 bits are set to the outer VID. 24-bit VPWS service
			instance identifiers <xref target="RFC8214"/> as well as 12-bit VPWS
			service instance identifiers representing normalized VIDs
			<bcp14>MUST</bcp14> be right-aligned. </t>
			<t>Since there is only a single EVPN-VPWS service tunnel associated with
			many normalized VIDs (either single or double) across multiple physical
			interfaces, an MPLS lookup at the disposition PE is no longer sufficient
			to forward the packet to the correct egress endpoint or
			interface. Therefore, in addition to an EVPN label lookup corresponding
			to the VPWS service tunnel, a VID lookup (either single or double) is
			also required. At the disposition PE, the EVPN label lookup identifies a
			VID-VRF, and the lookup of the normalized VIDs within that table
			identifies the appropriate egress endpoint or interface. The tag
			manipulation (translation from normalized VIDs to the local VID)
			<bcp14>SHOULD</bcp14> be performed either as part of the VID table
			lookup or at the egress interface itself.</t>
			<t>Since the VID lookup (single or double) needs to be performed at the
			disposition PE, VID normalization <bcp14>MUST</bcp14> be completed prior
			to MPLS encapsulation on the ingress PE. This requires that both the
			imposition and disposition PE devices be capable of VLAN tag
			manipulation, such as rewriting (single or double), adding, or deleting
			(single or double) at their endpoints (e.g., their ESs, MAC-VRFs,
			IP-VRFs, etc.). Operators should be informed of potential trade-offs
			from a performance standpoint, compared to typical pseudowire
			processing.</t>
			<section anchor="svc_ids">
			<name>VPWS Service Identifiers</name>
			<t>In <xref target="RFC8214"/>, a unique value identifying the service
			is signaled in the context of each PE's EVI. The 32-bit Ethernet Tag
			ID field <bcp14>MUST</bcp14> be set to this VPWS service instance
			identifier value. Translation at an Autonomous System Border Router
			(ASBR) is needed if re-advertising to another AS affects
			uniqueness.</t>
			<t>For FXC, this same Ethernet Tag ID field value is an identifier that
			may represent:</t>
			<ul spacing="normal">
			<li>VLAN Bundle Service Interface: a unique value for a group of
			VLANs</li>
			<li>VLAN-Aware Bundle Service Interface: a unique value for
			individual VLANs and is considered the same as the normalized VID</li>
			</ul>
			<t>Both the VPWS service instance identifier and normalized VID are
			carried in the Ethernet Tag ID field of the Ethernet A-D per EVI
			route. For FXC, in the case of a 12-bit ID, the VPWS service instance
			identifier is the same as the single-tag normalized VID and will be
			the same on both VPWS service endpoints. Similarly in the case of a
			24-bit ID, the VPWS service instance identifier is the same as the
			double-tag normalized VID.</t>
			</section>
			<section anchor="fxc">
			<name>Default Flexible Cross-Connect</name>
			<t>In this mode of operation, many ACs across several ESs are
			multiplexed into a single EVPN-VPWS service tunnel represented by a
			single VPWS service ID. This is the default mode of operation for FXC,
			and the participating PEs do not need to signal the VLANs (normalized
			VIDs) in EVPN BGP.</t>
			<t>Regarding the data plane aspects of this solution, the imposition
			PE performs VID normalization, and the disposition PE carries out VID
			lookup and translation. Both imposition and disposition PE devices
			<bcp14>MUST</bcp14> be aware of the VLANs through configuration.
			There should ideally be a single point-to-point (P2P) EVPN-VPWS
			service tunnel between a pair of PEs for a specific set of ACs.</t>
			<t>As previously mentioned, because the EVPN-VPWS service tunnel is
			employed to multiplex ACs across various ESs or
			physical interfaces, the EVPN label alone is not sufficient for
			accurate forwarding of the received packets over the MPLS/IP network
			to egress interfaces. Therefore, normalized VID lookup is
			<bcp14>REQUIRED</bcp14> in the disposition direction to forward
			packets to their proper egress endpoints; the EVPN label lookup
			identifies a VID-VRF, and a subsequent normalized VID lookup in that
			table identifies the egress interface.</t>
			<t>In this solution, for each PE, the single-homing ACs represented by
			their normalized VIDs are associated with a single VPWS service
			instance within a specific EVI. The generated EVPN route is an
			Ethernet A-D per-EVI route with an ESI of 0, the Ethernet Tag field is
			set to a VPWS service instance ID, and the MPLS label field is set to
			a dynamically generated EVPN service label representing the EVPN-VPWS
			service tunnel. This route is sent with a Route Target (RT) that
			represents the EVI, which can be auto-generated from the EVI according
			to <xref target="RFC8365" section="5.1.2.1"/>. Additionally, this
			route is sent with the EVPN Layer 2 Attributes Extended Community
			defined in <xref target="RFC8214" section="3.1" sectionFormat="of"/>
			with two new flags (outlined in <xref target="bgp_extensions"/>) that
			indicate: 1) the VPW service tunnel (set to default Flexible
			Cross-Connect) and 2) the normalized VID type (set to normalized
			single VID or double VID). The receiving PE uses these new flags for a
			consistency check and <bcp14>MAY</bcp14> generate an alarm if it
			detects inconsistencies, but it will not disrupt the VPWS service.</t>
			<t>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 AC with the normalized VID. As additional ACs are
			configured and associated with this EVPN-VPWS service tunnel, the PE
			does not advertise any additional EVPN BGP routes and only locally
			associates these ACs with the pre-established VPWS service tunnel.</t>
			<section anchor="fxc_mh">
			<name>Multi-homing</name>
			<t>The default FXC mode can also be used for multi-homing. In this
			mode, a group of normalized VIDs representing ACs on a single ES, all
			destined to a single endpoint, are multiplexed into a single EVPN-VPWS
			service tunnel, which is identified by a unique VPWS service ID. When
			employing the default FXC mode for multi-homing, rather than using a
			single EVPN-VPWS service tunnel, there may be multiple service tunnels
			per pair of PEs. Specifically, there is one tunnel for each group of
			VIDs per pair of PEs, and there can be many such groups between a pair
			of PEs, resulting in numerous EVPN service tunnels.</t>
			</section>
			</section>
			<section anchor="vlan_sig_fxc">
			<name>VLAN-Signaled FXC</name>
			<t>In this mode of operation, similar to the default FXC mode
			described in <xref target="fxc"/>, many normalized VIDs representing
			ACs across several ESs and interfaces are multiplexed into a
			single EVPN-VPWS service tunnel. However, this single tunnel is
			represented by multiple VPWS service IDs (one per normalized VID), and
			these normalized VIDs are signaled using EVPN BGP.</t>
			<t>In this solution, on each PE, the multi-homing ACs represented by
			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
			corresponds to the normalized VID. For each normalized VID on each
			ES, the PE generates an Ethernet A-D per-EVI route 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 dynamically
			generated EVPN label representing the P2P EVPN service tunnel. This
			label is the same for all ACs multiplexed into a single EVPN-VPWS
			service tunnel. This route is sent with an RT representing the EVI. As
			before, this RT can be auto-generated from the EVI per <xref
			target="RFC8365" section="5.1.2.1"/>. Additionally, this route
			includes the EVPN Layer 2 Attributes Extended Community defined in <xref
			target="RFC8214" section="3.1"/> with two new flags (outlined in <xref
			target="bgp_extensions"/>) that indicate: 1) this VPWS service tunnel
			for VLAN-signaled FXC and 2) the normalized VID
			type (single versus double). The receiving PE uses these new flags for
			a consistency check and may generate an alarm if it detects
			inconsistency, but it will not disrupt the VPWS service.</t>
			<t>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. Each
			normalized VID that is configured per ES results in generation of an
			Ethernet A-D per EVI.</t>
			<t>This mode of operation enabled automatic cross-checking of
			normalized VIDs used for Ethernet Virtual Private Line (EVPL) services
			because these VIDs are signaled in EVPN BGP. For instance, if the same
			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
			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
			feasible in the default FXC mode because the normalized VIDs are not
			signaled.</t>
			<section anchor="local_switch">
			<name>Local Switching</name>
			<t>When cross-connection occurs between two ACs belonging to two
			multi-homed ESs on the same set of multi-homing PEs,
			the forwarding between the two ACs must be performed locally during
			normal operation (e.g., in absence of a local link failure). This
			means that traffic between the two ACs <bcp14>MUST</bcp14> be
			locally switched within the PE.</t>
			<t>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
			local ESI, the PE does not modify its forwarding state based on the
			received route. This approach ensures that local switching takes
			precedence over forwarding via the MPLS/IP network. This method of
			prioritizing locally switched traffic aligns with the baseline EVPN
			principles described in <xref target="RFC7432"/>, where locally
			switched preference is specified for MAC/IP routes.</t>
			<t>In such scenarios, the Ethernet A-D per-EVI route should be
			advertised with the MPLS label either associated with the
			destination AC or with the destination ES in order to
			avoid any ambiguity in forwarding. In other words, the MPLS label
			cannot represent the same VID-VRF outlined in <xref
			target="vlan_sig_fxc"/>, as the same normalized VID can be reachable
			via two ESs. In the 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 per <xref target="RFC8214"/>.</t>
			</section>
			</section>
			<section anchor="instantiation">
			<name>Service Instantiation</name>
			<t>The V field defined in <xref target="bgp_extensions"/> is
			<bcp14>OPTIONAL</bcp14>. However, if transmitted, its value may
			indicate an error condition that could lead to operational issues. In
			such cases, merely notifying the operator of an error is insufficient;
			the VPWS service tunnel must not be established.</t>
			<t>If both endpoints of a VPWS tunnel are signaling a matching
			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 V-bit facilitates the detection and prevention of this tunnel's
			instantiation.</t>
			<t>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 VID normalization applies only to the outer tag. Conversely,
			if double VID normalization is signaled in the Ethernet Tag ID field
			(24 bits), VID normalization applies to both the inner and outer
			tags.</t>
			</section>
			</section>
			<section anchor="bgp_extensions">
			<name>BGP Extensions</name>
			<t>This document uses the EVPN Layer 2 Attributes Extended Community as
			defined in <xref target="RFC8214"/> with two additional flags
			incorporated into this Extended Community (EC) as detailed below. This
			EC is sent with Ethernet A-D per-EVI route per <xref
			target="solution"/> and <bcp14>SHOULD</bcp14> be sent for both
			Single-Active and All-Active redundancy modes.</t>
	</section>		<artwork><![CDATA[
	<section title="Service Instantiation" anchor="instantiation">
	<t>The V field defined in <xref target="bgp_extensions"/> is OPTIONAL.
	However, if transmitted, its value may indicate an error condition that coul
	d lead to
	operational issues.
	In such cases, merely notifying the operator of an error is insufficient; the VP
	WS service tunnel
	must not be established.</t>
	<t>If both endpoints of a VPWS tunnel are signaling a matching Normalised VI
	D
	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 facilitates the detect
	ion and
	prevention of this tunnel's instantiation.</t>
	<t>If single VID normalization is signaled in the Ethernet Tag ID
	field (12 bits) yet dataplane is operating based on double tags,
	the VID normalization applies only to outer tag.
	Conversely, if double VID normalization is signaled in the Ethernet Tag ID
	field (24 bits), VID normalization applies to both the inner
	and outer tags.</t>
	</section>
	</section>
	<section title="BGP Extensions" anchor="bgp_extensions">
	<t>This draft uses the EVPN Layer-2 attribute extended community as defined
	in <xref target="RFC8214"/> with two additional flags incorporated into this E
	xtended Community
	(EC) as
	detailed below. This EC is sent with Ethernet A-D per EVI route per <xref targ
	et="solution"/>,
	and SHOULD be sent for both Single-Active and All-Active redundancy modes.
	<figure><artwork><![CDATA[
	+-------------------------------------------+		+-------------------------------------------+
	| 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) |
	+-------------------------------------------+		+-------------------------------------------+
	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)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]>		]]></artwork>
	</artwork></figure>
	</t>
	<t>The following bits in the Control Flags are defined; the remaining
	bits MUST be set to zero when sending and MUST be ignored when
	receiving this community.
	<figure><artwork><![CDATA[
	Name Meaning
	---------------------------------------------------------------
	B,P,C per definition in [RFC8214]
	M 00 mode of operation as defined in [RFC8214]
	01 VLAN-Signaled FXC
	10 Default FXC
	V 00 operating per [RFC8214]
	01 single-VID normalization
	10 double-VID normalization
	]]>
	</artwork></figure>
	</t>
	<t>The M and V fields are OPTIONAL. The M field is ignored at		<t>The following bits in the Control Flags are defined; the remaining
	reception for forwarding purposes and is used for error		bits <bcp14>MUST</bcp14> be set to zero when sending and
	notifications. </t>		<bcp14>MUST</bcp14> be ignored when receiving this community.</t>
	</section>
	<section title="Failure Scenarios" anchor="failure_scenarios">		<table>
	<t>Two examples will be used as an example to analyze the failure		<thead>
	scenarios.</t>		<tr>
			<th>Name</th>
			<th>Meaning</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>B,P,C</td>
			<td>per definition in <xref target="RFC8214"/></td>
			</tr>
			<tr>
			<td rowspan="3">M</td>
			<td>00 mode of operation as defined in <xref target="RFC8214"/></td>
			</tr>
			<tr>
			<td>01 VLAN-Signaled FXC </td>
			</tr>
			<tr>
			<td>10 Default FXC</td>
			</tr>
			<tr>
			<td rowspan="3">V</td>
			<td>00 operating per <xref target="RFC8214"/></td>
			</tr>
			<tr>
			<td>01 single-VID normalization</td>
			</tr>
			<tr>
			<td>10 double-VID normalization</td>
			</tr>
			</tbody>
			</table>
	<t>The first scenario is a default Flexible Xconnect with Multi-Homing		<t>The M and V fields are <bcp14>OPTIONAL</bcp14>. The M field is
	solution and it is depicted in <xref target="dflt_fig"/>. In this case, VID		ignored at reception for forwarding purposes and is used for error
	Normalization is performed and a single Ethernet A-D per EVI route is sent for		notifications. </t>
	the		</section>
	bundle of ACs on an ES. That is, PE1 will advertise two Ethernet A-D per EVI		<section anchor="failure_scenarios">
	routes: the first one will identify the ACs on port p1's ES and the second		<name>Failure Scenarios</name>
	one will identify the AC2 in port p2's ES. Similarly, PE2 will advertise		<t>The two following examples analyze the failure
	two Ethernet A-D per EVI routes.		scenarios.</t>
			<t>The first scenario is a default Flexible Cross-Connect with a multi-hom
			ing
			solution, and it is depicted in <xref target="dflt_fig"/>. In this case,
			VID 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 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 p2's
			ES. Similarly, PE2 will advertise two Ethernet A-D per-EVI routes.</t>
	<figure title="Default Flexible Xconnect" anchor="dflt_fig">		<figure anchor="dflt_fig">
	<artwork><![CDATA[		<name>Default Flexible Cross-Connect</name>
			<artwork><![CDATA[
	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 |----+
	\ / p2 +---------+ +======| | | 2 +-----+		\ / p2 +---------+ +======| | | 2 +-----+
	skipping to change at line 612 ¶		skipping to change at line 577 ¶
	/ /\ +---------+ +=====| | | | |		/ /\ +---------+ +=====| | | | |
	/ / \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 +-------------------+
	]]>		]]></artwork>
	</artwork></figure>		</figure>
	</t>		<t>The second scenario, depicted in <xref target="vlan_sig_fig"/>,
			illustrates the VLAN-signaled FXC mode with multi-homing. In this
	<t>The second scenario, depicted in <xref target="vlan_sig_fig"/>, illustrates		example:</t>
	the VLAN&nbhy;signaled FXC mode with Multi-Homing. In this example:
	<list style="symbols">
	<t>CE1 is connected to PE1 and PE2 via (port,VID)=(p1,1) and (p3,3),
	respectively. CE1's VIDs are normalized to value&nbsp;1 on both PEs, and
	CE1 is cross-connected to CE3's VID&nbsp;1 at the remote end.</t>
	<t>CE2 is connected to PE1 and PE2 via ports p2 and p4 respectively:
	<list style="symbols">
	<t>The combinations (p2,1) and (p4,3) identify the ACs used to cross-connec
	t
	CE2 to CE4's VID 2, and are normalized to value&nbsp;2.</t>
	<t>The combinations (p2,2) and (p4,4) identify the ACs used to cross-connec
	t
	CE2 to CE5's VID&nbsp;3, and are normalized to value&nbsp;3.</t>
	</list>
	</t>
	</list>
	In this scenario, PE1 and PE2 advertise an Ethernet A-D per EVI route for ea		<ul spacing="normal">
	ch		<li>CE1 is connected to PE1 and PE2 via (port,VID)=(p1,1) and (p3,3),
	normalized VID (values 1, 2 and 3). However, only two VPWS Service		respectively. CE1's VIDs are normalized to value 1 on both PEs, and
	Tunnels are required: VPWS Service Tunnel 1 (sv.T1) between PE1's FXC		CE1 is cross-connected to CE3's VID 1 at the remote end.</li>
	service and PE3's FXC, and VPWS Service Tunnel 2 (sv.T2) between		<li>
	PE2's FXC and PE3's FXC.		<t>CE2 is connected to PE1 and PE2 via ports p2 and p4, respectively:
			</t>
			<ul spacing="normal">
			<li>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.</li>
			<li>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.</li>
			</ul>
			</li>
			</ul>
			<t> 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 Service Tunnels are required: 1) VPWS Service Tunnel 1 (sv.T1)
			between PE1's FXC and PE3's FXC and 2) VPWS Service Tunnel 2 (sv.T2)
			between PE2's FXC and PE3's FXC.</t>
	<figure title="VLAN-Signaled Flexible Xconnect" anchor="vlan_sig_fig">		<figure anchor="vlan_sig_fig">
	<artwork><![CDATA[		<name>VLAN-Signaled FXC</name>
			<artwork><![CDATA[
	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 |----+
	\ / p2 +---------+ | | | | 2 +-----+		\ / p2 +---------+ | | | | 2 +-----+
	skipping to change at line 662 ¶		skipping to change at line 630 ¶
	/ /\ +---------+ +======| | | | |		/ /\ +---------+ +======| | | | |
	/ / \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 +------------------+
	]]>		]]></artwork>
	</artwork></figure>		</figure>
	</t>		<section anchor="evpws_svc_failure">
			<name>EVPN-VPWS Service Failure</name>
			<t>The failure detection of an EVPN-VPWS service can be performed via
			OAM mechanisms such as Bidirectional Forwarding Detection (BFD)
			for the pseudowire Virtual Circuit Connectivity Verification (VCCV)
			<xref target="RFC5885"/>, and upon such failure detection, the switch over pr
			ocedure
			to the backup PE is the same as the one described above.</t>
			</section>
			<section anchor="ac_failure">
			<name>Attachment Circuit Failure</name>
			<t>In the event of an AC failure, the VLAN-Signaled and default FXC
			modes exhibit distinct behaviors:</t>
			<ul spacing="normal">
			<li>Default FXC (<xref target="dflt_fig"/>): In the default mode, a
			VLAN or AC failure is not signaled. Consequently, in case of an AC
			failure, such as VID1 on CE2, there is nothing to prevent PE3 from
			directing traffic from CE4 to PE1, leading to a potential packet
			loss at the egress PE with a failed AC. Application layer OAM may be
			utilized if per-VLAN fault propagation is necessary in this
			scenario.</li>
			<li>VLAN-Signaled FXC (<xref target="vlan_sig_fig"/>): In the case
			of a VLAN or AC failure, such as VID1 on CE2, this triggers the withdr
			awal
			of the Ethernet A-D per-EVI route for the corresponding Normalized
			VID, specifically Ethernet-Tag 2. Upon receiving the route
			withdrawal, PE3 will remove PE1 from its outgoing adjacency list for
			traffic originating from CE4.</li>
			</ul>
			</section>
			<section anchor="pe_port_failure">
			<name>PE Port Failure</name>
			<t>In the event of a PE port failure, the failure will be signaled,
			and the other PE will assume forwarding in both scenarios:</t>
	<section title="EVPN VPWS Service Failure" anchor="evpws_svc_failure">		<ul spacing="normal">
	<t>The failure detection of an EVPN VPWS service can be performed via		<li>Default FXC (<xref target="dflt_fig"/>): In the case of a port
	OAM mechanisms such as VCCV-BFD (Bidirectional Forwarding Detection for the P		failure, such as p2, the route for Service Tunnel 2 (sv.T2) will be
	seudowire Virtual		withdrawn. Upon receiving the fault notification, PE3 will remove
	Circuit Connectivity Verification, <xref target="RFC5885"/>) and upon such fa		PE1 from its adjacency list for traffic originating from CE4 and
	ilure detection, the		CE5.</li>
	switch over procedure to the backup S-PE is the same as the one		<li>VLAN-Signaled FXC (<xref target="vlan_sig_fig"/>): A port
	described above.</t>		failure, such as p2, triggers the withdrawal of the Ethernet A-D per
	</section>		EVI routes for normalized 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 will remove PE1 from its adjacency list for the traf
			fic
			originating from CE4 and CE5.</li>
			</ul>
			</section>
			<section anchor="pe_node_failure">
			<name>PE Node Failure</name>
			<t>In the case of PE node failure, the operation is similar to the steps
			described above, albeit that EVPN route withdrawals are performed by
			the route reflector instead of the PE.</t>
			</section>
			</section>
			<section>
			<name>Security Considerations</name>
			<t>Since this document describes a muxing capability that leverages
			EVPN-VPWS signaling, no additional functionality beyond the muxing
			service is added, and thus no additional security considerations are
			needed beyond what is already specified in <xref target="RFC8214"/>.</t>
			</section>
			<section anchor="IANA">
			<name>IANA Considerations</name>
			<t>This document has allocated bits 8-11 in the
			"EVPN Layer 2 Attributes Control Flags" registry with names M and V:
			</t>
			<dl spacing="compact" newline="false">
			<dt>M</dt><dd>Signaling mode of operation (bits 10-11)</dd>
			<dt>V</dt><dd>VLAN-ID normalization (bits 8-9)</dd>
			</dl>
			</section>
			</middle>
	<section title="Attachment Circuit Failure" anchor="ac_failure">		<back>
	<t>In the event of an AC failure, the VLAN-Signaled and default FXC modes exh		<displayreference target="I-D.ietf-rtgwg-bgp-pic" to="BGP-PIC"/>
	ibit distinct		<references>
	behaviors:		<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
			119.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			174.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			432.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			214.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<!-- [I-D.ietf-rtgwg-bgp-pic] IESG State: Expired as of 01/09/25.
			Note to PE: Recommend changing the cite tag for this I-D to something more
			symbolic:
	<list style="symbols">		Current:
	<t>Default FXC (<xref target="dflt_fig"/>): in the default mode, a VLAN or A		[I-D.ietf-rtgwg-bgp-pic]
	C failure is not
	signaled. Consequently, in case of an AC failure such as VID1 on CE2, there
	is nothing to
	prevent PE3 from directing traffic from CE4 to PE1, leading to a potential b
	lack hole.
	Application layer Operations, Administration, and
	Maintenance (OAM) may be utilized if per-VLAN fault propagation is necessary in
	this scenario.</t>
	<t>VLAN-Signaled FXC (<xref target="vlan_sig_fig"/>): in the case of a VLAN		Perhaps:
	or AC failure such		[BGP-PIC]
	as VID1 on CE2, triggers the withdrawal of the Ethernet A-D per EVI route fo		-->
	r the		<reference anchor="I-D.ietf-rtgwg-bgp-pic" target="https://datatracker.ietf.org/
	corresponding Normalized VID, specifically Ethernet-Tag&nbsp;2. Upon receivi		doc/html/draft-ietf-rtgwg-bgp-pic-21">
	ng the route		<front>
	withdrawal, PE3 will remove PE1 from its outgoing path list for traffic orig		<title>BGP Prefix Independent Convergence</title>
	inating from CE4.</t>		<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy" role="editor"
	</list>		>
	</t>		<organization>Cisco Systems</organization>
	</section>		</author>
			<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
			<organization>Cisco Systems</organization>
			</author>
			<author fullname="Prodosh Mohapatra" initials="P." surname="Mohapatra">
			<organization>Sproute Networks</organization>
			</author>
			<date day="7" month="July" year="2024"/>
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-bgp-pic-21"/>
			</reference>
	<section title="PE Port Failure" anchor="pe_port_failure">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<t>In the event of a PE port failure, the failure will be signaled, and the		365.xml"/>
	other PE will assume forwarding in both scenarios:		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			659.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			885.xml"/>
			</references>
			</references>
	<list style="symbols">		<section numbered="false">
	<t>Default FXC (<xref target="dflt_fig"/>): In the case of a port failure, s		<name>Contributors</name>
	uch as p2, the route		<t>In addition to the authors listed on the front page, the following
	for Service&nbsp;Tunnel&nbsp;2 (sv.T2) will be withdrawn. Upon receiving the		co-authors have also contributed substantially to this document:</t>
	fault
	notification, PE3 will remove PE1 from its path list for traffic
	originating from CE4 and CE5.</t>
	<t>VLAN-Signaled FXC (<xref target="vlan_sig_fig"/>): A port failure, such a		<contact fullname="Wen Lin">
	s p2, triggers the		<organization>Juniper Networks</organization>
	withdrawal of the Ethernet A-D per EVI routes for Normalized VIDs 2 and 3, a		<address>
	long with the		<email>wlin@juniper.net</email>
	withdrawal of the Ethernet A-D per ES route for p2's ES. Upon		</address>
	receiving the fault notification, PE3 will remove PE1 from its		</contact>
	path list for the traffic originating from CE4 and CE5.</t>
	</list>
	</t>
	</section>
	<section title="PE Node Failure" anchor="pe_node_failure">		<contact fullname="Luc Andre Burdet">
	<t>In the case of PE node failure, the operation is similar to the steps		<organization>Cisco</organization>
	described above, albeit that EVPN route withdrawals are performed by		<address>
	the Route Reflector instead of the PE.</t>		<email>lburdet@cisco.com</email>
	</section>		</address>
			</contact>
	</section>		</section>
			</back>
	<section title="Security Considerations">		<!-- [rfced] Terminology
	<t>Since this document describes a muxing capability which leverages EVPN-VPWS
	signaling,
	no additional functionality beyond the muxing service is added and thus no add
	itional
	security considerations are needed beyond what is already specified in <xref t
	arget="RFC8214"/>.</t>
	</section>
	<section anchor="IANA" title="IANA Considerations">		A) To match usage in RFC 8214, may we update the following terms to the
	<t>This document requests allocation of bits 8-11 in the		format on the right?
	"EVPN Layer 2 Attributes Control Flags" registry with names M and V:
	<figure><artwork><![CDATA[
	M Signaling mode of operation (bits 10-11)
	V VLAN-ID normalization (bits 8-9)
	]]></artwork></figure>
	</t>
	</section>		single-active > Single-Active
			all-active > All-Active
			EVPN VPWS > EVPN-VPWS
			Ethernet A-D per EVI route > Ethernet A-D per-EVI route
			Ethernet A-D per ES route > Ethernet A-D per-ES route
			VLAN-bundle > VLAN bundle
	</middle>		B) Throughout the text, the following terminology appears to be used
			inconsistently. May we update them to the format on the right?
	<!-- *****BACK MATTER ***** -->		Normalized VID > normalized VID
			VLAN-signaled flexible cross-connect > VLAN-signaled FXC
			VLAN-signaled Flexible Cross-Connect > VLAN-signaled FXC
	<back>		C) Since RFC 8214 uses "EVPN Layer 2 Attributes Extended Community", should
	<!-- References split into informative and normative -->		the following terms be update to match? We ask because of the possible
	<references title="Normative References">		addition of "Attributes".
	<?rfc include="reference.RFC.2119.xml"?>
	<?rfc include="reference.RFC.8174.xml"?>
	<?rfc include="reference.RFC.7432.xml"?>
	<?rfc include="reference.RFC.8214.xml"?>
	</references>
	<references title="Informative References">		EVPN Layer 2 Extended Community (Sections 3.2 and 3.3)
	<?rfc include="reference.I-D.draft-ietf-rtgwg-bgp-pic-21.xml"?>		EVPN Layer 2 attribute extended community (Section 4)
	<?rfc include="reference.RFC.8365.xml"?>		-->
	<?rfc include="reference.RFC.5659.xml"?>
	<?rfc include="reference.RFC.5885.xml"?>
	</references>
	<!--		<!--[rfced] Abbreviations
	<section title="Acknowledgments">
	</section>
	-->
	<section title="Contributors">		A) FYI - We have added expansions for the following abbreviations
	<t>In addition to the authors listed on the front page, the following co		per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
	-authors		expansion in the document carefully to ensure correctness.
	have also contributed substantially to this document:
	</t>
	<t>Wen Lin<br/>Juniper Networks</t>		Autonomous System (AS)
	<t>EMail: wlin@juniper.net</t>		Switching Provider Edge (S-PE)
	<t>Luc Andre Burdet<br/>Cisco</t>		B) Both the expansion and the acronym for Ethernet Segment (ES) are used
	<t>EMail: lburdet@cisco.com</t>		throughout the document. Would you like to update to using the expansion upon
	</section>		first usage and the acronym for the rest of the document for consistency?
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers.
			For example, please consider whether the following should be updated:
			black hole
			block-holed
			-->
	</back>
	</rfc>		</rfc>
End of changes. 40 change blocks.
	760 lines changed or deleted		746 lines changed or added
This html diff was produced by rfcdiff 1.48.