rfc9784xml2.original.xml   rfc9784.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;">
]> ]>
<!-- If further character entities are required then they should be added to the
DOCTYPE above.
Use of an external entity file is not recommended. -->
<?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-virtual-eth-segment-19" number="9784" obsoletes="" updates="" conse
nsus="true" submissionType="IETF" ipr="trust200902" tocInclude="true" tocDepth="
4" symRefs="true" sortRefs="true" version="3" xml:lang="en">
<?rfc compact="yes" ?> <!--[rfced] To align with the Abstract/Introduction, we made
<!-- do not start each main section on a new page --> "Virtual Ethernet Segment" plural in the document title and the
<?rfc subcompact="no" ?> short title (which appears in the running header of the PDF).
<!-- keep one blank line between list items --> Please let us know of any changes.
<rfc category="std" Additionally, please consider if "Provider Backbone Bridge EVPN"
xmlns:xi="http://www.w3.org/2001/XInclude" should be included in the document title per the scope. And for
docName="draft-ietf-bess-evpn-virtual-eth-segment-19" clarity, would it be correct for "Solutions", "Requirements", or
obsoletes="" other to be included?
updates=""
consensus="true"
submissionType="IETF"
ipr="trust200902"
tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true">
<!-- ***** FRONT MATTER ***** --> Original:
EVPN Virtual Ethernet Segment
<front> Current:
<!-- The abbreviated title is used in the page header - it is only necessary EVPN Virtual Ethernet Segments
if the
full title is longer than 39 characters -->
<title abbrev="EVPN Virtual Ethernet Segment"> EVPN Virtual Ethernet Segment Perhaps:
</title> EVPN and Provider Backbone Bridge EVPN Solutions for
Virtual Ethernet Segments
-->
<author initials="A" surname="Sajassi" fullname="Ali Sajassi"> <front>
<organization>Cisco Systems</organization> <title abbrev="EVPN Virtual Ethernet Segments"> EVPN Virtual Ethernet Segmen
<address> ts </title>
<email>sajassi@cisco.com</email> <seriesInfo name="RFC" value="9784"/>
</address> <author initials="A" surname="Sajassi" fullname="Ali Sajassi">
</author> <organization>Cisco Systems</organization>
<author initials="P" surname="Brissette" fullname="Patrice Brissette"> <address>
<organization>Cisco Systems</organization> <email>sajassi@cisco.com</email>
<address> </address>
<email>pbrisset@cisco.com</email> </author>
</address> <author initials="P" surname="Brissette" fullname="Patrice Brissette">
</author> <organization>Cisco Systems</organization>
<author initials="R" surname="Schell" fullname="Rick Schell"> <address>
<organization>Verizon</organization> <email>pbrisset@cisco.com</email>
<address> </address>
<email>richard.schell@verizon.com</email> </author>
</address> <author initials="R" surname="Schell" fullname="Rick Schell">
</author> <organization>Verizon</organization>
<author initials="J" surname="Drake" fullname="John E Drake"> <address>
<organization>Juniper</organization> <email>richard.schell@verizon.com</email>
<address> </address>
<email>jdrake@juniper.net</email> </author>
</address> <author initials="J" surname="Drake" fullname="John E Drake">
</author> <organization>Juniper</organization>
<author initials="J" surname="Rabadan" fullname="Jorge Rabadan"> <address>
<organization>Nokia</organization> <email>jdrake@juniper.net</email>
<address> </address>
<email>jorge.rabadan@nokia.com</email> </author>
</address> <author initials="J" surname="Rabadan" fullname="Jorge Rabadan">
</author> <organization>Nokia</organization>
<address>
<email>jorge.rabadan@nokia.com</email>
</address>
</author>
<date year="2025" month="May"/>
<area>RTG</area>
<workgroup>bess</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
<date year="2024"/>
<area>Routing</area>
<workgroup>BESS WorkGroup</workgroup>
<abstract> <abstract>
<t> <t>
Ethernet VPN (EVPN) and Provider Backbone EVPN (PBB-EVPN) introduce a Ethernet VPN (EVPN) and Provider Backbone Bridge EVPN (PBB-EVPN) introduce a
comprehensive suite of solutions for delivering Ethernet services over comprehensive suite of solutions for delivering Ethernet services over
MPLS/IP networks. These solutions offer advanced MPLS/IP networks. These solutions offer advanced
multi-homing capabilities. Specifically, they support Single-Active and multi-homing capabilities. Specifically, they support Single-Active and
All-Active redundancy modes for an Ethernet Segment (ES), which is defined All-Active redundancy modes for an Ethernet Segment (ES), which is defined
as a collection of physical links connecting a multi-homed device or network as a collection of physical links connecting a multi-homed device or network
to a set of Provider Edge (PE) devices. This document extends the concept of to a set of Provider Edge (PE) devices. This document extends the concept of
an Ethernet Segment by allowing an ES to be associated with a set of Ethernet an Ethernet Segment by allowing an ES to be associated with a set of Ethernet
Virtual Circuits (EVCs, such as VLANs) or other entities, including MPLS Labe Virtual Circuits (EVCs), such as VLANs, or other entities, including MPLS Lab
l el
Switched Paths (LSPs) or Pseudowires (PWs). This extended concept is referred Switched Paths (LSPs) or pseudowires (PWs). This extended concept is referred
to as virtual Ethernet Segments (vES). This draft list the requirements to as virtual Ethernet Segments (vESes). This document lists the requirements
and specifies the necessary extensions to support vES in both EVPN and PBB-EV PN. and specifies the necessary extensions to support vES in both EVPN and PBB-EV PN.
</t> </t>
</abstract> </abstract>
</front>
</front>
<!-- ***** MIDDLE MATTER ***** -->
<middle> <middle>
<section title="Introduction"> <section>
<t> Ethernet VPN (EVPN, <xref target="RFC7432"/>) and Provider Backbone EVPN <name>Introduction</name>
(PBB-EVPN, <xref target="RFC7623"/>)) introduce <t> Ethernet VPN (EVPN) <xref target="RFC7432"/> and Provider Backbone Bri
dge EVPN
(PBB-EVPN) <xref target="RFC7623"/> introduce
a comprehensive suite of solutions for delivering Ethernet services a comprehensive suite of solutions for delivering Ethernet services
over MPLS/IP networks. These solutions offer advanced over MPLS/IP networks. These solutions offer advanced
multi-homing capabilities. Specifically, they support Single-Active and multi-homing capabilities. Specifically, they support Single-Active and
All-Active redundancy modes for an Ethernet Segment (ES). As defined in All-Active redundancy modes for an Ethernet Segment (ES). As defined in
<xref target="RFC7432"/>, an Ethernet Segment (ES) represents a collection of <xref target="RFC7432"/>, an ES represents a collection of
Ethernet links that connect a customer site to one or more PEs devices. </t> Ethernet links that connect a customer site to one or more Provider Edge (PE)
devices. </t>
<t> This document extends the concept of an Ethernet Segment by allowing an E <t> This document extends the concept of an Ethernet Segment by allowing a
S to be n ES to be
associated with a set of Ethernet Virtual Circuits (EVCs, such as VLANs) or o associated with a set of Ethernet Virtual Circuits (EVCs) (such as VLANs) or
ther other
entities, including MPLS Label Switched Paths (LSPs) or Pseudowires (PWs). Th entities, including MPLS Label Switched Paths (LSPs) or pseudowires (PWs). Th
is is
extended concept is referred to as virtual Ethernet Segments (vES). This draf extended concept is referred to as virtual Ethernet Segments (vESes). This do
t cument
lists the requirements and specifies the necessary extensions to support vES in both EVPN lists the requirements and specifies the necessary extensions to support vES in both EVPN
and PBB-EVPN. The scope of this document includes PBB-EVPN <xref target="RFC7 623"/>, and PBB-EVPN. The scope of this document includes PBB-EVPN <xref target="RFC7 623"/>,
EVPN over MPLS <xref target="RFC7432"/>, and EVPN over IP <xref target="RFC83 EVPN over MPLS <xref target="RFC7432"/>, and EVPN over IP <xref target="RFC83
65"/>. 65"/>;
However, it excludes EVPN over SRv6 <xref target="RFC9252"/>. </t> however, it excludes EVPN over SRv6 <xref target="RFC9252"/>. </t>
<section>
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
and only when, they appear in all capitals, as shown here. </t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</section> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
<section title="vESes in Access Ethernet Networks"> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<t> Some Service Providers (SPs) seek to extend the concept of physical when, and only when, they appear in all capitals, as shown here.
Ethernet links in an ES to encompass Ethernet Virtual Circuits (EVCs), </t>
</section>
<section>
<name>vESes in Access Ethernet Networks</name>
<t> Some service providers (SPs) seek to extend the concept of physical
Ethernet links in an ES to encompass EVCs,
wherein multiple EVCs (such as VLANs) can be aggregated onto a single wherein multiple EVCs (such as VLANs) can be aggregated onto a single
physical External Network-to-Network Interface (ENNI). An ES composed physical External Network-Network Interface (ENNI). An ES composed
of a set of EVCs rather than physical links is referred to as a vES. of a set of EVCs rather than physical links is referred to as a vES.
Figure 1 illustrates two PE devices (PE1 and PE2), each with <xref target="fig-1"/> illustrates two PE devices (PE1 and PE2), each with
an ENNI aggregating several EVCs. Some of these EVCs on a given ENNI an ENNI aggregating several EVCs. Some of these EVCs on a given ENNI
can be associated with vESes. For instance, the multi-homed vES depicted can be associated with vESes. For instance, the multi-homed vES depicted
in Figure 1 consists of EVC4 on ENNI1 and EVC5 on ENNI2. </t> in <xref target="fig-1"/> consists of EVC4 on ENNI1 and EVC5 on ENNI2. </t>
<figure>
<preamble/>
<artwork ><![CDATA[
3rd Party
+-----+ EAP
| CE11|EVC1 +---------+
+-----+ \ | | +---+
Cust. A \-0=========0--ENNI1| |
+-----+ | | ENNI1| | +-------+ +---+
| CE12|EVC2--0=========0--ENNI1|PE1|---| | | |
+-----+ | | ENNI1| | |SP |---|PE3|-
| ==0--ENNI1| | |IP/MPLS| | | \ +---+
+-----+ | / | +---+ |Core | +---+ \-| |
| CE22|EVC3--0==== / | |Network| |CE4|
+-----+ | X | | | +---+ | |
Cust. B | / \ | +---+ | | | | /-| |
+-----+ -0=== ===0--ENNI2| | | |---|PE4|-/ +---+
| CE3 |EVC4/ | | ENNI2|PE2|---| | | |
| |EVC5--0=========0--ENNI2| | +-------+ +---+
+-----+ | | +---+
Cust. C +---------+ /\
/\ ||
|| ENNI
EVCs Interface
<--------802.1Q----------> <---- EVPN Network -----> <-802.1Q->
Figure 1: Dual-homed Device/Network (both SA/AA) and SH on same ENNI
]]></artwork> <figure anchor="fig-1">
<postamble></postamble> <name>A Dual-Homed Device/Network (Both SA/AA) and SH on the Same ENNI</name>
</figure> <artwork><![CDATA[
Third-Party
+-----+ EAP
| CE11|EVC1 +---------+
+-----+ \ | | +---+
Cust. A \-0=========0--ENNI1| |
+-----+ | | ENNI1| | +-------+ +---+
| CE12|EVC2--0=========0--ENNI1|PE1|---| | | |
+-----+ | | ENNI1| | |SP |---|PE3|-
| ==0--ENNI1| | |IP/MPLS| | | \ +---+
+-----+ | / | +---+ |Core | +---+ \-| |
| CE22|EVC3--0==== / | |Network| |CE4|
+-----+ | X | | | +---+ | |
Cust. B | / \ | +---+ | | | | /-| |
+-----+ -0=== ===0--ENNI2| | | |---|PE4|-/ +---+
| CE3 |EVC4/ | | ENNI2|PE2|---| | | |
| |EVC5--0=========0--ENNI2| | +-------+ +---+
+-----+ | | +---+
Cust. C +---------+ /\
/\ ||
|| ENNI
EVCs Interface
<--------802.1Q----------> <---- EVPN Network -----> <-802.1Q->]]></artwork
>
</figure>
<t> ENNIs are commonly used to reach remote <t> ENNIs are commonly used to reach remote
customer sites via independent Ethernet access networks or third- customer sites via independent Ethernet access networks or third-party
party Ethernet Access Providers (EAP). ENNIs can Ethernet Access Providers (EAPs). ENNIs can
aggregate traffic from many vESes (e.g., hundreds to thousands), aggregate traffic from many vESes (e.g., hundreds to thousands),
where each vES is represented by its associated EVC on that ENNI. As a result , where each vES is represented by its associated EVC on that ENNI. As a result ,
ENNIs and their associated EVCs are a key element of SP external boundaries ENNIs and their associated EVCs are key elements of SP external boundaries
that are carefully designed and closely monitored. As a reminder, that are carefully designed and closely monitored. As a reminder,
the ENNI is the demarcation between the SP (IP/MPLS Core Network) and the the ENNI is the demarcation between the SP (IP/MPLS core network) and the
third-party Ethernet Access Provider. third-party Ethernet Access Provider.
</t> </t>
<t> To meet customers' Service Level Agreements (SLAs), SPs build
<t> To meet customers' Service Level Agreements (SLA), SPs build
redundancy via multiple EVPN PEs and across multiple ENNIs (as shown redundancy via multiple EVPN PEs and across multiple ENNIs (as shown
in Figure 1) where a given vES can be multi&nbhy;homed to two or more EVPN in <xref target="fig-1"/>), where a given vES can be multi-homed to two or
more EVPN
PE devices (on two or more ENNIs) via their associated EVCs. Just PE devices (on two or more ENNIs) via their associated EVCs. Just
like physical ESs in <xref target="RFC7432"/> and <xref target="RFC7623"/> so like physical ESs in the solutions described in <xref target="RFC7432"/> and
lutions, <xref target="RFC7623"/>, these vESes
these vESes can be single-homed or multi-homed ESs, and when multi-homed, they
can be single&nbhy;homed or multi&nbhy;homed ESs and when multi&nbhy;homed, t
hen
can operate in either Single-Active or All-Active redundancy modes. can operate in either Single-Active or All-Active redundancy modes.
In a typical SP external-boundary scenario (e.g., with an EAP), an ENNI can b e associated with In a typical SP external-boundary scenario (e.g., with an EAP), an ENNI can b e associated with
several thousands of single&nbhy;homed vESes, several hundreds of Single- several thousands of single-homed vESes, several hundreds of Single-Active
Active vESes and it may also be associated with tens or hundreds of vESes, and tens or hundreds of All-Active vESes. The specific figures used th
All-Active vESes. The specific figures (hundreds, thousands, etc.) used throu roughout
ghout this document reflect the relative quantities (hundreds, thousands, etc.) of
this document reflect the relative quantities of various elements as understo various elements as understood at the time of writing. </t>
od </section>
at the time of writing. </t> <section>
<name>vESes in Access MPLS Networks</name>
</section> <t> Other SPs want to extend the concept of
physical links in an ES to individual PWs or to MPLS
<section title="vESes in Access MPLS Networks"> LSPs in Access MPLS networks, i.e., a vES
<t> Other Service Providers (SPs) want to extend the concept of the consisting of a set of PWs or a set of LSPs. <xref target="fig-2"/> illustrat
physical links in an ES to individual Pseudowires (PWs) or to MPLS es this concept. </t>
Label Switched Paths (LSPs) in Access MPLS networks - i.e., a vES
consisting of a set of PWs or a set of LSPs. Figure 2 illustrates
this concept. </t>
<figure>
<preamble/>
<artwork ><![CDATA[
<figure anchor="fig-2">
<name>A Dual-Homed and Single-Homed Network on MPLS Aggregation Networks</name
>
<artwork><![CDATA[
MPLS Aggregation MPLS Aggregation
Network Network
+-----+ +-----------------+ +-----+ +-----------------+
| CE11|EVC1 | | | CE11|EVC1 | |
+-----+ \ +AG1-+ PW1 +-+---+ +-----+ \ +AG1-+ PW1 +-+---+
Cust. A -0----|===========| | Cust. A -0----|===========| |
+-----+ | ---+===========| | +-------+ +---+ +-----+ | ---+===========| | +-------+ +---+
| CE12|EVC2-0/ | PW2 /\ | PE1 +---+ | | | | CE12|EVC2-0/ | PW2 /\ | PE1 +---+ | | |
+-----+ ++---+ /=||=| | | +---+PE3+- +-----+ ++---+ /=||=| | | +---+PE3+-
| //=||=| | |IP/MPLS| | | \ +---+ | //=||=| | |IP/MPLS| | | \ +---+
skipping to change at line 230 skipping to change at line 215
| CE13| \+AG2-+==// | | | +---+ | | | CE13| \+AG2-+==// | | | +---+ | |
+-----+ 0 |==/PW4 /\ +-+---+ | | | | /-+ | +-----+ 0 |==/PW4 /\ +-+---+ | | | | /-+ |
0 |==PW5===||=| | | +---+PE4+-/ +---+ 0 |==PW5===||=| | | +---+PE4+-/ +---+
+-----+ /++---+==PW6===||=| PE2 +---+ | | | +-----+ /++---+==PW6===||=| PE2 +---+ | | |
| CE14|EVC4 | \/ | | +-------+ +---+ | CE14|EVC4 | \/ | | +-------+ +---+
+-----+ | LSP2+-+---+ +-----+ | LSP2+-+---+
Cust. C +-----------------+ Cust. C +-----------------+
/\ /\
|| ||
EVCs EVCs
<--802.1Q--> <-----MPLS Agg----> <--- EVPN Network ---> <-802.1Q-> <--802.1Q--> <-----MPLS Agg----> <--- EVPN Network ---> <-802.1Q->]]></artwor
k>
Figure 2: Dual-Homed and Single-homed Network </figure>
on MPLS Aggregation networks
]]></artwork>
<postamble></postamble>
</figure>
<t> In certain scenarios, Service Providers utilize MPLS Aggregation Networks <t> In certain scenarios, SPs utilize MPLS Aggregation Networks
that are managed by separate administrative entities or third-party organizat ions that are managed by separate administrative entities or third-party organizat ions
to gain access to their own IP/MPLS core network infrastructure. This situati on to gain access to their own IP/MPLS core network infrastructure. This situati on
is depicted in Figure 2. </t> is depicted in <xref target="fig-2"/>. </t>
<t> In such scenarios, a vES is defined as a set of individual PWs
<t> In such scenarios, a vES is defined as a set of individual PWs
when aggregation is not feasible. If aggregation is possible, the vES can be when aggregation is not feasible. If aggregation is possible, the vES can be
associated with a group of PWs that share the same unidirectional LSP pai r, associated with a group of PWs that share the same unidirectional LSP pai r,
where the LSP pair consists of the ingress and egress LSPs between the sa me where the LSP pair consists of the ingress and egress LSPs between the sa me
endpoints. </t> endpoints. </t>
<t> In <xref target="fig-2"/>, EVC3 is connected to
<t> In the example of Figure 2, EVC3 is connected to
a VPWS instance in AG2 that is connected to PE1 and PE2 via PW3 and a VPWS instance in AG2 that is connected to PE1 and PE2 via PW3 and
PW5 respectively. EVC4 is connected to another VPWS instance on PW5, respectively. EVC4 is connected to another VPWS instance on
AG2 that is connected to PE1 and PE2 via PW4 and PW6, AG2 that is connected to PE1 and PE2 via PW4 and PW6,
respectively. Since the PWs for the two VPWS instances can be respectively. Since the PWs for the two VPWS instances can be
aggregated into the same LSP pair going to and coming from the MPLS aggregated into the same LSP pair going to and coming from the MPLS
network, a common vES can be defined for the four mentioned network, a common vES can be defined for the four mentioned
PWs. In Figure 2, LSP1 and LSP2 represent the two LSP pairs between PE1 PWs. In <xref target="fig-2"/>, LSP1 and LSP2 represent the two LSP pairs bet
and AG2, and between PE2 and AG2, respectively. The vES consists of these two ween PE1
LSP and AG2 and between PE2 and AG2, respectively. The vES consists of these two
pairs (LSP1 and LSP2) and each LSP pair has two PWs. This vES will be LSP
pairs (LSP1 and LSP2), and each LSP pair has two PWs. This vES will be
shared by two separate EVPN instances (e.g., EVI-1 and EVI-2) in shared by two separate EVPN instances (e.g., EVI-1 and EVI-2) in
the EVPN network. PW3 and PW4 are associated with EVI-1 and EVI-2 respectivel the EVPN network. PW3 and PW4 are associated with EVI-1 and EVI-2, respective
y ly,
on PE1, and PW5 and PW6 are associated with EVI-1 and EVI-2 respectively on P on PE1, and PW5 and PW6 are associated with EVI-1 and EVI-2, respectively, on
E2. </t> PE2. </t>
<!--[rfced] For clarity, may "on a per individual PW" be rephrased
as "on each PW"? Alternatively, if "individual" is necessary, then
perhaps "for each individual PW".
<t> In some cases, the aggregation of PWs that share the same LSP pair Original:
may not be possible. For instance, if PW3 were terminated into a third PE, e. For instance, if PW3 were terminated into a
g. third PE, e.g. PE3, instead of PE1, the vES would need to be defined
PE3, instead of PE1, the vES would need to be defined on a per on a per individual PW on each PE.
individual PW on each PE.</t>
<t> For MPLS/IP access networks where a vES represents a set of LSP Perhaps:
For instance, if PW3 were terminated into a
third PE, e.g., PE3, instead of PE1, the vES would need to be defined
on each PW on each PE.
-->
<t> In some cases, the aggregation of PWs that share the same LSP pair
may not be possible. For instance, if PW3 were terminated into a third PE, e.
g.,
PE3, instead of PE1, the vES would need to be defined on a per individual
PW on each PE.</t>
<t> For MPLS/IP access networks where a vES represents a set of LSP
pairs or a set of PWs, this document extends the Single-Active multi-homing pairs or a set of PWs, this document extends the Single-Active multi-homing
procedures defined in <xref target="RFC7432"/> and <xref target="RFC7623"/> t o procedures defined in <xref target="RFC7432"/> and <xref target="RFC7623"/> t o
accommodate vES. The extension of vES to support All-Active multi-homing in accommodate vES. The extension of vES to support All-Active multi-homing in
MPLS/IP access networks is beyond the scope of this document. </t> MPLS/IP access networks is beyond the scope of this document. </t>
<t> This document defines the concept of a vES and specifies the additio
<t> This draft defines the concept of a vES and specifies the additional exte nal extensions
nsions
necessary to support a vES in accordance with <xref target="RFC7432"/> and necessary to support a vES in accordance with <xref target="RFC7432"/> and
<xref target="RFC7623"/>. <xref target="requirements"/> enumerates the set of <xref target="RFC7623"/>. <xref target="requirements"/> enumerates the set of
requirements for a vES. <xref target="overview"/> details the extensions for a requirements for a vES. <xref target="overview"/> details the extensions for a
vES applicable to EVPN solutions, including those specified in <xref target=" RFC7432"/> vES applicable to EVPN solutions, including those specified in <xref target=" RFC7432"/>
and <xref target="RFC7209"/>. These extensions are designed to meet the requi rements and <xref target="RFC7209"/>. These extensions are designed to meet the requi rements
listed in <xref target="requirements"/>. <xref target="overview"/> also provi des listed in <xref target="requirements"/>. <xref target="overview"/> also provi des
an overview of the solution, while <xref target="failure"/> addresses failure handling, an overview of the solution, while <xref target="failure"/> addresses failure handling,
recovery, scalability, and fast convergence of <xref target="RFC7432"/> and recovery, scalability, and fast convergence of <xref target="RFC7432"/> and
<xref target="RFC7623"/> for vESes. </t> <xref target="RFC7623"/> for vESes. </t>
</section>
</section> </section>
</section> <section>
<name>Terminology</name>
<section title="Terminology"> <dl newline="false" spacing="normal" indent="10">
<dt>AC:</dt>
<t> <dd>Attachment Circuit</dd>
<list style="hanging" hangIndent="10"> <dt>B-MAC:</dt>
<t hangText="AC:">Attachment Circuit</t> <dd>Backbone MAC Address </dd>
<t hangText="B-MAC:">Backbone MAC Address </t> <dt>CE:</dt>
<t hangText="CE:">Customer Edge Device </t> <dd>Customer Edge</dd>
<t hangText="C-MAC:">Customer/Client MAC Address </t> <dt>C-MAC:</dt>
<t hangText="DF:">Designated Forwarder</t> <dd>Customer/Client MAC Address </dd>
<t hangText="ENNI:">External Network-Network Interface </t> <dt>DF:</dt>
<t hangText="ES:">Ethernet Segment </t> <dd>Designated Forwarder</dd>
<t hangText="ESI:">Ethernet Segment Identifier </t> <dt>ENNI:</dt>
<t hangText="Ethernet A-D:">Ethernet Auto-Discovery Route </t> <dd>External Network-Network Interface </dd>
<t hangText="EVC:">Ethernet Virtual Circuit, <xref target="MEF63"/> </t> <dt>ES:</dt>
<t hangText="EVI:">EVPN Instance </t> <dd>Ethernet Segment </dd>
<t hangText="EVPN:">Ethernet VPN </t> <dt>ESI:</dt>
<t hangText="I-SID:">Service Instance Identifier (24 bits and global wit <dd>Ethernet Segment Identifier </dd>
hin a PBB <dt>Ethernet A-D:</dt>
network see <xref target="RFC7080"/>) </t> <dd>Ethernet Auto-Discovery </dd>
<t hangText="PBB:">Provider Backbone Bridge </t> <dt>EVC:</dt>
<t hangText="PBB-EVPN:">Provider Backbone Bridge EVPN </t> <dd>Ethernet Virtual Circuit <xref target="MEF63"/> </dd>
<t hangText="PE:">Provider Edge Device </t> <dt>EVI:</dt>
<t hangText="VPWS:">Virtual Pseudowire Service</t> <dd>EVPN Instance </dd>
<dt>EVPN:</dt>
<t hangText="Single-Active Redundancy Mode (SA):">When only a single PE, <dd>Ethernet VPN </dd>
among a <dt>I-SID:</dt>
<dd>Service Instance Identifier (24 bits and global within a PBB
network; see <xref target="RFC7080"/>). </dd>
<dt>MAC:</dt>
<dd>Media Access Control</dd>
<dt>PBB:</dt>
<dd>Provider Backbone Bridge </dd>
<dt>PBB-EVPN:</dt>
<dd>Provider Backbone Bridge EVPN </dd>
<dt>PE:</dt>
<dd>Provider Edge</dd>
<dt>VPWS:</dt>
<dd>Virtual Private Wire Service</dd>
<dt>Single-Active (SA) Redundancy Mode:</dt>
<dd>When only a single PE, among a
group of PEs attached to an Ethernet Segment, is allowed to forward group of PEs attached to an Ethernet Segment, is allowed to forward
traffic to/from that Ethernet Segment, then the Ethernet Segment is traffic to/from that Ethernet Segment, the Ethernet Segment is
defined to be operating in Single-Active redundancy mode. </t> defined as operating in Single-Active redundancy mode. </dd>
<dt>All-Active (AA) Redundancy Mode:</dt>
<t hangText="All-Active Redundancy Mode (AA):">When all PEs attached to <dd>When all PEs attached to an Ethernet
an Ethernet Segment are allowed to forward traffic to/from that Ethernet Segment,
segment, are allowed to forward traffic to/from that Ethernet Segment, the Ethernet Segment is defined as operating in All-Active
then the Ethernet Segment is defined to be operating in All-Active redundancy mode. </dd>
redundancy mode. </t> </dl>
</list>
</t>
</section> </section>
<section anchor="requirements">
<section title="Requirements" anchor="requirements"> <name>Requirements</name>
<t> This section describes the requirements specific to vES for EVPN and P
<t> This section describes the requirements specific to virtual Ethernet BB-EVPN solutions. These requirements are in
Segment (vES) for (PBB-)EVPN solutions. These requirements are in
addition to the ones described in <xref target="RFC8214"/>, <xref target="RFC 7432"/>, and addition to the ones described in <xref target="RFC8214"/>, <xref target="RFC 7432"/>, and
<xref target="RFC7623"/>. </t> <xref target="RFC7623"/>. </t>
<section>
<name>Single-Homed and Multi-Homed vES</name>
<t> A PE device <bcp14>MUST</bcp14> support the following types of vESes
: </t>
<section title="Single-Homed and Multi-Homed vES"> <ol type="(R1%c)">
<li>The PE <bcp14>MUST</bcp14> handle single-homed vESes on a
<t> A PE device MUST support the following types of virtual Ethernet Segments single physical port, such as a single ENNI. </li>
(vES): </t> <li>The PE <bcp14>MUST</bcp14> support a combination of
single-homed vESes and Single-Active multi-homed vESes simultaneously
<t> (R1a) The PE MUST handle single-homed vESes on a single physical port, su on a single physical port, such as a single ENNI. Throughout this
ch as document, Single-Active multi-homed vESes will be referred to as
a single ENNI. </t> "Single-Active vESes". </li>
<li>The PE <bcp14>MAY</bcp14> support All-Active multi-homed
<t> (R1b) The PE MUST support a combination of single-homed vESes and Single- vESes on a single physical port. Throughout this document, All-Active
Active multi-homed vESes will be referred to as "All-Active vESes". </li>
multi-homed vESes simultaneously on a single physical port, such as a single <li>The PE <bcp14>MAY</bcp14> support a combination of
ENNI. All-Active vESes along with other types of vESes on a single physical
Throughout this document, Single-Active multi-homed vESes will be referred to port. </li>
as <li>A multi-homed vES, whether Single-Active or All-Active, can
Single-Active vESes. </t> span across two or more ENNIs on any two or more PEs. </li>
</ol>
<t> (R1c) The PE MAY support All-Active multi-homed vESes on a single physica </section>
l port. <section>
Throughout this document, All-Active multi-homed vESes will be referred to as <name>Local Switching</name>
All-Active vESes. </t> <t> Many vESes of different types can be aggregated on a single physical
<t> (R1d) The PE MAY support a combination of All-Active vESes along with oth
er
types of vESes on a single physical port. </t>
<t> (R1e) A Multi-Homed vES, whether Single-Active or All-Active, can span
across two or more ENNIs on any two or more PEs. </t>
</section>
<section title="Local Switching">
<t> Many vESes of different types can be aggregated on a single physical
port on a PE device and some of these vESes can belong to the same port on a PE device and some of these vESes can belong to the same
service instance (e.g., EVI). This translates into the need for service instance (e.g., EVI). This translates into the need for
supporting local switching among the vESes for the same service supporting local switching among the vESes for the same service
instance on the same physical port (e.g., ENNI) of the PE. </t> instance on the same physical port (e.g., ENNI) of the PE. </t>
<!--[rfced] Section 3.2: Why is this item numbered "R3a" instead of "R2a"?
In other words, The preceding section is R1a, R1b, etc., so
should this be "R2a" instead of "R3a"?
<t> (R3a) A PE device that supports the vES function MUST support local switc If your answer is "R2a", then the subsequent requirements will be
hing updated as well (i.e. R4a, R4b, etc., will become R3a, R3b, etc.)
among different vESes associated with the same service instance on a single p
hysical
port. For instance, in Figure 1, PE1 must support local switching between CE1
1 and CE12,
which are mapped to two single-homed vESes on ENNI1. In the case of Single-Ac
tive vESes,
the local switching is performed among active EVCs associated with the same s
ervice
instance on the same ENNI. </t>
</section>
<section title="EVC Service Types"> Original:
(R3a) A PE device that supports the vES function MUST support local
switching among different vESes associated with the same service
instance on a single physical port.
-->
<t> A physical port, such as an ENNI of a PE device, can aggregate numerous <ol type="(R3%c)">
<li>A PE device that supports the vES function <bcp14>MUST</bcp14> suppo
rt local switching among different vESes associated with the same service instan
ce on a single physical port. For instance, in <xref target="fig-1"/>, PE1 must
support local switching between CE11 and CE12, which are mapped to two single-ho
med vESes on ENNI1. In the case of Single-Active vESes, the local switching is p
erformed among active EVCs associated with the same service
instance on the same ENNI. </li>
</ol>
</section>
<section>
<name>EVC Service Types</name>
<t> A physical port, such as an ENNI of a PE device, can aggregate numer
ous
EVCs, each associated with a vES. An EVC may carry one or more VLANs. Typical ly, EVCs, each associated with a vES. An EVC may carry one or more VLANs. Typical ly,
an EVC carries a single VLAN and is therefore associated with a single broadc ast an EVC carries a single VLAN and is therefore associated with a single broadc ast
domain. However, there are no restrictions preventing an EVC from carrying domain. However, there are no restrictions preventing an EVC from carrying
multiple VLANs. </t> multiple VLANs. </t>
<t> (R4a) An EVC can be associated with a single broadcast domain, such as in <ol type="(R4%c)" group="req4">
a VLAN-based service or a VLAN bundle service. </t> <li>An EVC can be associated with a single broadcast domain, such as in
a VLAN-based service or a VLAN bundle service. </li>
<t> (R4b) An EVC MAY be associated with several broadcast domains, such as in <li>An EVC <bcp14>MAY</bcp14> be associated with several broadcast domai
a VLAN-aware bundle service. </t> ns, such as in
a VLAN-aware bundle service. </li>
<t> Similarly, a PE can aggregate multiple LSPs and PWs. In the case of indiv </ol>
idual <t> Similarly, a PE can aggregate multiple LSPs and PWs. In the case of
PWs per vES, typically, a PW is associated with a single broadcast domain, al individual
though PWs per vES, a PW is typically associated with a single broadcast domain, alt
hough
there are no restrictions preventing a PW from carrying multiple VLANs if the PW there are no restrictions preventing a PW from carrying multiple VLANs if the PW
is configured in Raw mode. </t> is configured in Raw mode. </t>
<ol type="(R4%c)" group="req4">
<t> (R4c) A PW can be associated with a single broadcast domain, such as in a <li>A PW can be associated with a single broadcast domain, such as in a
VLAN-based service or a VLAN bundle service. </t> VLAN-based service or a VLAN bundle service. </li>
<li>A PW <bcp14>MAY</bcp14> be associated with several broadcast domains
<t> (R4d) An PW MAY be associated with several broadcast domains, such as in , such as in a
a VLAN-aware bundle service. </li>
VLAN-aware bundle service. </t> </ol>
</section>
</section> <section>
<name>Designated Forwarder (DF) Election</name>
<section title="Designated Forwarder (DF) Election"> <t><xref section="8.5" target="RFC7432" sectionFormat="of"/> specifies t
he default procedure for DF
<t> Section 8.5 of <xref target="RFC7432"/> specifies the default procedure f
or DF
election in EVPN, which is also applied in <xref target="RFC7623"/> and election in EVPN, which is also applied in <xref target="RFC7623"/> and
<xref target="RFC8214"/>. <xref target="RFC8584"/> elaborates on additional <xref target="RFC8214"/>. <xref target="RFC8584"/> elaborates on additional
procedures for DF election in EVPN. These DF election procedures are performe d at procedures for DF election in EVPN. These DF election procedures are performe d at
the granularity of (ESI, Ethernet Tag). In the context of a vES, the same EVP N default the granularity of (ESI, Ethernet Tag). In the context of a vES, the same EVP N default
procedure for DF election is applicable, but at the granularity of (vESI, Eth ernet Tag). procedure for DF election is applicable but at the granularity of (vESI, Ethe rnet Tag).
In this context, the Ethernet Tag is represented by an I-SID in PBB-EVPN and by a In this context, the Ethernet Tag is represented by an I-SID in PBB-EVPN and by a
VLAN ID (VID) in EVPN. VLAN ID (VID) in EVPN.
As described in <xref target="RFC7432"/>, this default procedure for DF elect ion at As described in <xref target="RFC7432"/>, this default procedure for DF elect ion at
the granularity of (vESI, Ethernet Tag) is also known as "service carving." T he goal the granularity of (vESI, Ethernet Tag) is also known as "service carving." T he goal
of service carving is to evenly distribute the DFs for different vESes among various PEs, of service carving is to evenly distribute the DFs for different vESes among various PEs,
thereby ensuring an even distribution of traffic across the PEs. The followin g thereby ensuring an even distribution of traffic across the PEs. The followin g
requirements are applicable to the DF election of vESes for (PBB-)EVPN. </t> requirements are applicable to the DF election of vESes for EVPN and PBB-EVPN . </t>
<t> (R5a) A PE that supports vES function, MUST support a vES with m EVCs amo <!--[rfced] Section 3.4: FYI, we changed "Rbc" to"R5b".
ng Rationale: The preceding item is R5a, and the numbering in the
n ENNIs belonging to p PEs in any arbitrary order; where n >= p >= m >=2. preceding section is R4a, R4b, R4c, etc. Please let us know if
For example, if there is a vES with 2 EVCs and there are 5 ENNIs on 5 PEs you intended otherwise.
(PE1 through PE5), then vES can be dual homed to PE2 and PE4 and the DF
election must be performed between PE2 and PE4.</t>
<t> (Rbc) Each vES MUST be identified by its own virtual ESI (vESI). </t> Original:
</section> (Rbc) Each vES MUST be identified by its own virtual ESI (vESI).
<section title="EVC Monitoring"> Current:
(R5b) Each vES MUST be identified by its own virtual ESI (vESI).
-->
<t> To detect the failure of an individual EVC and subsequently perform DF <ol type="(R5%c)">
<li>A PE that supports vES function <bcp14>MUST</bcp14> support a vES wi
th m EVCs among
n ENNIs belonging to p PEs in any arbitrary order, where n &gt;= p &gt;= m &g
t;=2.
For example, if there is a vES with 2 EVCs and there are 5 ENNIs on 5 PEs
(PE1 through PE5), then vES can be dual-homed to PE2 and PE4, and the DF
election must be performed between PE2 and PE4.</li>
<li>Each vES <bcp14>MUST</bcp14> be identified by its own virtual ESI (v
ESI). </li>
</ol>
</section>
<section>
<name>EVC Monitoring</name>
<t> To detect the failure of an individual EVC and subsequently perform
DF
election for its associated vES as a result of this failure, each EVC should election for its associated vES as a result of this failure, each EVC should
be monitored independently. </t> be monitored independently. </t>
<t> (R6a) Each EVC SHOULD be independently monitored for its operational heal <ol type="(R6%c)">
th. </t> <li>Each EVC <bcp14>SHOULD</bcp14> be independently monitored for its op
erational health. </li>
<t> (R6b) A failure in a single EVC, among many aggregated on a single physic <li>A failure in a single EVC, among many aggregated on a single physica
al l
port or ENNI, MUST trigger a DF election for its associated vES. </t> port or ENNI, <bcp14>MUST</bcp14> trigger a DF election for its associated vE
S. </li>
</section> </ol>
</section>
<section title="Failure and Recovery"> <section>
<name>Failure and Recovery</name>
<t> (R7a) Failure and failure recovery of an EVC for a Single-homed vES <ol type="(R7%c)">
SHALL NOT impact any other EVCs within its service instance or any <li>Failure and failure recovery of an EVC for a single-homed vES
other service instances. In other words, for PBB-EVPN, it SHALL NOT <bcp14>SHALL NOT</bcp14> impact any other EVCs within its service instance or
trigger any MAC flushing both within its own I-SID as well as other any
I-SIDs. </t> other service instances. In other words, for PBB-EVPN, it <bcp14>SHALL NOT</b
cp14>
<t> (R7b) In case of All-Active vES, failure and failure trigger any MAC flushing within both its own I-SID and other
recovery of an EVC for that vES SHALL NOT impact any other EVCs within I-SIDs. </li>
<li>In case of All-Active vES, failure and failure
recovery of an EVC for that vES <bcp14>SHALL NOT</bcp14> impact any other EVC
s within
its service instance or any other service instances. In other its service instance or any other service instances. In other
words, for PBB-EVPN, it SHALL NOT trigger any MAC flushing both words, for PBB-EVPN, it <bcp14>SHALL NOT</bcp14> trigger any MAC flushing
within its own I-SID as well as other I-SIDs. </t> within both its own I-SID and other I-SIDs. </li>
<li>Failure and failure recovery of an EVC for a Single-Active vES
<t> (R7c) Failure and failure recovery of an EVC for a Single-Active vES <bcp14>SHALL</bcp14> impact only its own service instance. In other words, fo
SHALL impact only its own service instance. In other words, for PBB- r PBB-EVPN,
EVPN, MAC flushing SHALL be limited to the associated I-SID only and MAC flushing <bcp14>SHALL</bcp14> be limited to the associated I-SID only and
SHALL NOT impact any other I-SIDs. </t> <bcp14>SHALL NOT</bcp14> impact any other I-SIDs. </li>
<li>Failure and failure recovery of an EVC for a Single-Active vES
<bcp14>MUST</bcp14> only impact C-MACs associated with a multi-homed device/n
etwork for that service
instance. In other words, MAC flushing <bcp14>MUST</bcp14> be limited to a si
ngle
service instance (I-SID in the case of PBB-EVPN) and only C-MACs for a
Single-Active multi-homed device/network. </li>
</ol>
</section>
<section>
<name>Fast Convergence</name>
<t> (R7d) Failure and failure recovery of an EVC for a Single-Active vES <!--[rfced] We had trouble parsing this sentence and updated it for
MUST only impact C-MACs associated with multi-homed device/network for that s clarity as shown below. Please let us know if it changes the
ervice intended meaning.
instance. In other words, MAC flushing MUST be limited to single
service instance (I-SID in the case of PBB-EVPN) and only C-MACs for
Single-Active multi-homed device/network. </t>
</section> Original:
Since many EVCs (and their associated vESes) are aggregated via a
single physical port (e.g., ENNI), then the failure of that physical
port impacts many vESes and triggers equally many ES route
withdrawals.
<section title="Fast Convergence"> Perhaps:
Since many EVCs (and their associated vESes) are aggregated via a
single physical port (e.g., ENNI), when there is a failure of that
physical port, it impacts many vESes and equally triggers many ES route
withdrawals.
-->
<t> Since many EVCs (and their associated vESes) are <t> Since many EVCs (and their associated vESes) are
aggregated via a single physical port (e.g., ENNI), then the failure aggregated via a single physical port (e.g., ENNI), when there is a failure
of that physical port impacts many vESes and triggers of that physical port, it impacts many vESes and equally triggers
equally many ES route withdrawals. Formulating, sending, many ES route withdrawals. Formulating, sending,
receiving, and processing such large number of BGP messages can receiving, and processing such large numbers of BGP messages can
introduce delay in DF election and convergence time. As such, it is introduce delay in DF election and convergence time. As such, it is
highly desirable to have a mass&nbhy;withdraw mechanism similar to the one highly desirable to have a mass-withdraw mechanism similar to the one
in <xref target="RFC7432"/> for withdrawing many Ethernet A-D per ES routes. </t> in <xref target="RFC7432"/> for withdrawing many Ethernet A-D per ES routes. </t>
<ol type="(R8%c)">
<t> (R8a) There SHOULD be a mechanism equivalent to EVPN mass&nbhy;withdraw <li>There <bcp14>SHOULD</bcp14> be a mechanism equivalent to EVPN mass with
such that upon an ENNI failure, only a single BGP message is needed draw
to indicate to the remote PEs to trigger DF election for all impacted such that upon an ENNI failure, only a single BGP message to the PEs is n
vES associated with that ENNI. </t> eeded to trigger DF election for all impacted vESes associated with that ENNI. <
/li>
</section> </ol>
</section> </section>
</section>
<section title="Solution Overview" anchor="overview"> <section anchor="overview">
<name>Solution Overview</name>
<t> The solutions described in <xref target="RFC7432"/> and <xref target="RFC <t> The solutions described in <xref target="RFC7432"/> and <xref target="
7623"/> are leveraged RFC7623"/>
as&nbhy;is with the modification that the ESI assignment is are leveraged
as is, with the modification that the ESI assignment is
performed for an EVC or a group of EVCs or LSPs/PWs instead of a link or a gr oup of performed for an EVC or a group of EVCs or LSPs/PWs instead of a link or a gr oup of
physical links. In other words, the ESI is associated with a virtual physical links. In other words, the ESI is associated with a vES (hereby refe
ES (vES), hereby referred to as vESI. </t> rred to as the "vESI"). </t>
<t> In the EVPN solution, the overall procedures remain consistent,
<t> In the EVPN solution, the overall procedures remain consistent,
with the primary difference being the handling of physical port failures with the primary difference being the handling of physical port failures
that can affect multiple vESes. Sections <xref target="fail_evc_sa_evpn" form at="counter"/> that can affect multiple vESes. Sections <xref target="fail_evc_sa_evpn" form at="counter"/>
and <xref target="fail_port_sa_evpn" format="counter"/> describe the and <xref target="fail_port_sa_evpn" format="counter"/> describe the
procedures for managing physical port or link failures in the context of EVPN . procedures for managing physical port or link failures in the context of EVPN .
In a typical multi-homed setup, MAC addresses learned behind a vES are In a typical multi-homed setup, MAC addresses learned behind a vES are
advertised using the ESI associated with the vES, referred to as the vESI. advertised using the ESI associated with the vES (i.e., the vESI).
EVPN aliasing and mass-withdraw operations are conducted with respect to the EVPN aliasing and mass-withdraw operations are conducted with respect to the
vES identifier. Specifically, the Ethernet Auto-Discovery (A-D) routes for th vES identifier. Specifically, the Ethernet A-D routes for these
ese operations are advertised using the vESI instead of the ESI. </t>
operations are advertised using the vESI instead of the ESI. </t>
<t> For PBB-EVPN solution, the main change is with respect to the B-MAC <!-- [rfced] We note that RFC 7623 does not contain Section
address assignment which is performed similar to what is described in 7.2.1.1. Was Section 6.2.1.1 ("PE B-MAC Address Assignment")
section 7.2.1.1 of <xref target="RFC7623"/> with the following refinements: perhaps intended
<https://www.rfc-editor.org/rfc/rfc7623#section-6.2.1.1>?
<list style="symbols"> Original:
For PBB-EVPN solution, the main change is with respect to the B-MAC
address assignment which is performed similar to what is described in
section 7.2.1.1 of [RFC7623] with the following refinements:
-->
<t> For the PBB-EVPN solution, the main change is with respect to the B-MA
C
address assignment, which is performed in a similar way to what is described
in
<xref section="7.2.1.1" target="RFC7623" sectionFormat="of"/>, with the follo
wing refinements:
<t> One shared B-MAC address SHOULD be used per PE for the single&nbhy;homed </t>
vESes. In other words, a single B-MAC is shared for all single&nbhy;homed <ul spacing="normal">
<li>
<t> One shared B-MAC address <bcp14>SHOULD</bcp14> be used per PE for
the single-homed
vESes. In other words, a single B-MAC is shared for all single-homed
vESes on that PE. </t> vESes on that PE. </t>
</li>
<t> One shared B-MAC address SHOULD be used per PE per physical port <li>
<t> One shared B-MAC address <bcp14>SHOULD</bcp14> be used per PE, per
physical port
(e.g., ENNI) for the Single-Active vESes. In other words, a single (e.g., ENNI) for the Single-Active vESes. In other words, a single
B-MAC is shared for all Single-Active vESes that share the same ENNI. </t> B-MAC is shared for all Single-Active vESes that share the same ENNI. </t>
</li>
<t> One shared B-MAC address MAY be used for all Single-Active vESes on <li>
<t> One shared B-MAC address <bcp14>MAY</bcp14> be used for all Single
-Active vESes on
that PE. </t> that PE. </t>
</li>
<t> One B-MAC address SHOULD be used per set of EVCs representing an <li>
<t> One B-MAC address <bcp14>SHOULD</bcp14> be used per set of EVCs re
presenting an
All-Active vES. In other words, a single B-MAC address is All-Active vES. In other words, a single B-MAC address is
used per vES for All-Active scenarios. </t> used per vES for All-Active scenarios. </t>
</li>
<t> A single B-MAC address MAY also be used per vES per PE for Single- <li>
Active scenarios. </t> <t> A single B-MAC address <bcp14>MAY</bcp14> also be used per vES, pe
r PE for Single-Active scenarios. </t>
</list> </li>
</t> </ul>
<section anchor="df_election">
<section title="EVPN DF Election for vES" anchor="df_election"> <name>EVPN DF Election for vES</name>
<t> <t>
The procedure for service carving for vESes is The service carving procedures for vESes are
almost the same as the ones outlined in section 8.5 of <xref target="RFC7432" almost the same as the procedures outlined in <xref section="8.5" target="RFC
/> 7432" sectionFormat="of"/>
and <xref target="RFC8584"/> except for the fact that and in <xref target="RFC8584"/>, except that ES is replaced with vES.</t>
ES is replaced with vES.</t> <t>For the sake of clarity and completeness, the default DF election
<t>For the sake of clarity and completeness, the default DF election
procedure of <xref target="RFC7432"/> is repeated below with the necessary procedure of <xref target="RFC7432"/> is repeated below with the necessary
changes: changes:
<list style="numbers"> </t>
<t> When a PE discovers the vESI or is configured with the vESI <ol spacing="normal" type="1">
associated with its attached vES, it advertises an Ethernet Segment <li>
route with the associated ES-Import extended community attribute. </t> <t> When a PE discovers the vESI or is configured with the vESI
associated with its attached vES, it advertises an Ethernet
<t> The PE then starts a timer (default value = 3 seconds) to allow Segment route with the associated ES-Import extended community
the reception of Ethernet Segment routes from other PE nodes attribute. </t>
connected to the same vES. This timer value MUST be same across all </li>
PEs connected to the same vES. </t> <li>
<t> The PE then starts a timer (default value = 3 seconds) to
allow the reception of Ethernet Segment routes from other PE nodes
connected to the same vES. This timer value <bcp14>MUST</bcp14> be
the same across all PEs connected to the same vES. </t>
</li>
<li>
<t> When the timer expires, each PE builds an ordered list of the
IP addresses of all the PE nodes connected to the vES (including
itself), in increasing numeric value. Each IP address in this list
is extracted from the "Originator Router's IP address" field of
the advertised Ethernet Segment route. Every PE is then given an
ordinal indicating its position in the ordered list, starting with
0 as the ordinal for the PE with the numerically lowest IP
address. The ordinals are used to determine which PE node will be
the DF for a given EVPN instance on the vES using the following
rule: Assuming a redundancy group of N PE nodes, the PE with
ordinal i is the DF for an EVPN instance with an associated
Ethernet Tag value of V when (V mod N) = i. It should be noted
that using the "Originator Router's IP address" field in the Etherne
t
Segment route to get the PE IP address needed for the ordered
list allows a CE to be multi-homed across different ASes, if
such need ever arises. </t>
</li>
<li>
<t> The PE that is elected as a DF for a given EVPN instance will
unblock traffic for that EVPN instance. Note that the DF PE
unblocks all traffic in both ingress and egress directions for
Single-Active vESes and unblocks multi-destination in the egress
direction for All-Active multi-homed vESes. All non-DF PEs block all
traffic in both ingress and egress directions for Single-Active
vESes and block multi-destination traffic in the egress direction
for All-Active vESes. </t>
</li>
</ol>
<t> In case of an EVC failure, the affected PE withdraws its correspondi
ng Ethernet
Segment route if there are no more EVCs associated to the vES in the
PE. This will re-trigger the DF election procedure on all the PEs in
the redundancy group. For PE node failure, or upon PE commissioning
or decommissioning, the PEs re-trigger the DF election procedure
across all affected vESes.
<t> When the timer expires, each PE builds an ordered list of the IP <!--[rfced] Is a word missing after "Single-Active" in the following
addresses of all the PE nodes connected to the vES (including sentence? Perhaps "scenario"?
itself), in increasing numeric value. Each IP address in this list is
extracted from the "Originator Router's IP address" field of the
advertised Ethernet Segment route. Every PE is then given an ordinal
indicating its position in the ordered list, starting with 0 as the
ordinal for the PE with the numerically lowest IP address. The
ordinals are used to determine which PE node will be the DF for a
given EVPN instance on the vES using the following rule: Assuming a
redundancy group of N PE nodes, the PE with ordinal i is the DF for
an EVPN instance with an associated Ethernet Tag value of V when (V
mod N) = i.
It should be noted that using "Originator Router's IP address" field
in the Ethernet Segment route to get the PE IP address needed for the
ordered list, allows for a CE to be multi&nbhy;homed across different ASes
if such need ever arises. </t>
<t> The PE that is elected as a DF for a given EVPN instance will Original:
unblock traffic for that EVPN instance. Note that the DF PE unblocks In case of a Single-Active, when a service moves from one PE in the
all traffic in both ingress and egress directions for Single-Active Redundancy Group to another PE because of DF re-election, the PE,
vES and unblocks multi&nbhy;destination in egress direction for All-Active which ends up being the elected DF for the service, MUST trigger a
Multi-homed vES. All non-DF PEs block all traffic in both ingress and MAC address flush notification towards the associated vES if the
egress directions for Single-Active vES and block multi&nbhy;destination multi-homing device is a bridge or the multi-homing network is an
traffic in the egress direction for All-Active vES. </t> Ethernet bridged network.
</list> -->
</t>
<t> In case of an EVC failure, the affected PE withdraws its corresponding Et In case of a Single-Active,
hernet when a service moves from one PE in the redundancy group to another
Segment route if there are no more EVCs associated to the vES in the PE because of DF re-election, the PE (which ends up being the
PE. This will re-trigger the DF Election procedure on all the PEs in elected DF for the service) <bcp14>MUST</bcp14> trigger a MAC address flush
the Redundancy Group. For PE node failure, or upon PE commissioning
or decommissioning, the PEs re-trigger the DF Election procedure
across all affected vESes. In case of a Single-Active,
when a service moves from one PE in the Redundancy Group to another
PE because of DF re-election, the PE, which ends up being the
elected DF for the service, MUST trigger a MAC address flush
notification towards the associated vES if the multi-homing device is a bridg e notification towards the associated vES if the multi-homing device is a bridg e
or the multi-homing network is an Ethernet bridged network.</t> or the multi-homing network is an Ethernet bridged network.</t>
<t> For LSP-based and PW-based vES, the non-DF PE <bcp14>SHOULD</bcp14>
<t> For LSP-based and PW-based vES, the non-DF PE SHOULD signal PW-status signal PW-status
'standby' to the Aggregation PE (e.g., AG1 and AG2 in Figure 2), 'standby' to the Aggregation PE (e.g., AG1 and AG2 in <xref target="fig-2"/>)
and a new DF PE MAY send an LDP MAC withdraw message as a MAC ,
and a new DF PE <bcp14>MAY</bcp14> send a Label Distribution Protocol (LDP) M
AC withdraw message as a MAC
address flush notification. It should be noted that the PW-status is address flush notification. It should be noted that the PW-status is
signaled for the scenarios where there is a one-to-one mapping signaled for the scenarios where there is a one-to-one mapping
between EVI (EVPN instance) and the PW. </t> between EVI (EVPN instance) and the PW. </t>
</section>
</section> <section anchor="grouping">
<name>Grouping and Route Coloring for vES</name>
<section title="Grouping and Route Coloring for vES" anchor="grouping"> <t>Physical ports (e.g., ENNI) that aggregate many EVCs
<t>Physical ports (e.g. ENNI) which aggregate many EVCs
are 'colored' to enable the grouping schemes described below. </t> are 'colored' to enable the grouping schemes described below. </t>
<t>By default, the MAC address of the corresponding port (e.g., ENNI)
<t>By default, the MAC address of the corresponding port (e.g. ENNI)
is used to represent the 'color' of the port, and the is used to represent the 'color' of the port, and the
EVPN Router's MAC Extended Community defined EVPN Router's MAC Extended Community defined
in <xref target="RFC9135"/> is used to in <xref target="RFC9135"/> is used to signal this color.</t>
signal this color.</t> <t>The difference between coloring mechanisms for EVPN and PBB-EVPN is t
hat
<t>The difference between coloring mechanism for EVPN and PBB-EVPN is th the extended community is advertised with the Ethernet A-D per ES
at route for EVPN, whereas the extended community is advertised
for EVPN, the extended community is advertised with the Ethernet A-D per with the B-MAC route for PBB-EVPN.</t>
ES <t> The subsequent sections detailing Grouping of Ethernet A-D
route whereas for PBB-EVPN, the extended community is advertised
with the B-MAC route.</t>
<t> The subsequent sections detailing Grouping of Ethernet Auto-Discover
y (A-D)
per ES and Grouping of B-MAC addresses will be essential for addressi ng port per ES and Grouping of B-MAC addresses will be essential for addressi ng port
failure handling, as discussed in Sections <xref target="fail_port_sa failure handling, as discussed in Sections <xref target="fail_port_sa
_evpn"/>, _evpn" format="counter"/>,
<xref target="fail_port_sa_pbbevpn"/>, and <xref target="convergence" <xref target="fail_port_sa_pbbevpn" format="counter"/>, and <xref tar
/>. </t> get="convergence" format="counter"/>. </t>
<section anchor="grouping_evpn">
<section title="EVPN Route Coloring for vES" anchor="grouping_evpn"> <name>EVPN Route Coloring for vES</name>
<t>When a PE discovers the vESI or is configured with the vESI assoc <t>When a PE discovers the vESI or is configured with the vESI associa
iated ted
with its attached vES, an Ethernet-Segment route and Ethernet A-D pe with its attached vES, an Ethernet Segment route and Ethernet A-D pe
r ES r ES
route are generated using the vESI identifier.</t> route are generated using the vESI identifier.</t>
<t>These Ethernet Segment and Ethernet A-D per ES routes specific to e
<t>These Ethernet-Segment and Ethernet A-D per ES routes specific to ach
each
vES are colored with an attribute representing their association vES are colored with an attribute representing their association
to a physical port (e.g. ENNI).</t> to a physical port (e.g., ENNI).</t>
<t>The corresponding port 'color' is encoded in the
<t>The corresponding port 'color' is encoded in the
EVPN Router's MAC Extended Community defined in <xref target="RFC913 5"/> EVPN Router's MAC Extended Community defined in <xref target="RFC913 5"/>
and advertised along with the Ethernet Segment and Ethernet A-D per ES and advertised along with the Ethernet Segment and Ethernet A-D per ES
routes for this vES. The color (which is the MAC address of the port ) MUST routes for this vES. The color (which is the MAC address of the port ) <bcp14>MUST</bcp14>
be unique. </t> be unique. </t>
<t>The PE also constructs a special Grouping Ethernet A-D per ES route
<t>The PE also constructs a special Grouping Ethernet A-D per ES rou that represents all the vESes associated with the port (e.g., ENNI).
te
which represents all the vES associated with the port (e.g. ENNI).
The corresponding port 'color' is encoded in the ESI field. The corresponding port 'color' is encoded in the ESI field.
For this encoding, Type 3 ESI (<relref target="RFC7432" section="5"/ >) is used For this encoding, Type 3 ESI (<xref target="RFC7432" section="5"/>) is used
with the MAC field set to the color (MAC address) of the port with the MAC field set to the color (MAC address) of the port
and the 3-octet local discriminator field set to 0xFFFFFF. and the 3-octet local discriminator field set to 0xFFFFFF.
</t> </t>
<t>The ESI label extended community (<xref target="RFC7432" section="7
<t>The ESI label extended community (<relref target="RFC7432" sectio .5"/>)
n="7.5"/>)
is not relevant to Grouping Ethernet A-D per ES route. The label val ue is not is not relevant to Grouping Ethernet A-D per ES route. The label val ue is not
used for encapsulating BUM (Broadcast, Unknown-unicast, Multicast) p ackets used for encapsulating Broadcast, Unknown Unicast, and Multicast (BU M) packets
for any split-horizon function. The ESI for any split-horizon function. The ESI
label extended community MUST NOT be added to Grouping Ethernet A-D label extended community <bcp14>MUST NOT</bcp14> be added to Groupin
per ES route and g Ethernet A-D per ES route and
MUST be ignored on receiving PE. <bcp14>MUST</bcp14> be ignored on receiving the PE.
</t> </t>
<t> The Grouping Ethernet A-D per ES route is advertised with a
<t> The Grouping Ethernet Auto-Discovery (A-D) per ES route is adver
tised with a
list of Route Targets corresponding to the affected service insta nces. If the list of Route Targets corresponding to the affected service insta nces. If the
number of associated Route Targets exceeds the capacity of a sing le route, number of associated Route Targets exceeds the capacity of a sing le route,
multiple Grouping Ethernet A-D per ES routes are advertised accor dingly as multiple Grouping Ethernet A-D per ES routes are advertised accor dingly as
specified in Section 8.2 of <xref target="RFC7432"/>. </t> specified in <xref section="8.2" target="RFC7432" sectionFormat=" of"/>. </t>
</section> </section>
<section anchor="grouping_pbbevpn">
<section title="PBB-EVPN Route Coloring for vES" anchor="grouping_pbbevp <name>PBB-EVPN Route Coloring for vES</name>
n"> <t> In PBB-EVPN, particularly when there are large numbers of service
<t> In PBB-EVPN, particularly when there are a large number of servi instances
ce instances (i.e., I-SIDs) associated with each EVC, the PE device <bcp14>MAY
(i.e., I-SIDs) associated with each EVC, the PE device MAY assign </bcp14> assign a color attribute
a color attribute
to each vES B-MAC route, indicating their association with a phys ical port to each vES B-MAC route, indicating their association with a phys ical port
(e.g., an ENNI). </t> (e.g., an ENNI). </t>
<t>The corresponding port 'color' is encoded in the
<t>The corresponding port 'color' is encoded in the
EVPN Router's MAC Extended Community defined EVPN Router's MAC Extended Community defined
in <xref target="RFC9135"/> and advertised in <xref target="RFC9135"/> and advertised
along with the B-MAC for this vES in PBB-EVPN.</t> along with the B-MAC for this vES in PBB-EVPN.</t>
<t>The PE <bcp14>MAY</bcp14> also construct a special Grouping B-MAC r
<t>The PE MAY then also construct a special Grouping B-MAC route oute
which represents all the vES associated with the port (e.g. ENNI). that represents all the vESes associated with the port (e.g., ENNI).
The corresponding port 'color' is encoded directly into this The corresponding port 'color' is encoded directly into this
special Grouping B-MAC route.</t> special Grouping B-MAC route.</t>
</section> </section>
</section>
</section>
</section> </section>
<section anchor="failure">
<section title="Failure Handling and Recovery" anchor="failure"> <name>Failure Handling and Recovery</name>
<t> There are several failure scenarios to consider such as:
<t> There are several failure scenarios to consider such as: </t>
<list style="hanging" hangIndent="3"> <dl newline="false" spacing="normal" indent="3">
<t hangText="A:">CE uplink port failure</t> <dt>A:</dt>
<t hangText="B:">Ethernet Access Network failure</t> <dd>CE uplink port failure</dd>
<t hangText="C:">PE access-facing port or link failure</t> <dt>B:</dt>
<t hangText="D:">PE node failure</t> <dd>Ethernet Access Network failure</dd>
<t hangText="E:">PE isolation from IP/MPLS network</t> <dt>C:</dt>
</list> <dd>PE access-facing port or link failure</dd>
</t> <dt>D:</dt>
<dd>PE node failure</dd>
<t> <dt>E:</dt>
<dd>PE isolation from IP/MPLS network</dd>
</dl>
<t>
The solutions specified in <xref target="RFC7432"/>, <xref target="RFC7623"/> , The solutions specified in <xref target="RFC7432"/>, <xref target="RFC7623"/> ,
and <xref target="RFC8214"/> provide protection against failures as described in and <xref target="RFC8214"/> provide protection against failures as described in
these respective references. In the context of these solutions, the presence of vESes these respective references. In the context of these solutions, the presence of vESes
introduces an additional failure scenario beyond those already considered, sp ecifically introduces an additional failure scenario beyond those already considered, sp ecifically
the failure of individual EVCs. Addressing vES failure scenarios necessitates the the failure of individual EVCs. Addressing vES failure scenarios necessitates the
independent monitoring of EVCs or PWs. Upon detection of failure or service r estoration, independent monitoring of EVCs or PWs. Upon detection of failure or service r estoration,
appropriate DF election and failure recovery mechanisms must be executed. </t > appropriate DF election and failure recovery mechanisms must be executed. </t >
<t> <xref target="RFC7023"/> is used for monitoring EVCs, and upon failure
<t> <xref target="RFC7023"/> is used for monitoring EVCs and upon failure det detection of a
ection of a given EVC, the DF election procedure per <xref target="df_election"/> is exec
given EVC, DF election procedure per <xref target="df_election"/> is executed uted. For
. For
PBB-EVPN, some extensions are needed to handle the failure and PBB-EVPN, some extensions are needed to handle the failure and
recovery procedures of <xref target="RFC7623"/> to meet the above recovery procedures of <xref target="RFC7623"/> to meet the above
requirements. These extensions are described in the next section. </t> requirements. These extensions are described in the next section. </t>
<t> <xref target="RFC4377"/> and <xref target="RFC6310"/> are used for mon
<t> <xref target="RFC4377"/> and <xref target="RFC6310"/> are used for monito itoring the status of LSPs
ring the status of LSPs
and/or PWs associated to vES. </t> and/or PWs associated to vES. </t>
<figure> <figure anchor="fig-3">
<preamble/> <name>Failure Scenarios A, B, C, D, and E</name>
<artwork ><![CDATA[ <artwork><![CDATA[
B D B D
|| || || ||
\/ \/ \/ \/
+-----+ +-----+
+-----+ | | +---+ +-----+ | | +---+
| CE1 |EVC2--0=====0--ENNI1| | +-------+ | CE1 |EVC2--0=====0--ENNI1| | +-------+
+-----+ | =0--ENNI1|PE1|---| | +---+ +---+ +-----+ | =0--ENNI1|PE1|---| | +---+ +---+
Cust. A | / | | | |IP/MPLS|--|PE3|--|CE4| Cust. A | / | | | |IP/MPLS|--|PE3|--|CE4|
+-----+ | / | +---+ |Network| | | +---+ +-----+ | / | +---+ |Network| | | +---+
| |EVC2--0== | | | +---+ | |EVC2--0== | | | +---+
| CE2 | | | +---+ | | | CE2 | | | +---+ | |
| |EVC3--0=====0--ENNI2|PE2|---| | | |EVC3--0=====0--ENNI2|PE2|---| |
+-----+ | | | | +-------+ +-----+ | | | | +-------+
+-----+ +---+ +-----+ +---+
/\ /\ /\ /\ /\ /\
|| || || || || ||
A C E A C E]]></artwork>
</figure>
Figure 4: Failure Scenarios A,B,C,D and E <section anchor="fail_evc_sa_evpn">
<name>EVC Failure Handling for Single-Active vES in EVPN</name>
]]></artwork> <t>
<postamble></postamble> In <xref target="RFC7432"/>, when a DF PE connected to a Single-Active multi-
</figure> homed Ethernet
<section title="EVC Failure Handling for Single-Active vES in EVPN" anch
or="fail_evc_sa_evpn">
<t>
In <xref target="RFC7432"/>, when a DF PE connected to a Single-Active multi&
nbhy;homed Ethernet
Segment loses connectivity to the segment, due to link or port Segment loses connectivity to the segment, due to link or port
failure, it signals to the remote PEs to invalidate all MAC addresses failure, it signals the remote PEs to invalidate all MAC addresses
associated with that Ethernet Segment. This is done by means of a associated with that Ethernet Segment. This is done by means of a
mass&nbhy;withdraw message, by withdrawing the Ethernet A-D per ES route. mass-withdraw message, by withdrawing the Ethernet A-D per ES route.
It should be It should be
noted that for dual-homing use cases where there is only a single noted that for dual-homing use cases where there is only a single
backup path, MAC invalidating can be avoided by the remote PEs as they backup path, MAC invalidating can be avoided by the remote PEs as they
can update their next hop associated with the affected MAC can update their next hop associated with the affected MAC
entries to the backup path per procedure described in section 8.2 of entries to the backup path per the procedure described in <xref section="8.2"
<xref target="RFC7432"/>. sectionFormat="of" target="RFC7432"/>.
</t> </t>
<t> <t>
In case of an EVC failure which impacts a single vES, this same In case of an EVC failure that impacts a single vES, this same
EVPN procedure is used. In this case, the mass&nbhy;withdraw is conveyed EVPN procedure is used. In this case, the mass withdraw is conveyed
by withdrawing the Ethernet A-D per vES route carrying the vESI representing by withdrawing the Ethernet A-D per vES route carrying the vESI representing
the failed EVC. The remote PEs upon receiving this the failed EVC. Upon receiving this
message perform the same procedures outlined in section 8.2 of message, the remote PEs perform the same procedures outlined in <xref section
<xref target="RFC7432"/>. ="8.2" sectionFormat="of" target="RFC7432"/>.
</t> </t>
</section> </section>
<section anchor="fail_evc_sa_pbbevpn">
<section title="EVC Failure Handling for Single-Active vES in PBB-EVPN" <name>EVC Failure Handling for a Single-Active vES in PBB-EVPN</name>
anchor="fail_evc_sa_pbbevpn"> <t> In <xref target="RFC7432"/>, when a PE connected to a Single-Active
Ethernet Segment
<t> In <xref target="RFC7432"/> when a PE connected to a Single-Active Ether
net Segment
loses connectivity to the segment, due to link or port failure, it loses connectivity to the segment, due to link or port failure, it
signals the remote PE to flush all C-MAC addresses associated with signals the remote PE to flush all C-MAC addresses associated with
that Ethernet Segment. This is done by updating the advertised a B-MAC route' that Ethernet Segment. This is done by updating the advertised B-MAC route's
s MAC Mobility Extended Community. </t>
MAC Mobility Extended community. </t> <t> In case of an EVC failure that impacts a single vES, if the above
<t> In case of an EVC failure that impacts a single vES, if the above
PBB-EVPN procedure is used, it results in excessive C-MAC flushing PBB-EVPN procedure is used, it results in excessive C-MAC flushing
because a single physical port can support large number of EVCs (and because a single physical port can support a large number of EVCs (and
their associated vESes) and thus updating the advertised B-MAC corresponding their associated vESes); therefore, updating the advertised B-MAC correspondi
to ng to
the physical port, with MAC mobility Extended community, will result in the physical port, with MAC Mobility Extended Community, will result in
flushing C-MAC addresses not just for the impacted EVC but for all flushing C-MAC addresses not just for the impacted EVC but for all
other EVCs on that port.</t> other EVCs on that port.</t>
<t> To reduce the scope of C-MAC flushing to only the impacted
<t> To reduce the scope of C-MAC flushing to only the impacted
service instances (the service instance(s) impacted by the EVC service instances (the service instance(s) impacted by the EVC
failure), the PBB-EVPN C-MAC flushing needs to be adapted on a per service failure), the PBB-EVPN C-MAC flushing needs to be adapted on a per-service-in
instance basis (i.e., per I-SID). <xref target="RFC9541"/> stance
introduces B-MAC/I-SID route where basis (i.e., per I-SID).
<!--[rfced] Please clarify "instead of NULL value". Is the intended
meaning that an I-SID is carried in the Ethernet Tag ID field
instead of in the NULL value (Perhaps A) or that the route is
modified to carry an I-SID instead of a NULL value (Perhaps B)?
Original:
[RFC9541] introduces B-MAC/I-SID route where existing PBB-EVPN B-MAC
route is modified to carry an I-SID in the "Ethernet Tag ID" field
instead of NULL value.
Perhaps A:
[RFC9541] introduces a B-MAC/I-SID route where the existing PBB-EVPN B-MAC
route is modified to carry an I-SID in the "Ethernet Tag ID" field instead
of in the NULL value.
or
Perhaps B:
[RFC9541] introduces a B-MAC/I-SID route where the existing PBB-EVPN B-MAC
route is modified to carry an I-SID, instead of a NULL value, in the
"Ethernet Tag ID" field.
-->
<xref target="RFC9541"/> introduces a B-MAC/I-SID route where the
existing PBB-EVPN B-MAC route is modified to carry an I-SID in the "Ethernet Tag ID" existing PBB-EVPN B-MAC route is modified to carry an I-SID in the "Ethernet Tag ID"
field instead of NULL value. This field indicates to the receiving PE, to flu sh all field instead of NULL value. To the receiving PE, this field indicates flushi ng all
C-MAC addresses associated with that I-SID for that B-MAC. This C-MAC flushin g mechanism per I-SID C-MAC addresses associated with that I-SID for that B-MAC. This C-MAC flushin g mechanism per I-SID
SHOULD be used in case of EVC failure impacting a vES. Since typically an EVC <bcp14>SHOULD</bcp14> be used in case of an EVC failure impacting a vES. Sinc
maps to a single e an EVC typically maps to a single
broadcast domain and thus, a single service instance, the affected PE only ne broadcast domain and thus a single service instance, the affected PE only nee
eds to ds to
advertise a single B-MAC/I-SID route. However, if the failed EVC carries mult advertise a single B-MAC/I-SID route.
iple
VLANs each with its own broadcast domain, then the affected PE needs to adver
tise multiple
B-MAC/I-SID routes - one for each VLAN (broadcast domain) - i.e., one for eac
h I-SID.
Each B-MAC/I-SID route basically instructs the remote PEs to perform flushing
for
C-MACs corresponding to the advertised B-MAC only for the advertised I-SID.</
t>
<t> The C-MAC flushing based on B-MAC/I-SID route works fine when there are o <!--[rfced] Please clarify if "one for each VLAN" is the same as "one
nly a few for each I-SID"? And does "one" mean "one route"?
VLANs (e.g., I-SIDs) per EVC. However if the number of I-SIDs associated with
a
failed EVC is large, then it is RECOMMENDED to assign a B-MAC per vES and upo
n EVC failure,
the affected PE simply withdraws this B-MAC message to other PEs. </t>
</section> Original:
However, if the failed EVC carries multiple VLANs each with its own
broadcast domain, then the affected PE needs to advertise multiple
B-MAC/I-SID routes - one for each VLAN (broadcast domain) - i.e.,
one for each I-SID.
<section title="Port Failure Handling for Single-Active vESes in EVPN" a Perhaps:
nchor="fail_port_sa_evpn"> However, if the failed EVC carries multiple VLANs each with its own
broadcast domain, then the affected PE needs to advertise multiple
B-MAC/I-SID routes, i.e., one route for each VLAN (broadcast domain),
meaning one route for each I-SID.
-->
<t> When many EVCs are aggregated via a single physical port However, if the failed EVC carries multiple
VLANs each with its own broadcast domain, then the affected PE needs to adver
tise multiple
B-MAC/I-SID routes -- one for each VLAN (broadcast domain) -- i.e., one for e
ach I-SID.
Each B&nbhy;MAC/I-SID route basically instructs the remote PEs to perform flu
shing for
C-MACs corresponding to the advertised B-MAC only for the advertised I-SID.</
t>
<t> The C-MAC flushing based on a B-MAC/I-SID route works fine when ther
e are only a few
VLANs (e.g., I-SIDs) per EVC. However, if the number of I-SIDs associated wit
h a
failed EVC is large, then it is <bcp14>RECOMMENDED</bcp14> to assign a B-MAC
per vES, and upon EVC failure,
the affected PE simply withdraws this B-MAC message to other PEs. </t>
</section>
<section anchor="fail_port_sa_evpn">
<name>Port Failure Handling for Single-Active vESes in EVPN</name>
<t> When many EVCs are aggregated via a single physical port
on a PE, where each EVC corresponds to a vES, then the port failure on a PE, where each EVC corresponds to a vES, then the port failure
impacts all the associated EVCs and their corresponding vESes. If the impacts all the associated EVCs and their corresponding vESes. If the
number of EVCs corresponding to the Single-Active vESes for that number of EVCs corresponding to the Single-Active vESes for that
physical port is in thousands, then thousands of service instances physical port is in the thousands, then thousands of service instances
are impacted. Therefore, the propagation of failure in BGP needs are impacted. Therefore, the propagation of failure in BGP needs
to address all these impacted service instances. In order to achieve this, to address all these impacted service instances. In order to achieve this,
the following extensions are added to the baseline EVPN mechanism: the following extensions are added to the baseline EVPN mechanism:
<list style="numbers"> </t>
<t> The PE MAY color each Ethernet A-D per ES route for a given vES, <ol spacing="normal" type="1"><li>
as described in <xref target="grouping_evpn"/>. PE SHOULD use the <t> The PE <bcp14>MAY</bcp14> color each Ethernet A-D per ES route
physical port MAC by default. for a given vES, as described in <xref
The receiving PEs take note of this color and create a list of vESes target="grouping_evpn"/>. The PE <bcp14>SHOULD</bcp14> use the
for this color.</t> MAC physical port by default. The receiving PEs take note of this
color and create a list of vESes for this color.</t>
</li>
<li>
<t>The PE <bcp14>MAY</bcp14> advertise a special Grouping
Ethernet A-D per ES route for that color, which represents all the
vESes associated with the port.</t>
</li>
<li>
<t> Upon a port failure (e.g., an ENNI failure), the PE
<bcp14>MAY</bcp14> send a mass-withdraw message by withdrawing the
Grouping Ethernet A-D per ES route.</t>
</li>
<li>
<t>The PE MAY advertises a special Grouping Ethernet A-D per ES route <!--[rfced] Please clarify what "(1)" is referring to in the
for that color, which represents all the vES associated with the port.</t> text below. Is "(1)" within the same section (Section 5.3) or a
different section? Or, perhaps "one (1)" was intended?
<t> Upon a port failure (e.g., ENNI failure), the PE MAY send a mass&nbhy;wit Original:
hdraw 4. When this message is received, the remote PE MAY detect the
message by withdrawing the Grouping Ethernet A-D per ES route.</t> special vES mass-withdraw message by identifying the Grouping
Ethernet A-D per ES route. The remote PEs MAY then access the
list created in (1) of the vESes for the specified color, and
initiate locally MAC address invalidating procedures for each of
the vESes in the list.
-->
<t> When this message is received, the remote PE MAY <t> When this message is received, the remote PE
detect the special vES mass&nbhy;withdraw message by identifying the <bcp14>MAY</bcp14> detect the special vES mass-withdraw message by
Grouping Ethernet A-D per ES route. The remote PEs MAY then access the list c identifying the Grouping Ethernet A-D per ES route. The remote PEs
reated <bcp14>MAY</bcp14> then access the list created in (1) of the
in (1) of the vESes for the vESes for the specified color and locally initiate MAC address
specified color, and initiate locally MAC address invalidating invalidating procedures for each of the vESes in the list. </t>
procedures for each of the vESes in the list. </t> </li>
</list> </ol>
<t>
In scenarios where a logical ENNI is used the above procedure equally In scenarios where a logical ENNI is used, the above procedure equally
applies. The logical ENNI is represented by a Grouping Ethernet A-D per ES applies. The logical ENNI is represented by a Grouping Ethernet A-D per ES
where the Type 3 ESI and the 6 bytes used in the ENNI's ESI MAC address where the Type 3 ESI and the 6 bytes used in the ENNI's ESI MAC address
field is used as a color for vESes as described above field are used as a color for the vESes as described above
and in <xref target="grouping_evpn"/>.</t> and in <xref target="grouping_evpn"/>.</t>
</section>
</section> <section anchor="fail_port_sa_pbbevpn">
<name>Port Failure Handling for Single-Active vESes in PBB-EVPN</name>
<section title="Port Failure Handling for Single-Active vESes in PBB-EVP <t>When many EVCs are aggregated via a single physical port
N" anchor="fail_port_sa_pbbevpn">
<t>When many EVCs are aggregated via a single physical port
on a PE, where each EVC corresponds to a vES, then the port failure on a PE, where each EVC corresponds to a vES, then the port failure
impacts all the associated EVCs and their corresponding vESes. If the impacts all the associated EVCs and their corresponding vESes. If the
number of EVCs corresponding to the Single-Active vESes for that number of EVCs corresponding to the Single-Active vESes for that
physical port is in thousands, then thousands of service instances physical port is in the thousands, then thousands of service instances (I-SID
(I-SIDs) are impacted. In such failure scenarios, the following two s) are impacted. In such failure scenarios, the following two
MAC flushing mechanisms per <xref target="RFC7623"/> can be performed. MAC flushing mechanisms per <xref target="RFC7623"/> can be performed.
<list style="numbers"> </t>
<ol spacing="normal" type="1"><li>
<t> If the MAC address of the physical port is used for PBB <t> If the MAC address of the physical port is used for PBB
encapsulation as B-MAC SA, then upon the port failure, the PE MUST use encapsulation as B-MAC SA, then upon the port failure, the PE
the EVPN MAC route withdrawal message to signal the flush.</t> <bcp14>MUST</bcp14> use the EVPN MAC route withdrawal message to
signal the flush.</t>
<t> If the PE shared MAC address is used for PBB encapsulation as B-MAC </li>
SA, then upon the port failure, the PE MUST re-advertise this MAC <li>
route with the MAC Mobility Extended Community to signal the flush.</t> <t> If the PE's shared MAC address is used for PBB encapsulation as
B-MAC SA, then upon the port failure, the PE <bcp14>MUST</bcp14>
</list> re-advertise this MAC route with the MAC Mobility Extended
Community to signal the flush.</t>
</li>
</ol>
<t>
The first method is recommended because it reduces the scope of The first method is recommended because it reduces the scope of
flushing the most. flushing the most.
</t> </t>
<t>As noted above, the
<t>As noted above, the advertisement of the extended community along with the B-MAC route for colori
advertisement of the extended community along with B-MAC route for coloring p ng purposes is optional
urposes is optional
and only recommended when there are many vESes per physical port and each vES is associated with and only recommended when there are many vESes per physical port and each vES is associated with
very large number of service instances (i.e., large number of I-SIDs). </t> a very large number of service instances (i.e., a large number of I-SIDs). </
t>
<t> If there are large number of service instances (i.e., I-SIDs) <t> If there are large numbers of service instances (i.e., I-SIDs)
associated with each EVC, and if there is a B-MAC assigned per vES associated with each EVC, and if there is a B-MAC assigned per vES
as recommended in the above section, then to handle as recommended in the above section, then in order to handle
port failure efficiently, the following extensions are added port failure efficiently, the following extensions are added
to the baseline PBB-EVPN mechanism: to the baseline PBB-EVPN mechanism:
<list style="numbers"> </t>
<t>Each vES MAY be colored with a MAC address representing the <ol spacing="normal" type="1">
<li>
<t>Each vES <bcp14>MAY</bcp14> be colored with a MAC address represe
nting the
physical port like the coloring mechanism for EVPN. physical port like the coloring mechanism for EVPN.
In other words, each B-MAC representing a vES is advertised In other words, each B-MAC representing a vES is advertised
with the 'color' of the physical port per <xref target="grouping_pbbevpn"/>. with the 'color' of the physical port per <xref target="grouping_pbbevpn"/>.
The receiving PEs take note of this color being advertised The receiving PEs take note of this color being advertised
along with the B-MAC route and for each such color, along with the B-MAC route, and for each such color, they
create a list of vESes associated with this color.</t> create a list of vESes associated with this color.</t>
</li>
<t>The PE MAY advertise a special Grouping B-MAC route <li>
for that color (consisting by default of port MAC address), <t>The PE <bcp14>MAY</bcp14> advertise a special Grouping B-MAC rout
which represents all the vES associated with the port.</t> e
for that color (consisting of a port MAC address by default),
<t> Upon a port failure (e.g., ENNI failure), the PE MAY send a mass&nbhy;wit which represents all the vESes associated with the port.</t>
hdraw </li>
<li>
<t> Upon a port failure (e.g., ENNI failure), the PE <bcp14>MAY</bcp
14> send a mass-withdraw
message by withdrawing the Grouping B-MAC route.</t> message by withdrawing the Grouping B-MAC route.</t>
</li>
<t> When this message is received, the remote PE MAY <li>
detect the special vES mass&nbhy;withdraw message by identifying the <t> When this message is received, the remote PE <bcp14>MAY</bcp14>
Grouping B-MAC route. The remote PEs MAY then access the list created detect the special vES mass-withdraw message by identifying the
in (1) for the Grouping B-MAC route. The remote PEs <bcp14>MAY</bcp14> then access the list
specified color, and flush all C-MACs associated with the failed physical por created
t. </t> in (1) above for the specified color and flush all C-MACs associated with the
failed physical port. </t>
</list> </li>
</t> </ol>
</section> </section>
<section anchor="convergence">
<section title="Fast Convergence in (PBB-)EVPN" anchor="convergence"> <name>Fast Convergence in EVPN and PBB-EVPN</name>
<t>As described above, when many EVCs are aggregated via a
<t>As described above, when many EVCs are aggregated via a physical port on a PE, and where each EVC corresponds to a vES, the
physical port on a PE, and where each EVC corresponds to a vES, then the
port failure impacts all the associated EVCs and their corresponding port failure impacts all the associated EVCs and their corresponding
vESes. Two actions must be taken as the result of such port failure: vESes. Two actions must be taken as the result of such a port failure:
<list style="symbols"> </t>
<t> For EVPN initiate mass&nbhy;withdraw procedure for all vESes associated w <ul spacing="normal">
ith <li>
the failed port to invalidate MACs and for PBB-EVPN flush all C-MACs associat <t> For EVPN, initiate the mass-withdraw procedure for all vESes ass
ed with ociated with
the failed port to invalidate MACs and for PBB-EVPN to flush all C-MACs assoc
iated with
the failed port across all vESes and the impacted I-SIDs </t> the failed port across all vESes and the impacted I-SIDs </t>
</li>
<li>
<t> Use DF election for all impacted vESes associated with the faile
d port </t>
</li>
</ul>
<t>
<t> DF election for all impacted vESes associated with the failed port </t> <xref target="fail_port_sa_evpn"/> already describes how to perform a mass wi
</list> thdraw
for all affected vESes and invalidate MACs using a single BGP withdrawal
<xref target="fail_port_sa_evpn"/> already describes how to perform mass&nbhy
;withdraw
for all affected vESes and invalidating MACs using a single BGP withdrawal
of the Grouping Ethernet A-D per ES route. of the Grouping Ethernet A-D per ES route.
<xref target="fail_port_sa_pbbevpn"/> describes how to only flush C-MAC addre ss <xref target="fail_port_sa_pbbevpn"/> describes how to only flush C-MAC addre sses
associated with the failed physical port (e.g., optimum C-MAC flushing) associated with the failed physical port (e.g., optimum C-MAC flushing)
as well as, optionally, the withdrawal of a Grouping B-MAC route.</t> as well as, optionally, the withdrawal of a Grouping B-MAC route.</t>
<t>This section describes how to perform DF election in the most
<t>This section describes how to perform DF election in the most optimal way, e.g., by triggering DF election for all impacted vESes
optimal way - e.g., to trigger DF election for all impacted vESes
(which can be very large) among the participating PEs via a single (which can be very large) among the participating PEs via a single
BGP message as opposed to sending large number of BGP messages (one per BGP message as opposed to sending a large number of BGP messages (one per
vES). This section assumes that the MAC flushing mechanism described in vES). This section assumes that the MAC flushing mechanism described in
<xref target="fail_port_sa_pbbevpn"/> is used and route coloring is used. <xref target="fail_port_sa_pbbevpn"/> and route coloring are used.
</t> </t>
<figure anchor="fig-4">
<figure> <name>Fast Convergence Upon ENNI Failure</name>
<preamble/> <artwork><![CDATA[
<artwork ><![CDATA[
+-----+ +-----+
+----+ | | +---+ +----+ | | +---+
| CE1|AC1--0=====0--ENNI1| | +-------+ | CE1|AC1--0=====0--ENNI1| | +-------+
| |AC2--0 | |PE1|--| | | |AC2--0 | |PE1|--| |
+----+ |\ ==0--ENNI2| | | | +----+ |\ ==0--ENNI2| | | |
| \/ | +---+ | | | \/ | +---+ | |
| /\ | |IP/MPLS| | /\ | |IP/MPLS|
+----+ |/ \ | +---+ |Network| +---+ +---+ +----+ |/ \ | +---+ |Network| +---+ +---+
| CE2|AC4--0 =0--ENNI3| | | |---|PE4|--|CE4| | CE2|AC4--0 =0--ENNI3| | | |---|PE4|--|CE4|
| |AC4--0=====0--ENNI3|PE2|--| | +---+ +---+ | |AC4--0=====0--ENNI3|PE2|--| | +---+ +---+
+----+ | ====0--ENNI3| | | | +----+ | ====0--ENNI3| | | |
|/ | +---+ | | |/ | +---+ | |
0 | | | 0 | | |
+----+ /| | +---+ | | +----+ /| | +---+ | |
| CE3|AC5- | | |PE3|--| | | CE3|AC5- | | |PE3|--| |
| |AC6--0=====0--ENNI4| | +-------+ | |AC6--0=====0--ENNI4| | +-------+
+----+ | | +---+ +----+ | | +---+
+-----+ +-----+]]></artwork>
</figure>
Figure 5: Fast Convergence Upon ENNI Failure
]]></artwork>
<postamble></postamble>
</figure>
<t> <t>
As discussed in <xref target="grouping"/>, it is highly desirable to have a As discussed in <xref target="grouping"/>, it is highly desirable to have a
mass withdraw mechanism similar to the one in <xref target="RFC7432"/> . Alth mass-withdraw mechanism similar to the one in <xref target="RFC7432"/>. Altho
ough ugh
such an optimization is desirable, it is OPTIONAL. If the optimization is such an optimization is desirable, it is <bcp14>OPTIONAL</bcp14>. If the opti
implemented, the following describes the procedure: mization is
implemented, the following procedures are used:
<list style="numbers"> </t>
<t> When a vES is configured, the PE advertises the Ethernet Segment route <ol spacing="normal" type="1">
<li>
<t> When a vES is configured, the PE advertises the Ethernet Segment
route
for this vES with a color that corresponds to the associated physical port. < /t> for this vES with a color that corresponds to the associated physical port. < /t>
</li>
<t> All receiving PEs within the redundancy group record this color and <li>
<t> All receiving PEs within the redundancy group record this color
and
compile a list of vESes associated with it. </t> compile a list of vESes associated with it. </t>
</li>
<t> Additionally, the PE advertises a Grouping Ethernet A-D per ES for EVPN, <li>
<t> Additionally, the PE advertises a Grouping Ethernet A-D per ES f
or EVPN,
and a Grouping B-MAC for PBB-EVPN, which corresponds to the color and vES gro uping. </t> and a Grouping B-MAC for PBB-EVPN, which corresponds to the color and vES gro uping. </t>
</li>
<t> In the event of a port failure, such as an ENNI failure, the PE withdraws <li>
<t> In the event of a port failure, such as an ENNI failure, the PE
withdraws
the previously advertised Grouping Ethernet A-D per ES or Grouping B-MAC asso ciated the previously advertised Grouping Ethernet A-D per ES or Grouping B-MAC asso ciated
with the failed port. The PE should prioritize sending these Grouping route w ithdrawal with the failed port. The PE should prioritize sending these Grouping route w ithdrawal
messages over the withdrawal of individual vES routes affected by the failure . For messages over the withdrawal of individual vES routes affected by the failure . For
instance, as depicted in Figure 5, when the physical port associated with ENN I3 fails instance, as depicted in <xref target="fig-4"/>, when the physical port assoc iated with ENNI3 fails
on PE2, it withdraws the previously advertised Grouping Ethernet A-D per ES r oute. on PE2, it withdraws the previously advertised Grouping Ethernet A-D per ES r oute.
Upon receiving this withdrawal message, other multi-homing PEs (such as PE1 a nd PE3) Upon receiving this withdrawal message, other multi-homing PEs (such as PE1 a nd PE3)
recognize that the vESes associated with CE1 and CE3 are impacted, based on t he associated recognize that the vESes associated with CE1 and CE3 are impacted, based on t he associated
color, and thus initiate the DF election procedure for these vESes. Furthermo color, and thus initiate the DF election procedure for these vESes. Furthermo
re, remote re, upon receiving this withdrawal message, remote PEs (such as PE4) initiate th
PEs (such as PE4), upon receiving this withdrawal message, initiate the failo e failover procedure
ver procedure for the vESes associated with CE1 and CE3 and switch to the other PE for each
for the vESes associated with CE1 and CE3, and switch to the other PE for eac vES
h vES
redundancy group. </t> redundancy group. </t>
</li>
<t> On reception of Grouping Ethernet A-D per ES or Grouping B-MAC route with <li>
drawal, <t> On reception of Grouping Ethernet A-D per ES or Grouping B-MAC r
oute withdrawal,
other PEs in the redundancy group initiate DF election procedures other PEs in the redundancy group initiate DF election procedures
across all their affected vESes. </t> across all their affected vESes. </t>
</li>
<t> The PE with the physical port failure (ENNI failure), sends <li>
vES route withdrawal for every impacted vES. The other PEs upon <t> The PE with the physical port failure (ENNI failure) sends a
receiving these messages, clear up their BGP tables. It should be vES route withdrawal for every impacted vES. Upon
noted the vES route withdrawal messages are not used for executing DF receiving these messages, the other PEs clear up their BGP tables. It should
be
noted that the vES route withdrawal messages are not used for executing DF
election procedures by the receiving PEs when Grouping Ethernet A-D per ES election procedures by the receiving PEs when Grouping Ethernet A-D per ES
or Grouping B-MAC withdrawal has been previously received. </t> or Grouping B-MAC withdrawal has been previously received. </t>
</list> </li>
</t> </ol>
</section> </section>
</section>
<section title="Acknowledgements">
<t>
The authors would like to thank Mei Zhang, Jose Liste, and Luc&nbsp;Andre&nbs
p;Burdet for their
reviews of this document and feedback.
</t>
</section> </section>
<section title="Security Considerations"> <section>
<t> <name>Security Considerations</name>
<t>
All the security considerations in <xref target="RFC7432"/> and <xref target= "RFC7623"/> apply All the security considerations in <xref target="RFC7432"/> and <xref target= "RFC7623"/> apply
directly to this document because this document leverages the control directly to this document because this document leverages the control
and data plane procedures described in those documents. and data plane procedures described in those documents.
</t> </t>
<t> <t>
This document does not introduce any new security considerations This document does not introduce any new security considerations
beyond that of <xref target="RFC7432"/> and <xref target="RFC7623"/> because beyond that of <xref target="RFC7432"/> and <xref target="RFC7623"/> because
advertisements and advertisements and the
processing of Ethernet Segment route for vES in this document follows processing of Ethernet Segment routes for vES in this document follow
that of physical ES in those RFCs. that of physical ES in those RFCs.
</t> </t>
</section> </section>
<section>
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t> <t>
This document requests no actions from IANA. This document has no IANA actions.
</t> </t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<references title="Normative References"> <references>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119. <name>References</name>
xml"/> <references>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174. <name>Normative References</name>
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7432. 119.xml"/>
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7623. 174.xml"/>
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8214. 432.xml"/>
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9135. 623.xml"/>
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8365. 214.xml"/>
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9541. 135.xml"/>
xml"/> <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.9
541.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
209.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
584.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
080.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
023.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
377.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
310.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
252.xml"/>
<!-- [rfced] We found the following URL for [MEF63]:
https://www.mef.net/resources/mef-6-3-subscriber-ethernet-service-definitions/.
May we add this URL to the reference entry for easy access?
Original:
[MEF63] Metro Ethernet Forum, "Subscriber Ethernet Services
Definitions", MEF Standard, MEF 6.3, November 2019.
Perhaps:
[MEF63] Metro Ethernet Forum, "Subscriber Ethernet Services
Definitions", MEF Standard, MEF 6.3, November 2019,
<https://www.mef.net/resources/mef-6-3-subscriber-
ethernet-service-definitions>.
-->
<reference anchor="MEF63">
<front>
<title>Subscriber Ethernet Services Definitions</title>
<author>
<organization>Metro Ethernet Forum</organization>
</author>
<date month="11" year="2019"/>
</front>
<seriesInfo name="MEF" value="6.3"/>
<refcontent>MEF Standard</refcontent>
</reference>
</references>
</references> </references>
<references title="Informative References">
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7209.
xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8584.
xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7080.
xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7023.
xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4377.
xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6310.
xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9252.
xml"/>
<reference anchor="MEF63">
<front>
<title>[MEF6.3]: Subscriber Ethernet Services Definitions</title>
<author initials="MEF" surname="Metro Ethernet Forum">
<organization></organization>
</author>
<date year="2019"/>
</front>
</reference>
</references> <section numbered="false">
</back> <name>Acknowledgements</name>
<t>
The authors would like to thank <contact fullname="Mei Zhang"/>, <contact
fullname="Jose Liste"/>, and <contact fullname="Luc André Burdet"/> for
their reviews of this document and their feedback.
</t>
</section>
<!-- [rfced] Terminology
a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how
they may be made consistent.
Ethernet A-D per ES route (16) vs.
Ethernet A-D per ES (5)
[Note: should "route" be added to the 5 instances that
do not include it?
MAC Mobility Extended Community vs.
MAC Mobility Extended community vs.
MAC mobility Extended community
[Note that the case used in RFCs 7432 and 7623 is
"MAC Mobility extended community".]
b) For consistency, we updated the document to use the form on the
right. Please let us know of any objections.
Core Network -> core network
DF Election -> DF election
Ethernet segment -> Ethernet Segment
Multi-Homed and Multi-homed -> multi-homed
Redundancy Group -> redundancy group
Service Provider -> service provider
Single-homed -> single-homed
c) May "multi-homed" and "multi-homing"
be changed to "multihomed" and "multihoming" per common
use in the RFC series (and in particular, in RFCs 7432,
7623, and 8584)? Your reply to this will be applied to the
other documents in this cluster (9785 and 9786).
-->
<!-- [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.
- Label Distribution Protocol (LDP)
- Media Access Control (MAC)
b) For consistency (within the RFC series and cluster 492), we updated
this document to use the forms on the right. Please let us know of
any objections.
All-Active Redundancy Mode (AA) -> All-Active (AA) Redundancy Mode
Broadcast, Unknown-unicast, Multicast (BUM) ->
Broadcast, Unknown Unicast, and Multicast (BUM) (per RFC 7432)
External Network-to-Network Interface (ENNI) (Section 1.2) vs.
External Network-Network Interface (Section 2)
-> updated to the latter for consistency.
Provider Backbone (PBB) -> Provider Backbone Bridge (PBB) (per RFC 7623)
Single-Active Redundancy Mode (SA) -> Single-Active (SA) Redundancy Mode
Virtual Pseudowire Service (VPWS) ->
Virtual Private Wire Service (VPWS) (per RFC 8214)
c) Please let us know how we may expand the following term:
- SH (in the title of Figure 1)
d) As recommended in the Web Portion of the Style Guide
<https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>,
once an abbreviation is introduced, the abbreviated form
should be used thereafter. Please consider if you would
like to apply this style for the following term:
- Ethernet Segment (ES) -> use "ES" thereafter
-->
<!-- [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.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back>
</rfc> </rfc>
 End of changes. 164 change blocks. 
841 lines changed or deleted 1075 lines changed or added

This html diff was produced by rfcdiff 1.48.