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>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="EVPN VPWS Flexible Cross-Connect">EVPN VPWS Flexible Cross-Con
nect Service</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-vpws-fxc-12"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Ali Sajassi" initials="A." surname="Sajassi" role="editor">
<organization>Cisco Systems</organization>
<address>
<email>sajassi@cisco.com</email>
</address>
</author>
<author fullname="Patrice Brissette" initials="P." surname="Brissette">
<organization>Cisco Systems</organization>
<address>
<email>pbrisset@cisco.com</email>
</address>
</author>
<author fullname="James Uttaro" initials="J." surname="Uttaro">
<organization>AT&amp;T</organization>
<address>
<email>uttaro@att.com</email>
</address>
</author>
<author fullname="John Drake" initials="J." surname="Drake">
<organization>Juniper Networks</organization>
<address>
<email>jdrake@juniper.net</email>
</address>
</author>
<author fullname="Sami Boutros" initials="S." surname="Boutros">
<organization>Ciena</organization>
<address>
<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 <!-- [rfced] Please note that the title of the document has been updated as
the VPWS service tunnel to the remote Ethernet Segment using the ESI field, a follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
nd when the Style Guide"). Please review.
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> Original:
When a single VPWS service tunnel carries multiple ACs across various EVPN VPWS Flexible Cross-Connect Service
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 Current:
onto a single VPWS service tunnel, two mechanisms have been EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC)
developed: one to support VPWS services between two single-homed Service
endpoints, and another to support VPWS services where one of -->
the endpoints is multi-homed.</t>
<t> <front>
For single-homed endpoints, it is acceptable not to signal each AC <title abbrev="EVPN VPWS FXC Service">EVPN Virtual Private Wire
in BGP because, in the event of a connection failure to the ES, there Service (VPWS) Flexible Cross-Connect (FXC) Service</title>
is no alternative path to that endpoint. However, the implication <seriesInfo name="RFC" value="9744"/>
of not signaling an AC failure is that the traffic destined for <author fullname="Ali Sajassi" initials="A." surname="Sajassi" role="editor"
the failed AC is sent over the MPLS/IP core and then discarded at >
the destination PE, thereby potentially wasting network resources. <organization>Cisco Systems</organization>
<br/> <address>
This waste of network resources during a connection failure may <email>sajassi@cisco.com</email>
be transient, as it can be detected and prevented at the application </address>
layer in certain cases. <xref target="fxc"/> outlines a solution for such </author>
single-homing VPWS services.</t> <author fullname="Patrice Brissette" initials="P." surname="Brissette">
<organization>Cisco Systems</organization>
<address>
<email>pbrisset@cisco.com</email>
</address>
</author>
<author fullname="James Uttaro" initials="J." surname="Uttaro">
<organization>AT&amp;T</organization>
<address>
<email>uttaro@att.com</email>
</address>
</author>
<author fullname="John Drake" initials="J." surname="Drake">
<organization>Juniper Networks</organization>
<address>
<email>jdrake@juniper.net</email>
</address>
</author>
<author fullname="Sami Boutros" initials="S." surname="Boutros">
<organization>Ciena</organization>
<address>
<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="2025" month="February"/>
<t> <area>RTG</area>
For VPWS services where one of the endpoints is multi-homed, there <workgroup>bess</workgroup>
are two options: </t>
<t>1) to signal each AC via BGP, allowing the path list to be updated upon a <keyword>EVPN</keyword>
failure affecting those ACs. This solution is described in <xref target="vlan_si <keyword>VPWS</keyword>
g_fxc"/> and <keyword>Flexible Cross Connect</keyword>
is referred to as the VLAN-signaled flexible cross-connect service.</t> <keyword>FXC</keyword>
<t>2) to bundle several ACs on an ES together per destination endpoint <abstract>
(e.g., ES, MAC-VRF, etc.) and associate such a bundle with a single <t>This document describes a new EVPN Virtual Private Wire Service (VPWS)
VPWS service tunnel. This approach is similar to the VLAN-bundle service type specifically for
service interface described in <xref target="RFC8214"/>. This solution is descri multiplexing multiple attachment circuits across different Ethernet
bed Segments and physical interfaces into a single EVPN VPWS service tunnel
in <xref target="fxc_mh"/>.</t> and still providing Single-Active and All-Active multi-homing. This new
service is referred to as the EVPN VPWS Flexible Cross-Connect (FXC) servi
ce.
This document specifies a solution based on extensions to EVPN VPWS (RFC
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>
</section> </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"/>.
<section title="Solution" anchor="solution"> <!-- [rfced] We're having trouble understanding "can designate on" in the
text below. Should this be updated to "can designate"?
<t> Original:
This section specifies how to provide a new VPWS service [RFC8214] describes a solution to deliver P2P services using BGP
between two PE devices where a large number of ACs (such as VLANs) that constructs defined in [RFC7432]. It delivers this P2P service
span across multiple Ethernet Segments (physical interfaces) on each between a pair of Attachment Circuits (ACs), where an AC can
PE are multiplexed onto a single P2P EVPN service tunnel. Since the designate on a PE, a port, a VLAN on a port, or a group of VLANs on a
multiplexing involves several physical interfaces, there can be port.
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> Perhaps:
When a single normalized VID is used, the lower 12 bits of the Ethernet [RFC8214] describes a solution to deliver P2P services using BGP
Tag ID field in EVPN routes MUST be set to that VID. When a double normalized constructs defined in [RFC7432]. It delivers this P2P service
VID is used, the lower 12 bits of the Ethernet Tag ID field MUST be set to between a pair of Attachment Circuits (ACs), where an AC can
the inner VID, while the higher 12 bits are set to the outer VID. As designate a PE, a port, a VLAN on a port, or a group of VLANs on a
stated in <xref target="RFC8214"/>, 12-bit and 24-bit VPWS service instance iden port.
tifiers -->
representing normalized VIDs MUST be right-aligned.</t>
<t> It delivers
Since there is only a single EVPN VPWS service tunnel associated with this P2P service between a pair of Attachment Circuits (ACs), where an
many normalized VIDs (either single or double) across multiple AC can designate on a Provider Edge (PE), a port, a VLAN on a port, or a g
physical interfaces, an MPLS lookup at the disposition PE is no roup of VLANs
longer sufficient to forward the packet to the correct egress on a port. It also leverages multi-homing and fast convergence
endpoint or interface. Therefore, in addition to an EVPN label capabilities of <xref target="RFC7432"/> in delivering these VPWS
lookup corresponding to the VPWS service tunnel, a VID lookup services. Multi-homing capabilities include the support of single-active
(either single or double) is also required. At the disposition and all-active redundancy mode, and fast convergence is provided using a
PE, the EVPN label lookup identifies a VID-VRF, and the lookup "mass withdrawal" message in control plane and fast protection switching
of the normalized VID(s) within that table identifies the appropriate using prefix-independent convergence in a data plane upon node or link
egress endpoint or interface. The tag manipulation (translation from failure <xref target="I-D.ietf-rtgwg-bgp-pic"/>. Furthermore, the use
normalized VID(s) to the local VID) SHOULD be performed either as of EVPN BGP constructs eliminates the need for multi-segment pseudowire
part of the VID table lookup or at the egress interface itself.</t> 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
Ethernet Segments) 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>
<t> <!--[rfced] To have a 1:1 matchup between the following abbreviations
Since the VID lookup (single or double) needs to be performed at the and their expansions, may we update as follows?
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"> Original:
<t>In <xref target="RFC8214"/>, a unique value identifying the service is si Ethernet A-D: Ethernet Auto-Discovery (A-D) per EVI and Ethernet A-D
gnaled in the context of each PE's per ESI routes, as defined in [RFC7432] and [RFC8214].
EVI. The 32-bit Ethernet Tag ID field MUST be set to this ...
VPWS service instance identifier value. Translation at an Autonomous System PE: Provider Edge device
Border Router (ASBR) is needed if re-advertising to ...
another AS affects uniqueness.</t> VRF: VPN Routing and Forwarding table
...
IP-VRF: VPN Routing and Forwarding table, for IP lookup
...
MAC-VRF: VPN Routing and Forwarding table, for MAC lookup
...
VID-VRF: VPN Routing and Forwarding table, for Normalized VID lookup
<t>For FXC, this same Ethernet Tag ID field value is an identifier which may Perhaps:
represent: Ethernet A-D: Ethernet Auto-Discovery (per EVI and per ESI routes,
<list style="symbols"> as defined in [RFC7432] and [RFC8214])
<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 PE: Provider Edge
s, and is ...
considered same as the normalized VID.</t> VRF: VPN Routing and Forwarding
</list> ...
</t> IP-VRF: VPN Routing and Forwarding for IP lookup
<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"> MAC-VRF: VPN Routing and Forwarding for MAC lookup
<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 VID-VRF: VPN Routing and Forwarding for normalized VID lookup
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 <dt>Ethernet A-D:</dt>
is employed to multiplex ACs across various Ethernet <dd>Ethernet Auto-Discovery per EVI and Ethernet A-D per ESI
Segments (ESs) or physical interfaces, the EVPN label alone is not sufficient fo routes, as defined in <xref target="RFC7432"/> and <xref
r accurate forwarding of the target="RFC8214"/>.</dd>
received packets over the MPLS/IP network to egress interfaces. <dt>FXC:</dt>
Therefore, normalized VID lookup is REQUIRED in the disposition <dd>Flexible Cross Connect</dd>
direction to forward packets to their proper egress end-points; the EVPN labe <dt>MAC:</dt>
l lookup identifies <dd>Media Access Control</dd>
a VID-VRF, and a subsequent normalized VID lookup in that table identifies th <dt>MPLS:</dt>
e egress <dd>Multiprotocol Label Switching</dd>
interface.</t> <dt>OAM:</dt>
<dd>Operations, Administration, and Maintenance</dd>
<dt>PE:</dt>
<dd>Provider Edge device</dd>
<dt>VCCV:</dt>
<dd>Virtual Circuit Connection 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 table</dd>
<dt>IP-VRF:</dt>
<dd>VPN Routing and Forwarding table, for IP lookup</dd>
<dt>MAC-VRF:</dt>
<dd>VPN Routing and Forwarding table, for MAC lookup</dd>
<dt>VID-VRF:</dt>
<dd>VPN Routing and Forwarding table, 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 anchor="requirements">
<name>Requirements</name>
<t>Two of the main motivations for service providers seeking a new
solution are: 1) to reduce the number of VPWS service tunnels by
multiplexing a 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 the multi-homing and fast convergence capabilities of
<xref target="RFC8214"/>.</t>
<t>In <xref target="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 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 identifier (which is unique within the EVI) and the 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. Additionally, when the remote ES fails and the PE receives the
"mass withdrawal" message associated with the failed ES per <xref
target="RFC7432"/>, a PE device can quickly update its BGP list of availab
le
remote entries to invalidate all VPWS service tunnels sharing the ESI
field and achieve fast convergence for multi-homing scenarios. Even if
fast convergence was 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 a 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 the absence of updating the
BGP path list, the traffic for that VPWS service tunnel will be
black-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.</t>
<t>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 one t
o
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.</t>
<t>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>
<ol spacing="normal" type="1">
<li>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_sig_fxc"/> and is referred to as the "VLAN-signaled
flexible cross-connect service".</li>
<li>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 described in <xref target="fxc_mh"/>.</li>
</ol>
</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 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 (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>In this solution, for each PE, the single-homing ACs represented by <!-- [rfced] We were unable to find exactly "12-bit VPWS service instance
their normalized VIDs are associated with a single VPWS service instance with identifiers" in [RFC8214]. We did find the following in Section 3 of [RFC8214]:
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; The VPWS service instance identifier value MAY be set to a 24-bit value,
A-D per EVI and when a 24-bit value is used, it MUST be right-aligned.
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"> For a more accurate citation, may we update to something like the following?
<t>The default FXC mode can also be used for multi-homing. In this mode, a Current:
group of normalized VIDs representing ACs on a single Ethernet Segment, all As stated in [RFC8214], 12-bit and 24-bit VPWS service instance identifiers
destined to a single endpoint, are multiplexed into a single EVPN VPWS representing normalized VIDs MUST be right-aligned.
service tunnel which is identified by a unique VPWS service ID.
When employing the default FXC mode for multi-homing, rather than using a si
ngle 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 PE
s, and there can be
many such groups between a pair of PEs, resulting in numerous EVPN service t
unnels.</t>
</section> Perhaps:
24-bit VPWS service instance identifiers [RFC8214] as well as 12-bit
VPWS service instance identifiers representing normalized VIDs MUST
be right-aligned.
-->
</section> <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. As stated in <xref
target="RFC8214"/>, 12-bit and 24-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 Xconnect</name>
<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
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 Ethernet Segments (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"/>.
<section title="VLAN-Signaled Flexible Xconnect" anchor="vlan_sig_fxc"> <!--[rfced] To clarify the numbered list, we have updated this sentence
<t>In this mode of operation, similar to the default FXC mode described in <x in Section 3.2. Please review and ensure that the intended meaning has
ref target="fxc"/>, not changed. Note that we have made a similar update to a sentence in
many normalized VIDs representing ACs across several Ethernet Segments/interf Section 3.3.
aces 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 Original:
their normalized VIDs are configured with a single EVI. There is no Additionally, this route
need to configure a separate VPWS service instance ID in here, as it correspo is sent with the EVPN Layer-2 Extended Community defined in
nds to the Section 3.1 of [RFC8214] with two new flags (outlined in Section 4)
normalized VID. For each normalized VID on each Ethernet Segment, the PE that indicate: 1) this VPWS service tunnel is for the default
generates an Ethernet A-D per EVI route where the ESI field Flexible Cross-Connect, and 2) the normalized VID type (single versus
represents the ES ID, the Ethernet Tag field is set to the normalized double).
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 a Route Target (RT) representing the EVI. As
before, this RT can be auto-generated from the EVI per section
<relref target="RFC8365" section="5.1.2.1"/>. Additionally, this route includ
es the
EVPN Layer-2 Extended Community defined in <relref target="RFC8214" section="
3.1"/>
with two new flags (outlined in <xref target="bgp_extensions"/>) that indicat
e: 1) this VPWS
service tunnel is for VLAN-signaled 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 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 Current:
single Ethernet A-D per EVI route for each AC that is configured. Each Additionally, this route
normalized VID that is configured per ES results in generation of an Ethernet is sent with the EVPN Layer 2 Extended Community defined in
A-D per EVI.</t> Section 3.1 of [RFC8214] with two new flags (outlined in Section 4)
that indicate: 1) this VPWS service tunnel for the default
Flexible Cross-Connect and 2) the normalized VID type (single versus
double).
-->
<t>This mode of operation enabled automatic cross-checking of Additionally, this route is sent with the EVPN Layer 2 Extended
normalized VIDs used for Ethernet Virtual Private Line (EVPL) services becaus Community defined in <xref target="RFC8214" section="3.1" sectionFormat=
e these VIDs are "of"/> with two
signaled in EVPN BGP. For instance, if the same normalized VID is new flags (outlined in <xref target="bgp_extensions"/>) that indicate:
configured on three PE devices (instead of two) for the same EVI, 1) this VPWS service tunnel for the default Flexible Cross-Connect
then when a PE receives the second remote Ethernet A-D per EVI route, it and 2) the normalized VID type (single versus double). The receiving
generates an error message unless the two Ethernet A-D per EVI routes PE uses these new flags for a consistency check and <bcp14>MAY</bcp14>
include the same ESI. Such cross-checking is not feasible in the default generate an alarm if it detects inconsistencies, but it will not
FXC mode because the normalized VIDs are not signaled.</t> 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 Ethernet
Segment, 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 Flexible Xconnect</name>
<section title="Local Switching" anchor="local_switch"> <!--[rfced] Please note that a slash (/) can mean "and", "or", or "and/or".
<t>When cross-connection occurs between two ACs belonging to two multi-homed We have updated it to "and" in the text below for clarity. Please review
Ethernet Segments on the same set of multi-homing PEs, the and let us know if any further updates are needed.
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 MUST be locally switched within the
PE.</t>
<t>In terms of control plane processing, this means that when the Original:
receiving PE processes an Ethernet A-D per EVI route whose ESI is a In this mode of operation, similar to the default FXC mode described
local ESI, the PE does not modify its forwarding state based on the in Section 3.2, many normalized VIDs representing ACs across several
received route. This approach ensures that local switching takes Ethernet Segments/interfaces are multiplexed into a single EVPN VPWS
precedence over forwarding via the MPLS/IP network. service tunnel.
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/&wj;IP routes.</t>
<t>In such scenarios, the Ethernet A-D per EVI route should be Current:
advertised with the MPLS label either associated with the destination In this mode of operation, similar to the default FXC mode described
Attachment Circuit or with the destination Ethernet Segment in order in Section 3.2, many normalized VIDs representing ACs across several
to avoid any ambiguity in forwarding. In other words, the MPLS label Ethernet Segments and interfaces are multiplexed into a single EVPN VPWS
cannot represent the same VID-VRF outlined in <xref target="vlan_sig_fxc"/>, service tunnel.
as the same normalized VID can be reachable via two Ethernet Segments. -->
In the case of using an MPLS label per destination AC, this approach can als
o be applied to
VLAN-based VPWS or VLAN-bundle VPWS services as per
<xref target="RFC8214"/>.</t>
<t>In this mode of operation, similar to the default FXC mode
described in <xref target="fxc"/>, many normalized VIDs representing
ACs across several Ethernet Segments 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
Ethernet Segment, the PE generates an Ethernet A-D per EVI route where
the ESI field represents the ES ID, the Ethernet Tag field is 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 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 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
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 Ethernet Segments 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 Ethernet Segment 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 Ethernet Segments. 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>
<section anchor="bgp_extensions">
<name>BGP Extensions</name>
<t>This document uses the EVPN Layer 2 attribute 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 Xconnect with a multi-homing
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 Xconnect</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 700
/ /\ +---------+ +=====| | | | | / /\ +---------+ +=====| | | | |
/ / \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
example:</t>
<t>The second scenario, depicted in <xref target="vlan_sig_fig"/>, illustrates <ul spacing="normal">
the VLAN&nbhy;signaled FXC mode with Multi-Homing. In this example: <li>CE1 is connected to PE1 and PE2 via (port,VID)=(p1,1) and (p3,3),
respectively. CE1's VIDs are normalized to value 1 on both PEs, and
CE1 is cross-connected to CE3's VID 1 at the remote end.</li>
<li>
<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).
<list style="symbols"> <!--[rfced] May we remove "service" after "FXC" in the following sentence?
<t>CE1 is connected to PE1 and PE2 via (port,VID)=(p1,1) and (p3,3), Additionally, please note that we have numbered the items listed to
respectively. CE1's VIDs are normalized to value&nbsp;1 on both PEs, and improve readability.
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: Original:
<list style="symbols"> However, only two VPWS
<t>The combinations (p2,1) and (p4,3) identify the ACs used to cross-connec Service Tunnels are required: VPWS Service Tunnel 1 (sv.T1) between
t PE1's FXC service and PE3's FXC, and VPWS Service Tunnel 2 (sv.T2)
CE2 to CE4's VID 2, and are normalized to value&nbsp;2.</t> between PE2's FXC and PE3's FXC.
<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 Perhaps:
ch However, only two VPWS
normalized VID (values 1, 2 and 3). However, only two VPWS Service Service Tunnels are required: 1) VPWS Service Tunnel 1 (sv.T1) between
Tunnels are required: VPWS Service Tunnel 1 (sv.T1) between PE1's FXC PE1's FXC and PE3's FXC and 2) VPWS Service Tunnel 2 (sv.T2)
service and PE3's FXC, and VPWS Service Tunnel 2 (sv.T2) between between PE2's FXC and PE3's FXC.
PE2's FXC and PE3's FXC. -->
<figure title="VLAN-Signaled Flexible Xconnect" anchor="vlan_sig_fig"> However, only two
<artwork><![CDATA[ VPWS service tunnels are required: 1) VPWS Service Tunnel 1 (sv.T1) betwee
n
PE1's FXC service and PE3's FXC and 2) VPWS Service Tunnel 2 (sv.T2)
between PE2's FXC and PE3's FXC.</t>
<figure anchor="vlan_sig_fig">
<name>VLAN-Signaled Flexible Xconnect</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 772
/ /\ +---------+ +======| | | | | / /\ +---------+ +======| | | | |
/ / \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>
<section title="EVPN VPWS Service Failure" anchor="evpws_svc_failure"> <!--[rfced] May we update the following acronyms and their expansions
<t>The failure detection of an EVPN VPWS service can be performed via to better reflect the text in RFC 5885?
OAM mechanisms such as VCCV-BFD (Bidirectional Forwarding Detection for the P
seudowire Virtual
Circuit Connectivity Verification, <xref target="RFC5885"/>) and upon such fa
ilure detection, the
switch over procedure to the backup S-PE is the same as the one
described above.</t>
</section>
<section title="Attachment Circuit Failure" anchor="ac_failure"> Original:
<t>In the event of an AC failure, the VLAN-Signaled and default FXC modes exh The failure detection of an EVPN VPWS service can be performed via
ibit distinct OAM mechanisms such as VCCV-BFD (Bidirectional Forwarding Detection
behaviors: for the Pseudowire Virtual Circuit Connectivity Verification,
[RFC5885]) and upon such failure detection, the switch over procedure
to the backup S-PE is the same as the one described above.
<list style="symbols"> Perhaps:
<t>Default FXC (<xref target="dflt_fig"/>): in the default mode, a VLAN or A The failure detection of an EVPN VPWS service can be performed via
C failure is not OAM mechanisms such as Bidirectional Forwarding Detection (BFD)
signaled. Consequently, in case of an AC failure such as VID1 on CE2, there for the pseudowire Virtual Circuit Connectivity Verification (VCCV)
is nothing to [RFC5885], and upon such failure detection, the switch over procedure
prevent PE3 from directing traffic from CE4 to PE1, leading to a potential b to the backup S-PE is the same as the one described above.
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 <t>The failure detection of an EVPN VPWS service can be performed via
or AC failure such OAM mechanisms such as VCCV-BFD (Bidirectional Forwarding Detection
as VID1 on CE2, triggers the withdrawal of the Ethernet A-D per EVI route fo for the Pseudowire Virtual Circuit Connectivity Verification) <xref
r the target="RFC5885"/>, and upon such failure detection, the switchover
corresponding Normalized VID, specifically Ethernet-Tag&nbsp;2. Upon receivi procedure to the backup Switching Provider Edge (S-PE) is the same as th
ng the route e one described
withdrawal, PE3 will remove PE1 from its outgoing path list for traffic orig above.</t>
inating from CE4.</t> </section>
</list> <section anchor="ac_failure">
</t> <name>Attachment Circuit Failure</name>
</section> <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 black
hole. 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 path 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="PE Port Failure" anchor="pe_port_failure"> <ul spacing="normal">
<t>In the event of a PE port failure, the failure will be signaled, and the <li>Default FXC (<xref target="dflt_fig"/>): In the case of a port
other PE will assume forwarding in both scenarios: failure, such as p2, the route for Service Tunnel 2 (sv.T2) will be
withdrawn. Upon receiving the fault notification, PE3 will remove
PE1 from its path list for traffic originating from CE4 and
CE5.</li>
<li>VLAN-Signaled FXC (<xref target="vlan_sig_fig"/>): A port
failure, such as p2, triggers 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 route for p2's ES. Upon receiving the fault
notification, PE3 will remove PE1 from its path list for the traffic
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>
<list style="symbols"> <back>
<t>Default FXC (<xref target="dflt_fig"/>): In the case of a port failure, s <displayreference target="I-D.ietf-rtgwg-bgp-pic" to="BGP-PIC"/>
uch as p2, the route <references>
for Service&nbsp;Tunnel&nbsp;2 (sv.T2) will be withdrawn. Upon receiving the <name>References</name>
fault <references>
notification, PE3 will remove PE1 from its path list for traffic <name>Normative References</name>
originating from CE4 and CE5.</t> <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:
<t>VLAN-Signaled FXC (<xref target="vlan_sig_fig"/>): A port failure, such a Current:
s p2, triggers the [I-D.ietf-rtgwg-bgp-pic]
withdrawal of the Ethernet A-D per EVI routes for Normalized VIDs 2 and 3, a
long 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
path list for the traffic originating from CE4 and CE5.</t>
</list>
</t>
</section>
<section title="PE Node Failure" anchor="pe_node_failure"> Perhaps:
<t>In the case of PE node failure, the operation is similar to the steps [BGP-PIC]
described above, albeit that EVPN route withdrawals are performed by -->
the Route Reflector instead of the PE.</t> <reference anchor="I-D.ietf-rtgwg-bgp-pic" target="https://datatracker.ietf.org/
</section> doc/html/draft-ietf-rtgwg-bgp-pic-21">
<front>
<title>BGP Prefix Independent Convergence</title>
<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy" role="editor"
>
<organization>Cisco Systems</organization>
</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> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
365.xml"/>
<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>
<section title="Security Considerations"> <section numbered="false">
<t>Since this document describes a muxing capability which leverages EVPN-VPWS <name>Contributors</name>
signaling, <t>In addition to the authors listed on the front page, the following
no additional functionality beyond the muxing service is added and thus no add co-authors have also contributed substantially to this document:</t>
itional
security considerations are needed beyond what is already specified in <xref t
arget="RFC8214"/>.</t>
</section>
<section anchor="IANA" title="IANA Considerations"> <contact fullname="Wen Lin">
<t>This document requests allocation of bits 8-11 in the <organization>Juniper Networks</organization>
"EVPN Layer 2 Attributes Control Flags" registry with names M and V: <address>
<figure><artwork><![CDATA[ <email>wlin@juniper.net</email>
M Signaling mode of operation (bits 10-11) </address>
V VLAN-ID normalization (bits 8-9) </contact>
]]></artwork></figure>
</t>
</section> <contact fullname="Luc Andre Burdet">
<organization>Cisco</organization>
<address>
<email>lburdet@cisco.com</email>
</address>
</contact>
</middle> </section>
</back>
<!-- *****BACK MATTER ***** --> <!-- [rfced] Terminology
<back> A) To match usage in RFC 8214, may we update the following terms to the
<!-- References split into informative and normative --> format on the right?
<references title="Normative References">
<?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"> single-active > Single-Active
<?rfc include="reference.I-D.draft-ietf-rtgwg-bgp-pic-21.xml"?> all-active > All-Active
<?rfc include="reference.RFC.8365.xml"?> EVPN VPWS > EVPN-VPWS
<?rfc include="reference.RFC.5659.xml"?> Ethernet A-D per EVI route > Ethernet A-D per-EVI route
<?rfc include="reference.RFC.5885.xml"?> Ethernet A-D per ES route > Ethernet A-D per-ES route
</references> VLAN-bundle > VLAN bundle
<!-- B) Throughout the text, the following terminology appears to be used
<section title="Acknowledgments"> inconsistently. May we update them to the format on the right?
</section>
-->
<section title="Contributors"> Normalized VID > normalized VID
<t>In addition to the authors listed on the front page, the following co VLAN-signaled flexible cross-connect > VLAN-signaled FXC
-authors VLAN-signaled Flexible Cross-Connect > VLAN-signaled FXC
have also contributed substantially to this document:
</t>
<t>Wen Lin<br/>Juniper Networks</t> C) Since RFC 8214 uses "EVPN Layer 2 Attributes Extended Community", should
<t>EMail: wlin@juniper.net</t> the following terms be update to match? We ask because of the possible
addition of "Attributes".
<t>Luc Andre Burdet<br/>Cisco</t> EVPN Layer 2 Extended Community (Sections 3.2 and 3.3)
<t>EMail: lburdet@cisco.com</t> EVPN Layer 2 attribute extended community (Section 4)
</section> -->
<!--[rfced] Abbreviations
A) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Autonomous System (AS)
Switching Provider Edge (S-PE)
B) Both the expansion and the acronym for Ethernet Segment (ES) are used
throughout the document. Would you like to update to using the expansion upon
first usage and the acronym for the rest of the document for consistency?
C) We note that "FXC" appears to be expanded in different ways throughout
the document. May we update all these instances to be "Flexible Cross-Connect"
for consistency?
Flexible Xconnect
Flexible Cross Connect
Flexible Cross-Connect
D) We note that "VCCV" is expanded in two different ways in this document.
Please review and let us know which version should be updated for
consistency.
Virtual Circuit Connectivity Verification
Virtual Circuit Connection Verification
-->
<!-- [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. 69 change blocks. 
733 lines changed or deleted 898 lines changed or added

This html diff was produced by rfcdiff 1.48.