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 " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<!-- 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" ?> | ||||
<!-- give errors regarding ID-nits and DTD validation --> | ||||
<?rfc compact="yes" ?> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie | |||
<!-- do not start each main section on a new page --> | tf-bess-evpn-virtual-eth-segment-19" number="9784" obsoletes="" updates="" conse | |||
<?rfc subcompact="no" ?> | nsus="true" submissionType="IETF" ipr="trust200902" tocInclude="true" tocDepth=" | |||
<!-- keep one blank line between list items --> | 4" symRefs="true" sortRefs="true" version="3" xml:lang="en"> | |||
<rfc category="std" | ||||
xmlns:xi="http://www.w3.org/2001/XInclude" | ||||
docName="draft-ietf-bess-evpn-virtual-eth-segment-19" | ||||
obsoletes="" | ||||
updates="" | ||||
consensus="true" | ||||
submissionType="IETF" | ||||
ipr="trust200902" | ||||
tocInclude="true" | ||||
tocDepth="4" | ||||
symRefs="true" | ||||
sortRefs="true"> | ||||
<!-- ***** FRONT MATTER ***** --> | ||||
<front> | <front> | |||
<!-- The abbreviated title is used in the page header - it is only necessary | <title abbrev="EVPN Virtual Ethernet Segments">Virtual Ethernet Segments for | |||
if the | EVPN and Provider Backbone Bridge EVPN </title> | |||
full title is longer than 39 characters --> | <seriesInfo name="RFC" value="9784"/> | |||
<author initials="A" surname="Sajassi" fullname="Ali Sajassi"> | ||||
<title abbrev="EVPN Virtual Ethernet Segment"> EVPN Virtual Ethernet Segment | <organization>Cisco Systems</organization> | |||
</title> | <address> | |||
<email>sajassi@cisco.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="P" surname="Brissette" fullname="Patrice Brissette"> | ||||
<organization>Cisco Systems</organization> | ||||
<address> | ||||
<email>pbrisset@cisco.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="R" surname="Schell" fullname="Rick Schell"> | ||||
<organization>Verizon</organization> | ||||
<address> | ||||
<email>richard.schell@verizon.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="J" surname="Drake" fullname="John E Drake"> | ||||
<organization>Juniper</organization> | ||||
<address> | ||||
<email>jdrake@juniper.net</email> | ||||
</address> | ||||
</author> | ||||
<author initials="J" surname="Rabadan" fullname="Jorge Rabadan"> | ||||
<organization>Nokia</organization> | ||||
<address> | ||||
<email>jorge.rabadan@nokia.com</email> | ||||
</address> | ||||
</author> | ||||
<date year="2025" month="May"/> | ||||
<area>RTG</area> | ||||
<workgroup>bess</workgroup> | ||||
<author initials="A" surname="Sajassi" fullname="Ali Sajassi"> | <!-- [rfced] Please insert any keywords (beyond those that appear in | |||
<organization>Cisco Systems</organization> | the title) for use on https://www.rfc-editor.org/search. | |||
<address> | --> | |||
<email>sajassi@cisco.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="P" surname="Brissette" fullname="Patrice Brissette"> | ||||
<organization>Cisco Systems</organization> | ||||
<address> | ||||
<email>pbrisset@cisco.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="R" surname="Schell" fullname="Rick Schell"> | ||||
<organization>Verizon</organization> | ||||
<address> | ||||
<email>richard.schell@verizon.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="J" surname="Drake" fullname="John E Drake"> | ||||
<organization>Juniper</organization> | ||||
<address> | ||||
<email>jdrake@juniper.net</email> | ||||
</address> | ||||
</author> | ||||
<author initials="J" surname="Rabadan" fullname="Jorge Rabadan"> | ||||
<organization>Nokia</organization> | ||||
<address> | ||||
<email>jorge.rabadan@nokia.com</email> | ||||
</address> | ||||
</author> | ||||
<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 | multihoming 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 multihomed 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 ES 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 | multihoming 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 ES by allowing an ES to be | |||
S to be | associated with a set of Ethernet Virtual Circuits (EVCs) (such as VLANs) or | |||
associated with a set of Ethernet Virtual Circuits (EVCs, such as VLANs) or o | other | |||
ther | 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 (vESes). This do | |||
extended concept is referred to as virtual Ethernet Segments (vES). This draf | cument | |||
t | ||||
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 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 multihomed 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) That is Single-Homed on the Sam | |||
</figure> | e ENNI</name> | |||
<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 multihomed 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 multihomed ESs, and when multihomed, 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 194 ¶ | |||
| 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> | |||
<t> In some cases, the aggregation of PWs that share the same LSP pair | ||||
<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. | |||
may not be possible. For instance, if PW3 were terminated into a third PE, e. | g., | |||
g. | PE3, instead of PE1, the vES would need to be defined on each PW on each PE.< | |||
PE3, instead of PE1, the vES would need to be defined on a per | /t> | |||
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 multihoming | ||||
<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 | ||||
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 multihoming 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 title="Terminology"> | ||||
<t> | ||||
<list style="hanging" hangIndent="10"> | ||||
<t hangText="AC:">Attachment Circuit</t> | ||||
<t hangText="B-MAC:">Backbone MAC Address </t> | ||||
<t hangText="CE:">Customer Edge Device </t> | ||||
<t hangText="C-MAC:">Customer/Client MAC Address </t> | ||||
<t hangText="DF:">Designated Forwarder</t> | ||||
<t hangText="ENNI:">External Network-Network Interface </t> | ||||
<t hangText="ES:">Ethernet Segment </t> | ||||
<t hangText="ESI:">Ethernet Segment Identifier </t> | ||||
<t hangText="Ethernet A-D:">Ethernet Auto-Discovery Route </t> | ||||
<t hangText="EVC:">Ethernet Virtual Circuit, <xref target="MEF63"/> </t> | ||||
<t hangText="EVI:">EVPN Instance </t> | ||||
<t hangText="EVPN:">Ethernet VPN </t> | ||||
<t hangText="I-SID:">Service Instance Identifier (24 bits and global wit | ||||
hin a PBB | ||||
network see <xref target="RFC7080"/>) </t> | ||||
<t hangText="PBB:">Provider Backbone Bridge </t> | ||||
<t hangText="PBB-EVPN:">Provider Backbone Bridge EVPN </t> | ||||
<t hangText="PE:">Provider Edge Device </t> | ||||
<t hangText="VPWS:">Virtual Pseudowire Service</t> | ||||
<t hangText="Single-Active Redundancy Mode (SA):">When only a single PE, | ||||
among a | ||||
group of PEs attached to an Ethernet Segment, is allowed to forward | ||||
traffic to/from that Ethernet Segment, then the Ethernet Segment is | ||||
defined to be operating in Single-Active redundancy mode. </t> | ||||
<t hangText="All-Active Redundancy Mode (AA):">When all PEs attached to | ||||
an Ethernet | ||||
segment, are allowed to forward traffic to/from that Ethernet Segment, | ||||
then the Ethernet Segment is defined to be operating in All-Active | ||||
redundancy mode. </t> | ||||
</list> | ||||
</t> | ||||
</section> | </section> | |||
<section> | ||||
<section title="Requirements" anchor="requirements"> | <name>Terminology</name> | |||
<dl newline="false" spacing="normal" indent="10"> | ||||
<t> This section describes the requirements specific to virtual Ethernet | <dt>AC:</dt> | |||
Segment (vES) for (PBB-)EVPN solutions. These requirements are in | <dd>Attachment Circuit</dd> | |||
<dt>B-MAC:</dt> | ||||
<dd>Backbone MAC Address </dd> | ||||
<dt>CE:</dt> | ||||
<dd>Customer Edge</dd> | ||||
<dt>C-MAC:</dt> | ||||
<dd>Customer/Client MAC Address </dd> | ||||
<dt>DF:</dt> | ||||
<dd>Designated Forwarder</dd> | ||||
<dt>ENNI:</dt> | ||||
<dd>External Network-Network Interface </dd> | ||||
<dt>ES:</dt> | ||||
<dd>Ethernet Segment </dd> | ||||
<dt>ESI:</dt> | ||||
<dd>Ethernet Segment Identifier </dd> | ||||
<dt>Ethernet A-D:</dt> | ||||
<dd>Ethernet Auto-Discovery </dd> | ||||
<dt>EVC:</dt> | ||||
<dd>Ethernet Virtual Circuit <xref target="MEF63"/> </dd> | ||||
<dt>EVI:</dt> | ||||
<dd>EVPN Instance </dd> | ||||
<dt>EVPN:</dt> | ||||
<dd>Ethernet VPN </dd> | ||||
<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 ES, is allowed to forward | ||||
traffic to/from that ES, the ES is | ||||
defined as operating in Single-Active redundancy mode. </dd> | ||||
<dt>All-Active (AA) Redundancy Mode:</dt> | ||||
<dd>When all PEs attached to an ES are allowed to forward traffic to/fro | ||||
m that ES, | ||||
the ES is defined as operating in All-Active | ||||
redundancy mode. </dd> | ||||
</dl> | ||||
</section> | ||||
<section anchor="requirements"> | ||||
<name>Requirements</name> | ||||
<t> This section describes the requirements specific to vES for EVPN and P | ||||
BB-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 Multihomed 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 multihomed 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 multihomed vESes will be referred to as | |||
a single ENNI. </t> | "Single-Active vESes". </li> | |||
<li>The PE <bcp14>MAY</bcp14> support All-Active multihomed | ||||
<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 | multihomed 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 multihomed 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> | |||
<t> (R3a) A PE device that supports the vES function MUST support local switc | <ol type="(R2%c)"> | |||
hing | <li>A PE device that supports the vES function <bcp14>MUST</bcp14> suppo | |||
among different vESes associated with the same service instance on a single p | rt local switching among different vESes associated with the same service instan | |||
hysical | ce on a single physical port. For instance, in <xref target="fig-1"/>, PE1 must | |||
port. For instance, in Figure 1, PE1 must support local switching between CE1 | support local switching between CE11 and CE12, which are mapped to two single-ho | |||
1 and CE12, | med vESes on ENNI1. In the case of Single-Active vESes, the local switching is p | |||
which are mapped to two single-homed vESes on ENNI1. In the case of Single-Ac | erformed among active EVCs associated with the same service | |||
tive vESes, | instance on the same ENNI. </li> | |||
the local switching is performed among active EVCs associated with the same s | </ol> | |||
ervice | </section> | |||
instance on the same ENNI. </t> | <section> | |||
</section> | <name>EVC Service Types</name> | |||
<t> A physical port, such as an ENNI of a PE device, can aggregate numer | ||||
<section title="EVC Service Types"> | ous | |||
<t> A physical port, such as an ENNI of a PE device, can aggregate numerous | ||||
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="(R3%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="(R3%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 | <ol type="(R4%c)"> | |||
ng | <li>A PE that supports vES function <bcp14>MUST</bcp14> support a vES wi | |||
n ENNIs belonging to p PEs in any arbitrary order; where n >= p >= m >=2. | th m EVCs among | |||
n ENNIs belonging to p PEs in any arbitrary order, where n >= p >= m &g | ||||
t;=2. | ||||
For example, if there is a vES with 2 EVCs and there are 5 ENNIs on 5 PEs | 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 | (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> | election must be performed between PE2 and PE4.</li> | |||
<li>Each vES <bcp14>MUST</bcp14> be identified by its own virtual ESI (v | ||||
<t> (Rbc) Each vES MUST be identified by its own virtual ESI (vESI). </t> | ESI). </li> | |||
</section> | </ol> | |||
</section> | ||||
<section title="EVC Monitoring"> | <section> | |||
<name>EVC Monitoring</name> | ||||
<t> To detect the failure of an individual EVC and subsequently perform DF | <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="(R5%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="(R6%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 | ||||
<t> (R7d) Failure and failure recovery of an EVC for a Single-Active vES | <bcp14>MUST</bcp14> only impact C-MACs associated with a multihomed device/ne | |||
MUST only impact C-MACs associated with multi-homed device/network for that s | twork for that service | |||
ervice | instance. In other words, MAC flushing <bcp14>MUST</bcp14> be limited to a si | |||
instance. In other words, MAC flushing MUST be limited to single | ngle | |||
service instance (I-SID in the case of PBB-EVPN) and only C-MACs for | service instance (I-SID in the case of PBB-EVPN) and only C-MACs for a | |||
Single-Active multi-homed device/network. </t> | Single-Active multihomed device/network. </li> | |||
</ol> | ||||
</section> | </section> | |||
<section> | ||||
<section title="Fast Convergence"> | <name>Fast Convergence</name> | |||
<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="(R7%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 multihomed 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 | ||||
address assignment which is performed similar to what is described in | ||||
section 7.2.1.1 of <xref target="RFC7623"/> with the following refinements: | ||||
<list style="symbols"> | <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="6.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 ES route with the | ||||
<t> The PE then starts a timer (default value = 3 seconds) to allow | 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 | ||||
<t> When the timer expires, each PE builds an ordered list of the IP | allow the reception of ES routes from other PE nodes | |||
addresses of all the PE nodes connected to the vES (including | connected to the same vES. This timer value <bcp14>MUST</bcp14> be | |||
itself), in increasing numeric value. Each IP address in this list is | the same across all PEs connected to the same vES. </t> | |||
extracted from the "Originator Router's IP address" field of the | </li> | |||
advertised Ethernet Segment route. Every PE is then given an ordinal | <li> | |||
indicating its position in the ordered list, starting with 0 as the | <t> When the timer expires, each PE builds an ordered list of the | |||
ordinal for the PE with the numerically lowest IP address. The | IP addresses of all the PE nodes connected to the vES (including | |||
ordinals are used to determine which PE node will be the DF for a | itself), in increasing numeric value. Each IP address in this list | |||
given EVPN instance on the vES using the following rule: Assuming a | is extracted from the "Originator Router's IP address" field of | |||
redundancy group of N PE nodes, the PE with ordinal i is the DF for | the advertised ES route. Every PE is then given an | |||
an EVPN instance with an associated Ethernet Tag value of V when (V | ordinal indicating its position in the ordered list, starting with | |||
mod N) = i. | 0 as the ordinal for the PE with the numerically lowest IP | |||
It should be noted that using "Originator Router's IP address" field | address. The ordinals are used to determine which PE node will be | |||
in the Ethernet Segment route to get the PE IP address needed for the | the DF for a given EVPN instance on the vES using the following | |||
ordered list, allows for a CE to be multi&nbhy;homed across different ASes | rule: Assuming a redundancy group of N PE nodes, the PE with | |||
if such need ever arises. </t> | 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 | ||||
<t> The PE that is elected as a DF for a given EVPN instance will | that using the "Originator Router's IP address" field in the ES | |||
unblock traffic for that EVPN instance. Note that the DF PE unblocks | route to get the PE IP address needed for the ordered | |||
all traffic in both ingress and egress directions for Single-Active | list allows a CE to be multihomed across different ASes, if | |||
vES and unblocks multi&nbhy;destination in egress direction for All-Active | such need ever arises. </t> | |||
Multi-homed vES. All non-DF PEs block all traffic in both ingress and | </li> | |||
egress directions for Single-Active vES and block multi&nbhy;destination | <li> | |||
traffic in the egress direction for All-Active vES. </t> | <t> The PE that is elected as a DF for a given EVPN instance will | |||
</list> | unblock traffic for that EVPN instance. Note that the DF PE | |||
</t> | unblocks all traffic in both ingress and egress directions for | |||
Single-Active vESes and unblocks multi-destination in the egress | ||||
<t> In case of an EVC failure, the affected PE withdraws its corresponding Et | direction for All-Active multihomed vESes. All non-DF PEs block all | |||
hernet | traffic in both ingress and egress directions for Single-Active | |||
Segment route if there are no more EVCs associated to the vES in the | vESes and block multi-destination traffic in the egress direction | |||
PE. This will re-trigger the DF Election procedure on all the PEs in | for All-Active vESes. </t> | |||
the Redundancy Group. For PE node failure, or upon PE commissioning | </li> | |||
or decommissioning, the PEs re-trigger the DF Election procedure | </ol> | |||
across all affected vESes. In case of a Single-Active, | <t> In case of an EVC failure, the affected PE withdraws its correspondi | |||
when a service moves from one PE in the Redundancy Group to another | ng ES 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, MUST trigger a MAC address flush | the redundancy group. For PE node failure, or upon PE commissioning | |||
notification towards the associated vES if the multi-homing device is a bridg | or decommissioning, the PEs re-trigger the DF election procedure | |||
e | across all affected vESes. | |||
or the multi-homing network is an Ethernet bridged network.</t> | In case of a Single-Active scenario, | |||
when a service moves from one PE in the redundancy group to another | ||||
<t> For LSP-based and PW-based vES, the non-DF PE SHOULD signal PW-status | PE because of DF re-election, the PE (which ends up being the | |||
'standby' to the Aggregation PE (e.g., AG1 and AG2 in Figure 2), | elected DF for the service) <bcp14>MUST</bcp14> trigger a MAC address flush | |||
and a new DF PE MAY send an LDP MAC withdraw message as a MAC | notification towards the associated vES if the multihoming device is a bridge | |||
or the multihoming network is an Ethernet bridged network.</t> | ||||
<t> For LSP-based and PW-based vES, the non-DF PE <bcp14>SHOULD</bcp14> | ||||
signal PW-status | ||||
'standby' to the Aggregation PE (e.g., AG1 and AG2 in <xref target="fig-2"/>) | ||||
, | ||||
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 | per ES routes and Grouping of B-MAC addresses will be essential for a | |||
with the B-MAC route.</t> | ddressing port | |||
failure handling, as discussed in Sections <xref target="fail_port_sa | ||||
<t> The subsequent sections detailing Grouping of Ethernet Auto-Discover | _evpn" format="counter"/>, | |||
y (A-D) | <xref target="fail_port_sa_pbbevpn" format="counter"/>, and <xref tar | |||
per ES and Grouping of B-MAC addresses will be essential for addressi | get="convergence" format="counter"/>. </t> | |||
ng port | <section anchor="grouping_evpn"> | |||
failure handling, as discussed in Sections <xref target="fail_port_sa | <name>EVPN Route Coloring for vES</name> | |||
_evpn"/>, | <t>When a PE discovers the vESI or is configured with the vESI associa | |||
<xref target="fail_port_sa_pbbevpn"/>, and <xref target="convergence" | ted | |||
/>. </t> | with its attached vES, an ES route and Ethernet A-D per ES | |||
<section title="EVPN Route Coloring for vES" anchor="grouping_evpn"> | ||||
<t>When a PE discovers the vESI or is configured with the vESI assoc | ||||
iated | ||||
with its attached vES, an Ethernet-Segment route and Ethernet A-D pe | ||||
r ES | ||||
route are generated using the vESI identifier.</t> | route are generated using the vESI identifier.</t> | |||
<t>These ES and Ethernet A-D per ES routes specific to each | ||||
<t>These Ethernet-Segment and Ethernet A-D per ES routes specific to | ||||
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 | and advertised along with the ES and Ethernet A-D per ES | |||
ES | routes for this vES. The color (which is the MAC address of the port | |||
routes for this vES. The color (which is the MAC address of the port | ) <bcp14>MUST</bcp14> | |||
) MUST | ||||
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 multih | |||
</figure> | omed ES loses connectivity to the segment, due to link or port | |||
failure, it signals the remote PEs to invalidate all MAC addresses | ||||
<section title="EVC Failure Handling for Single-Active vES in EVPN" anch | associated with that ES. This is done by means of a | |||
or="fail_evc_sa_evpn"> | mass-withdraw message, by withdrawing the Ethernet A-D per ES route. | |||
<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 | ||||
failure, it signals to the remote PEs to invalidate all MAC addresses | ||||
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. | ||||
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 | |||
ES | ||||
<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 ES. 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). | |||
existing PBB-EVPN B-MAC route is modified to carry an I-SID in the "Ethernet | ||||
Tag ID" | <xref target="RFC9541"/> introduces a B-MAC/I-SID route where the | |||
field instead of NULL value. This field indicates to the receiving PE, to flu | existing PBB-EVPN B-MAC route is modified to carry an I-SID, instead of a NUL | |||
sh all | L value, in the "Ethernet Tag ID" field. To the receiving PE, this field indicat | |||
es flushing 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 | However, if the failed EVC carries multiple | |||
VLANs each with its own broadcast domain, then the affected PE needs to adver tise 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 eac | B-MAC/I-SID routes, i.e., one route for each VLAN (broadcast domain), meaning | |||
h I-SID. | one route for each I-SID. | |||
Each B-MAC/I-SID route basically instructs the remote PEs to perform flushing | Each B&nbhy;MAC/I-SID route basically instructs the remote PEs to perform flu | |||
for | shing for | |||
C-MACs corresponding to the advertised B-MAC only for the advertised I-SID.</ t> | 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 | ||||
<t> The C-MAC flushing based on B-MAC/I-SID route works fine when there are o | e are only a few | |||
nly a few | VLANs (e.g., I-SIDs) per EVC. However, if the number of I-SIDs associated wit | |||
VLANs (e.g., I-SIDs) per EVC. However if the number of I-SIDs associated with | h a | |||
a | failed EVC is large, then it is <bcp14>RECOMMENDED</bcp14> to assign a B-MAC | |||
failed EVC is large, then it is RECOMMENDED to assign a B-MAC per vES and upo | per vES, and upon EVC failure, | |||
n EVC failure, | ||||
the affected PE simply withdraws this B-MAC message to other PEs. </t> | the affected PE simply withdraws this B-MAC message to other PEs. </t> | |||
</section> | ||||
</section> | <section anchor="fail_port_sa_evpn"> | |||
<name>Port Failure Handling for Single-Active vESes in EVPN</name> | ||||
<section title="Port Failure Handling for Single-Active vESes in EVPN" a | <t> When many EVCs are aggregated via a single physical port | |||
nchor="fail_port_sa_evpn"> | ||||
<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> | ||||
<t>The PE MAY advertises a special Grouping Ethernet A-D per ES route | </li> | |||
for that color, which represents all the vES associated with the port.</t> | <li> | |||
<t>The PE <bcp14>MAY</bcp14> advertise a special Grouping | ||||
<t> Upon a port failure (e.g., ENNI failure), the PE MAY send a mass&nbhy;wit | Ethernet A-D per ES route for that color, which represents all the | |||
hdraw | vESes associated with the port.</t> | |||
message by withdrawing the Grouping Ethernet A-D per ES route.</t> | </li> | |||
<li> | ||||
<t> When this message is received, the remote PE MAY | <t> Upon a port failure (e.g., an ENNI failure), the PE | |||
detect the special vES mass&nbhy;withdraw message by identifying the | <bcp14>MAY</bcp14> send a mass-withdraw message by withdrawing the | |||
Grouping Ethernet A-D per ES route. The remote PEs MAY then access the list c | Grouping Ethernet A-D per ES route.</t> | |||
reated | </li> | |||
in (1) of the vESes for the | <li> | |||
specified color, and initiate locally MAC address invalidating | <t> When this message is received, the remote PE | |||
procedures for each of the vESes in the list. </t> | <bcp14>MAY</bcp14> detect the special vES mass-withdraw message by | |||
</list> | identifying the Grouping Ethernet A-D per ES route. The remote PEs | |||
<bcp14>MAY</bcp14> then access the list of vESes created | ||||
per item 1 for the specified color and locally initiate MAC address | ||||
invalidating procedures for each of the vESes in the list. </t> | ||||
</li> | ||||
</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 | route 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 ES 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> | |||
and a Grouping B-MAC for PBB-EVPN, which corresponds to the color and vES gro | <t> Additionally, the PE advertises a Grouping Ethernet A-D per ES r | |||
uping. </t> | oute for EVPN, | |||
and a Grouping B-MAC route for PBB-EVPN, which corresponds to the color and v | ||||
<t> In the event of a port failure, such as an ENNI failure, the PE withdraws | ES grouping. </t> | |||
the previously advertised Grouping Ethernet A-D per ES or Grouping B-MAC asso | </li> | |||
ciated | <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 route or Grouping B-MA | ||||
C route associated | ||||
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 multihoming PEs (such as PE1 an d 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 route or Grouping B | |||
-MAC route 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> | route or Grouping B-MAC route 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 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 ES 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"/> | ||||
<reference anchor="MEF63" target="https://www.mef.net/resources/mef-6-3- | ||||
subscriber-ethernet-service-definitions"> | ||||
<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 | ||||
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 | ||||
c) Please let us know how we may expand the following term: | ||||
- SH (in the title of Figure 1) | ||||
--> | ||||
</back> | ||||
</rfc> | </rfc> | |||
End of changes. 139 change blocks. | ||||
889 lines changed or deleted | 879 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |