rfc9541xml2.original.xml   rfc9541.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC7623 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbsp "&#160;">
C.7623.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbhy "&#8209;">
C.7432.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC4762 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4762.xml">
<!ENTITY I-D.ietf-bess-evpn-virtual-eth-segment SYSTEM "https://xml2rfc.ietf.org
/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-virtual-eth-segment.xml">
]> ]>
<rfc category="std" docName="draft-ietf-bess-pbb-evpn-isid-cmacflush-09"
ipr="trust200902" submissionType="IETF">
<!-- Generated by id2xml 1.5.0 on 2020-10-30T09:55:35Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="o*+-"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" std" consensus="true" docName="draft-ietf-bess-pbb-evpn-isid-cmacflush-09" numbe r="9541" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">
<?rfc toc="yes"?> <!-- xml2rfc v2v3 conversion 3.18.2 -->
<!-- Generated by id2xml 1.5.0 on 2020-10-30T09:55:35Z -->
<front> <front>
<title abbrev="PBB-EVPN ISID-based CMAC-flush">PBB-EVPN ISID-based
C-MAC-Flush</title>
<author fullname="Jorge Rabadan" initials="J." role="editor" <title abbrev="PBB-EVPN I-SID-Based C-MAC Flush">Flush Mechanism for Custome
surname="Rabadan"> r MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbon
e Bridging EVPN (PBB-EVPN)</title>
<seriesInfo name="RFC" value="9541"/>
<author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabada
n">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>520 Almanor Avenue</street> <street>520 Almanor Avenue</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94085</code> <code>94085</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Senthil Sathappan" initials="S." surname="Sathappan"> <author fullname="Senthil Sathappan" initials="S." surname="Sathappan">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>520 Almanor Avenue</street> <street>520 Almanor Avenue</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94085</code> <code>94085</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>senthil.sathappan@nokia.com</email> <email>senthil.sathappan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj"> <author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>520 Almanor Avenue</street> <street>520 Almanor Avenue</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94085</code> <code>94085</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>kiran.nagaraj@nokia.com</email> <email>kiran.nagaraj@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="M. Miyake" initials="M." surname="Miyake"> <author fullname="M. Miyake" initials="M." surname="Miyake">
<organization>Softbank</organization> <organization>Softbank</organization>
<address> <address>
<email>masahiro.miyake@g.softbank.co.jp</email> <email>masahiro.miyake@g.softbank.co.jp</email>
</address> </address>
</author> </author>
<author fullname="T. Matsuda" initials="T." surname="Matsuda"> <author fullname="T. Matsuda" initials="T." surname="Matsuda">
<organization>Softbank</organization> <organization>Softbank</organization>
<address> <address>
<email>taku.matsuda@g.softbank.co.jp</email> <email>taku.matsuda@g.softbank.co.jp</email>
</address> </address>
</author> </author>
<date month="February" year="2024"/>
<date day="23" month="October" year="2023"/> <area>rtg</area>
<workgroup>bess</workgroup>
<workgroup>BESS Workgroup</workgroup>
<abstract> <abstract>
<t>Provider Backbone Bridging (PBB) can be combined with Ethernet <t>Provider Backbone Bridging (PBB) can be combined with Ethernet Virtual
Virtual Private Networks (EVPN) to deploy Ethernet Local Area Network Private Networks (EVPNs) to deploy
(ELAN) services in large Multi-Protocol Label Switching (MPLS) networks. Ethernet Local Area Network (E-LAN) services in large Multiprotocol Label
That combination is what we refer to as PBB-EVPN. Single-Active Switching (MPLS) networks. That combination
Multi-homing and per-I-SID (per Service Instance Identifier) is what we refer to as "PBB-EVPN." Single-Active multihoming and per
Load-Balancing can be provided to access devices and aggregation Service Instance Identifier (I-SID) load-balancing can be provided to
networks. In order to speed up the network convergence in case of access devices and aggregation networks. In order to speed up the
failures on Single-Active Multi-Homed Ethernet Segments (ES), PBB-EVPN network convergence in case of failures on Single-Active multihomed
defines a flush mechanism for Customer MACs (C-MAC-flush) that works for Ethernet Segments (ESs), PBB-EVPN defines a flush mechanism for Customer
different Ethernet Segment Backbone MAC (B-MAC) address allocation MACs (C-MACs) called "C-MAC flush" that works for different Ethernet Segme
models. This document complements those C-MAC-flush procedures for cases nt
in which no PBB-EVPN Ethernet Segments are defined (the attachment Backbone MAC (B-MAC) address allocation models. This document
circuit is associated to a zero Ethernet Segment Identifier) and a complements those C-MAC flush procedures for cases in which no PBB-EVPN
Service Instance Identifier based (I-SID-based) C-MAC-flush granularity ESs are defined (i.e., the attachment circuit is associated with a zero Et
is required.</t> hernet
Segment Identifier (ESI)) and the C-MAC flush requires I-SID-level granula
rity.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" title="Introduction"> <section anchor="sect-1" numbered="true" toc="default">
<t><xref target="RFC7623"/> defines how Provider Backbone Bridging (PBB) <name>Introduction</name>
can be combined with Ethernet Virtual Private Networks (EVPN) to deploy <t><xref target="RFC7623" format="default"/> defines how Provider Backbone
ELAN services in very large MPLS networks. <xref target="RFC7623"/> also Bridging (PBB)
describes how Single-Active Multi-homing and per-I-SID Load-Balancing can be combined with Ethernet Virtual Private Networks (EVPNs) to deploy
E-LAN services in very large MPLS networks. <xref target="RFC7623" format=
"default"/> also
describes how Single-Active multihoming and per-I-SID load-balancing
can be provided to access devices and aggregation networks. When Access can be provided to access devices and aggregation networks. When Access
Ethernet/MPLS Networks exists, <xref Ethernet and/or MPLS networks exist, <xref target="I-D.ietf-bess-evpn-virt
target="I-D.ietf-bess-evpn-virtual-eth-segment"/> describes how virtual ual-eth-segment" format="default"/> describes how virtual
Ethernet Segments (ES) can be associated to a group of Ethernet Virtual Ethernet Segments (ESs) can be associated with a group of Ethernet Virtual
Circuits (EVCs) or even Pseudowires (PWs). In order to speed up the Circuits (EVCs) or even pseudowires (PWs). In order to speed up the
network convergence in case of failures on Single-Active Multi-Homed network convergence in case of failures on Single-Active multihomed
Ethernet Segments, <xref target="RFC7623"/> defines a Customer MAC flush ESs, <xref target="RFC7623" format="default"/> defines a Customer MAC flus
mechanism that works for different Ethernet Segment B-MAC address h
mechanism that works for different ES B-MAC address
allocation models.</t> allocation models.</t>
<t>In some cases, the administrative entities that manage the access <t>In some cases, the administrative entities that manage the access
devices or aggregation networks do not demand Multi-Homing Ethernet devices or aggregation networks do not demand multihomed ESs from the PBB-
Segments (ES) from the PBB-EVPN provider, but simply multiple EVPN provider, but simply demand multiple
single-homed ES. Single-homed ES use null ESIs, whereas multi-homed ES single-homed ESs. Single-homed ESs use null ESIs, whereas multihomed ESs
use non-null ESIs. If case of using single-homed ES, the PBB-EVPN use non-null ESIs. If using single-homed ESs, the PBB-EVPN
network is no longer aware of the redundancy offered by the access network is no longer aware of the redundancy offered by the access
administrative entity. <xref administrative entity. <xref target="pbb-evpn-and-non-es-based-redundancy"
target="pbb-evpn-and-non-es-based-redundancy"/> shows an example where format="default"/> shows an example where
the PBB-EVPN network provides four different Attachment Circuits for the PBB-EVPN network provides four different Attachment Circuits (ACs) for
I-SID1, with those Attachment Circuits not being part of any Ethernet I-SID1, with those ACs not being part of any ES or virtual ES. (Therefore,
Segment or virtual Ethernet Segment (therefore they are referred to as they are referred to as
null virtual Ethernet Segment).</t> null virtual Ethernet Segments.)</t>
<figure anchor="pbb-evpn-and-non-es-based-redundancy">
<figure anchor="pbb-evpn-and-non-es-based-redundancy" <name>PBB-EVPN and Non-ES-Based Redundancy</name>
title="PBB-EVPN and non-ES based redundancy"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ <----G.8032----><--PBB-EVPN Network-----><----MPLS---->
<----G.8032--><--PBB-EVPN Network---><----MPLS----> Access MPLS Access
Access MPLS Access Ring Network
Ring Network I-SID1 ESI +------+ +------+
I-SID1 ESI +------+ +------+ +----+ null| PE1 |---------| PE3 |
+----+ null| PE1 |---------| PE3 | |CE1 |----------|B-MAC1| |B-MAC3| ESI null
|CE1 |--------|B-MAC1| |B-MAC3| ESI null +----+ active| | | |----+ PW
+----+ active| | | |----+ PW | +------+ +------+ \active
| +------+ +------+ \active | | | \ +----+
| | | \ +----+ | | | ==|CE3 |I-SID1
| | | ==|CE3 |I-SID1 | | | / +----+
| | | / +----+ |standby ESI +------+ +------+ / PW
|stb ESI +------+ +------+ / PW +----+ null| PE2 | | PE4 |----+ standby
+----+ null| PE2 | | PE4 |----+ standby |CE2 |----------|B-MAC2| |B-MAC4| ESI null
|CE2 |--------|B-MAC2| |B-MAC4| ESI null +----+ active| |---------| |
+----+ active| |---------| | I-SID1 +------+ +------+
I-SID1 +------+ +------+ ]]></artwork>
]]></artwork>
</figure> </figure>
<t>In the example in <xref target="pbb-evpn-and-non-es-based-redundancy"
<t>In the example in <xref format="default"/>, CE1, CE2, and CE3 are attached to the same service,
target="pbb-evpn-and-non-es-based-redundancy"/>, CE1, CE2 and CE3 are identified by I-SID1, in the PBB-EVPN PEs. CE1 and CE2 are connected to
attached to the same service, identified by I-SID1, in the PBB-EVPN PEs. the PEs via "Ethernet ring protection switching" as specified in <xref tar
CE1 and CE2 are connected to the PEs via G.8032 Ethernet Ring Protection get="G.8032"/>, and their
Switching, and their Attachment Circuits to PE1 and PE2 are represented ACs to PE1 and PE2 are represented by a port and VLAN
by a port and VLAN identifier. CE3 is dual-homed to PE3 and PE4 through identifier. CE3 is dual-homed to PE3 and PE4 through an active/standby
an active-standby PW, and its Attachment Circuit to the PEs is PW, and its AC to the PEs is represented by
represented by a PW. Each of the four PEs uses a dedicated Backbone MAC a PW. Each of the four PEs uses a dedicated Backbone MAC address as a
address as source MAC address (B-MAC1, B-MAC2, B-MAC3 and B-MAC4, source MAC address (B-MAC1, B-MAC2, B-MAC3, and B-MAC4, respectively)
respectively) when encapsulating customer frames in PBB packets and when encapsulating customer frames in PBB packets and forwarding those
forwarding those PBB packets to the remote PEs as per <xref PBB packets to the remote PEs as per <xref target="RFC7623"
target="RFC7623"/>. There are no multi-homed Ethernet Segments defined format="default"/>. There are no multihomed ESs defined in
in the PBB-EVPN network of the example, that is why the four Attachment the PBB-EVPN network of the example; that is why the four ACs in <xref tar
Circuits in <xref target="pbb-evpn-and-non-es-based-redundancy"/> show get="pbb-evpn-and-non-es-based-redundancy"
the text "ESI null", which means the Ethernet Segment Identifier on format="default"/> show the text "ESI null", which means the Ethernet
those Attachment Circuits is zero. Since there are no multi-homed ES Segment Identifier on those ACs is zero. Since there are
defined, the PEs keep their Attachment Circuits active as long as the no multihomed ESs defined, the PEs keep their ACs active
physical connectivity is established and the CEs are responsible for as long as the physical connectivity is established and the CEs are
managing the redundancy, avoiding loops and providing per-I-SID load responsible for managing the redundancy, avoiding loops, and providing
balancing to the PBB-EVPN network. Examples of CEs managing their own per-I-SID load-balancing to the PBB-EVPN network. Examples of CEs
redundancy are described in <xref target="G.8032"/>, or <xref managing their own redundancy are described in <xref target="G.8032"
target="RFC4762"/> for active/standby Pseudowires.</t> format="default"/>, or <xref target="RFC4762" format="default"/> for
active/standby PWs.</t>
<t>For instance, in normal conditions, CE2 will block its link to CE1 <t>For instance, in normal conditions, CE2 will block its link to CE1
and CE3 will block its forwarding path to PE4. In this situation, a and CE3 will block its forwarding path to PE4. In this situation, a
failure in one of the redundant Attachment Circuits will trigger the CEs failure in one of the redundant ACs will trigger the CEs
to start using their redundant paths, however those failures will not to start using their redundant paths; however, those failures will not
trigger any Customer MAC flush procedures in the PEs that implement trigger any C-MAC flush procedures in the PEs that implement
<xref target="RFC7623"/>, since the PEs are not using the PBB-EVPN <xref target="RFC7623" format="default"/>, since the PEs are not using the
multi-homing procedures. For example:<list style="symbols"> PBB-EVPN
<t>if the active PW from CE3 (to PE3) fails and the failure is due multihoming procedures. For example:</t>
<ul spacing="normal">
<li>
<t>If the active PW from CE3 (to PE3) fails and the failure is due
to the entire PE3 node failing, then the procedures in <xref to the entire PE3 node failing, then the procedures in <xref
target="RFC7623"/> guarantee that all the remote PEs flush all the target="RFC7623" format="default"/> guarantee that all the remote
Customer MACs associated with B-MAC3 (the B-MAC of PE3). In this PEs flush all the C-MACs associated with B-MAC3 (the B-MAC of
case, CE3 detects the fault due to the PW going operationally PE3). In this case, CE3 detects the fault due to the PW going
down.</t> operationally down.</t>
</li>
<t>however, if the active PW from CE3 (to PE3) fails (but PE3 is <li>
<t>However, if the active PW from CE3 (to PE3) fails (but PE3 is
still operationally up), following the procedures in <xref still operationally up), following the procedures in <xref
target="RFC7623"/>, neither PE3 nor PE4 issue a Customer MAC flush target="RFC7623" format="default"/>, neither PE3 nor PE4 issue a
message and therefore the remote PEs will continue pointing at PE3's C-MAC flush message. Therefore, the remote PEs will continue
Backbone MAC to reach CE3's Customer MACs, until the Customer MACs pointing at PE3's B-MAC to reach CE3's C-MACs, until the C-MACs age
age out in the I-SID1 forwarding tables. In this case, PE3 may use out in the I-SID1 forwarding tables. In this case, PE3 may use any
any of the existing PW notifications so that CE3 switches the active of the existing PW notifications so that CE3 switches the active PW
PW to PE4.</t> to PE4.</t>
</li>
<t>the same issue is exposed when the active PW from CE3 switches <li>
<t>The same issue is exposed when the active PW from CE3 switches
over from PE3 to PE4 due to a manual operation on CE3; that is, over from PE3 to PE4 due to a manual operation on CE3; that is,
neither PE3 nor PE4 trigger any Customer MAC flush notification and neither PE3 nor PE4 trigger any C-MAC flush notification and the
the remote PEs continue sending the traffic to PE3 until the remote PEs continue sending the traffic to PE3 until the C-MACs age
Customer MACs age out.</t> out.</t>
</list></t> </li>
</ul>
<t><xref target="RFC7623"/> provides a Customer MAC flush solution based <t><xref target="RFC7623" format="default"/> provides a C-MAC flush soluti
on a shared Backbone MAC update along with the MAC Mobility extended on based
on a shared B-MAC update along with the MAC Mobility extended
community where the sequence number is incremented. However, the community where the sequence number is incremented. However, the
procedure is only used along with multi-homed Ethernet Segments. Even if procedure is only used along with multihomed ESs. Even if
that procedure could be used for null Ethernet Segments, as in the that procedure could be used for null ESs, as in the
example of <xref target="pbb-evpn-and-non-es-based-redundancy"/>, the example of <xref target="pbb-evpn-and-non-es-based-redundancy" format="def
<xref target="RFC7623"/> Customer MAC flush procedure would result in ault"/>, the Customer MAC flush procedure in <xref target="RFC7623" format="defa
ult"/> would result in
unnecessary flushing of unaffected I-SIDs on the remote PEs, and unnecessary flushing of unaffected I-SIDs on the remote PEs, and
subsequent flooding of unknown unicast traffic in the network. For subsequent flooding of unknown unicast traffic in the network. For
instance, in case CE3 switches its active PW over to PE4, a potential instance, in the case that CE3 switches its active PW over to PE4, a poten
solution reusing the existing C-MAC Flush notifications in <xref tial
target="RFC7623"/> could be for PE3 to issue an update for the MAC/IP solution reusing the existing C-MAC flush notifications in <xref target="R
FC7623" format="default"/> is for PE3 to issue an update for the MAC/IP
Advertisement route of B-MAC3 with a higher sequence number. However, Advertisement route of B-MAC3 with a higher sequence number. However,
this update would have caused unnecessary Customer MAC flushing for all this update would cause unnecessary Customer MAC flushing for all
the I-SIDs attached to PE3 (supposing multiple I-SIDs in PE3), and not the I-SIDs attached to PE3 (supposing multiple I-SIDs in PE3) rather than
only I-SID1.</t> for only I-SID1.</t>
<t>This document describes an extension of the
<t>This document describes an extension of the <xref target="RFC7623"/> Customer MAC flush procedures in <xref target="RFC7623" format="default"/>
Customer MAC flush procedures, so that in the above failure example, PE3 , so that in the failure example above, PE3
can trigger a Customer MAC flush notification that makes PE1, PE2 and can trigger a Customer MAC flush notification that makes PE1, PE2, and
PE4 flush all the Customer MACs associated to PE3's B-MAC3 and (only) PE4 flush all the Customer MACs associated with PE3's B-MAC3 and (only)
I-SID1. In order to do so, this specification introduces the encoding of I-SID1. In order to do so, this specification introduces the encoding of
the I-SID in the MAC/IP Advertisement routes advertised for the B-MACs. the I-SID in the MAC/IP Advertisement routes advertised for the B-MACs.
The Customer MAC flush procedure explained in this document is referred The C-MAC flush procedure explained in this document is referred
to as "PBB-EVPN I-SID-based C-MAC-flush" and can be used in PBB-EVPN to as "PBB-EVPN I-SID-based C-MAC flush" and can be used in PBB-EVPN
networks with null or non-null (virtual) Ethernet Segments.</t> networks with null or non-null (virtual) ESs.</t>
<t>This specification assumes that the reader is familiar with the <t>This specification assumes that the reader is familiar with the
procedures in <xref target="RFC7623"/>. </t> procedures in <xref target="RFC7623" format="default"/>. </t>
<section anchor="sect-1.1" title="Terminology and Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<t>AC: Attachment Circuit.</t>
<t>B-MAC: Backbone MAC address.</t>
<t>B-MAC/0 route: an EVPN MAC/IP Advertisement route that uses a B-MAC
in the MAC address field and a zero Ethernet Tag ID.</t>
<t>B-MAC/I-SID route: an EVPN MAC/IP Advertisement route that uses a
B-MAC in the MAC address field and an I-SID in the Ethernet Tag field,
and it is used to notify remote PEs about the required C-MAC-flush
procedure for the C-MACs associated with the advertised B-MAC and
I-SID.</t>
<t>CE: Customer Edge router.</t>
<t>C-MAC: Customer MAC address.</t>
<t>ES, and ESI: Ethernet Segment and Ethernet Segment Identifier.</t>
<t>EVI: EVPN Instance.</t>
<t>EVPN: Ethernet Virtual Private Networks, as in <xref
target="RFC7432"/>.</t>
<t>G.8032: Ethernet Ring Protection <xref target="G.8032"/>.</t>
<t>I-SID: Service Instance Identifier.</t>
<t>MAC-VRF: A Virtual Routing and Forwarding table for MAC <section anchor="sect-abbrev" numbered="true" toc="default">
addresses.</t> <name>Abbreviations</name>
<dl>
<dt>AC:</dt><dd>Attachment Circuit</dd>
<dt>B-MAC:</dt><dd>Backbone MAC</dd>
<dt>CE:</dt><dd>Customer Edge</dd>
<dt>C-MAC:</dt><dd>Customer MAC</dd>
<dt>ES:</dt><dd>Ethernet Segment</dd>
<dt>ESI:</dt><dd>Ethernet Segment Identifier</dd>
<dt>EVI:</dt><dd>EVPN Instance</dd>
<dt>EVPN:</dt><dd>Ethernet Virtual Private Network (as in <xref target="
RFC7432" format="default"/>)</dd>
<dt>I-SID:</dt><dd>Service Instance Identifier</dd>
<dt>MAC:</dt><dd>Media Access Control</dd>
<dt>MAC-VRF:</dt><dd>MAC Virtual Routing and Forwarding</dd>
<dt>PBB-EVPN:</dt><dd>Provider Backbone Bridging and EVPN (as in <xref t
arget="RFC7623" format="default"/>)</dd>
<dt>PE:</dt><dd>Provider Edge</dd>
</dl>
</section>
<section anchor="sect-term">
<name>Terminology and Conventions</name>
<t>Familiarity with the terminology in <xref target="RFC7623"/> is expect
ed.</t>
<t>PBB-EVPN: Provider-Backbone-Bridging and EVPN, as in <xref <dl>
target="RFC7623"/>.</t> <dt>B-MAC/0 route:</dt><dd>This is an EVPN MAC/IP Advertisement route
that uses a B-MAC
in the MAC address field and a zero Ethernet Tag ID.</dd>
<t>PE: Provider Edge router.</t> <dt>B-MAC/I-SID route:</dt><dd>This is an EVPN MAC/IP Advertisement ro
ute that uses a
B-MAC in the MAC address field and an I-SID in the Ethernet Tag field.
It is used to notify remote PEs about the required C-MAC flush
procedure for the C-MACs associated with the advertised B-MAC and
I-SID.</dd>
<t>Familiarity with the terminology in <xref target="RFC7623"/> is <dt>G.8032:</dt><dd>Refers to Ethernet ring protection switching as desc
expected.</t> ribed in <xref target="G.8032" format="default"/>.</dd>
</dl>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
<section anchor="sect-2" title="Solution requirements"> <name>Solution Requirements</name>
<t>The following requirements are followed by the C-MAC-flush solution <t>The following requirements are followed by the C-MAC flush solution
described in this document:</t> described in this document:</t>
<ol spacing="normal" type="a"><li>
<t><list style="letters"> <t>The solution <bcp14>MUST</bcp14> prevent packet-loss scenarios in c
<t>The solution MUST prevent black-hole scenarios in case of ase of
failures on null ES ACs (Attachment Circuits not associated to ES, failures on null ES ACs (Attachment Circuits not associated with an ES
;
that is, their corresponding ESI is zero) when the access that is, their corresponding ESI is zero) when the access
device/network is responsible for the redundancy.</t> device or access network is responsible for the redundancy.</t>
</li>
<t>This extension described in this document MUST work with <li>
Single-Active non-null ES and virtual ES, irrespective of the PE <t>This extension described in this document <bcp14>MUST</bcp14> work
with
Single-Active non-null ESs and virtual ESs, irrespective of the PE
B-MAC address assignment (dedicated per-ES B-MAC or shared B-MAC, as B-MAC address assignment (dedicated per-ES B-MAC or shared B-MAC, as
in <xref target="RFC7623"/>).</t> in <xref target="RFC7623" format="default"/>).</t>
</li>
<t>In case of failure on the egress PE, the solution MUST provide a <li>
C-MAC-flush notification at B-MAC and I-SID granularity level.</t> <t>In case of failure on the egress PE, the solution <bcp14>MUST</bcp1
4> provide a
<t>The solution MUST provide a reliable C-MAC-flush notification in C-MAC flush notification at the B-MAC and I-SID granularity level.</t>
PBB-EVPN networks that use Route-Reflectors (RRs). MAC flushing </li>
<li>
<t>The solution <bcp14>MUST</bcp14> provide a reliable C-MAC flush not
ification in
PBB-EVPN networks that use Route Reflectors (RRs). MAC flushing
needs to be provided to all affected I-SIDs in spite of the BGP needs to be provided to all affected I-SIDs in spite of the BGP
flush notification messages being aggregated at the RR.</t> flush notification messages being aggregated at the RR.</t>
</li>
<t>The solution MUST coexist in <xref target="RFC7623"/> networks <li>
<t>The solution <bcp14>MUST</bcp14> coexist in <xref target="RFC7623"
format="default"/> networks
where there are PEs that do not support this specification.</t> where there are PEs that do not support this specification.</t>
</li>
<t>The solution SHOULD be enabled/disabled by an administrative <li>
option on a per-PE and per-I-SID basis (as opposed to be always <t>The solution <bcp14>SHOULD</bcp14> be enabled or disabled by an adm
inistrative
option on a per-PE and per-I-SID basis (as opposed to always being
enabled for all the I-SIDs).</t> enabled for all the I-SIDs).</t>
</list></t> </li>
</ol>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default">
<section anchor="sect-3" <name>EVPN BGP Encoding for I-SID-Based C-MAC Flush</name>
title="EVPN BGP Encoding for ISID-based C-MAC-flush">
<t>The solution does not use any new BGP attributes but reuses the MAC <t>The solution does not use any new BGP attributes but reuses the MAC
Mobility extended community as an indication of C-MAC-flush (as in <xref Mobility extended community as an indication of C-MAC flush (as in <xref
target="RFC7623"/>) and encodes the I-SID in the Ethernet Tag field of target="RFC7623" format="default"/>) and encodes the I-SID in the
the EVPN MAC/IP advertisement route. As a reference, <xref Ethernet Tag field of the EVPN MAC/IP advertisement route. As a
target="ure-cmac-flush-notification-encoding-bmac-isid-route"/> shows reference, <xref
the MAC Mobility extended community and the EVPN MAC/IP advertisement target="ure-cmac-flush-notification-encoding-bmac-isid-route"
route that are used specified in <xref target="RFC7432"/> and used in format="default"/> shows the MAC Mobility extended community and the
this document as a C-MAC-flush notification message.</t> EVPN MAC/IP advertisement route that are used as specified in <xref
target="RFC7432" format="default"/> and used in this document as a
<figure anchor="ure-cmac-flush-notification-encoding-bmac-isid-route" C-MAC flush notification message.</t>
title="CMAC-Flush notification encoding: BMAC/ISID route"> <figure anchor="ure-cmac-flush-notification-encoding-bmac-isid-route">
<artwork><![CDATA[ <name>C-MAC Flush Notification Encoding: B-MAC/I-SID Route</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x03 | Flags | Reserved=0 | | Type=0x06 | Sub-Type=0x03 | Flags | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------+ +---------------------------------------+
| Route Distinguisher | | Route Distinguisher |
+---------------------------------------+ +---------------------------------------+
skipping to change at line 384 skipping to change at line 336
| MAC Address Length = 48 | | MAC Address Length = 48 |
+---------------------------------------+ +---------------------------------------+
| B-MAC Address | | B-MAC Address |
+---------------------------------------+ +---------------------------------------+
| IP Address Length = 0 | | IP Address Length = 0 |
+---------------------------------------+ +---------------------------------------+
| MPLS Label1 | | MPLS Label1 |
+---------------------------------------+ +---------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:</t> <t>Where:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>The route's route distinguisher and route targets are the ones <t>The route's route distinguisher and route targets are the ones
corresponding to its EVI. Alternatively to the EVI's RT, the route corresponding to its EVI. Alternatively to the EVI's Route Target (RT)
MAY be tagged with an RT auto-derived from the Ethernet Tag (I-SID) , the route
instead. <xref target="RFC7623"/> describes how the EVPN MAC/IP <bcp14>MAY</bcp14> be tagged with an RT auto-derived from the Ethernet
Tag (I-SID)
instead. <xref target="RFC7623" format="default"/> describes how the E
VPN MAC/IP
Advertisement routes can be advertised along with the EVI RT or an Advertisement routes can be advertised along with the EVI RT or an
RT that is derived from the I-SID.</t> RT that is derived from the I-SID.</t>
</li>
<t>The Ethernet Tag encodes the I-SID for which the PE that receives <li>
the route must flush the C-MACs upon reception of the route.</t> <t>The Ethernet Tag encodes the I-SID. This indicates to the PE that i
t must flush the C-MACs for that encoded I-SID, upon reception of the route.</t>
<t>The MAC address field encodes the B-MAC Address for which the PE </li>
that receives the route must flush the C-MACs upon reception of the <li>
route.</t> <t>The MAC address field encodes the B-MAC address. This indicates to
the PE that it must flush the C-MACs associated with that encoded B-MAC, upon re
<t>The MAC Mobility extended community is used as in <xref ception of the route.</t>
target="RFC7623"/>, where an increment in the sequence number </li>
<li>
<t>The MAC Mobility extended community is used as in <xref target="RFC
7623" format="default"/>, where an increment in the sequence number
between two updates for the same B-MAC/I-SID will be interpreted as between two updates for the same B-MAC/I-SID will be interpreted as
a C-MAC-flush notification for the corresponding B-MAC and a C-MAC flush notification for the corresponding B-MAC and
I-SID.</t> I-SID.</t>
</list></t> </li>
</ul>
<t>All the other fields are set and used as defined in <xref <t>All the other fields are set and used as defined in <xref
target="RFC7623"/>. This document will refer to this route as the target="RFC7623" format="default"/>. This document will refer to this
B-MAC/I-SID route, as opposed to the EVPN MAC/IP Advertisement route route as the "B-MAC/I-SID route", as opposed to the EVPN MAC/IP
used in <xref target="RFC7623"/> that contains a specific B-MAC, and the Advertisement route used in <xref target="RFC7623" format="default"/>
Ethernet Tag ID set to zero. This document uses the term B-MAC/0 route that contains a specific B-MAC and the Ethernet Tag ID set to
to represent a B-MAC route advertised with Ethernet Tag ID = 0.</t> zero. This document uses the term "B-MAC/0 route" to represent a B-MAC
route advertised with an Ethernet Tag ID = 0.</t>
<t>Note that this B-MAC/I-SID route will be accepted and reflected by <t>Note that this B-MAC/I-SID route will be accepted and reflected by
any <xref target="RFC7432"/> RR, since no new attributes or values are any RR as specified in <xref target="RFC7432" format="default"/>, since no new attributes or values are
used. A PE receiving the route will process the received B-MAC/I-SID used. A PE receiving the route will process the received B-MAC/I-SID
update only in case of supporting the procedures described in this update only in the case of supporting the procedures described in this
document.</t> document.</t>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
<section anchor="sect-4" title="Solution description"> <name>Solution Description</name>
<t><xref target="pbb-evpn-and-non-es-based-redundancy"/> will be used in <t><xref target="pbb-evpn-and-non-es-based-redundancy" format="default"/>
the description of the solution. CE1, CE2 and CE3 are connected to ACs will be used in
associated to I-SID1, where no (Multi-Homed) Ethernet Segments have been the description of the solution. CE1, CE2, and CE3 are connected to ACs
enabled, and the ACs and PWs are in active or standby state as per <xref associated with I-SID1, where no (multihomed) ESs have been
target="pbb-evpn-and-non-es-based-redundancy"/>.</t> enabled, and the ACs and PWs are in active or standby state as per <xref t
arget="pbb-evpn-and-non-es-based-redundancy" format="default"/>.</t>
<t>Enabling or disabling I-SID-based C-MAC-flush SHOULD be an <t>Enabling or disabling I-SID-based C-MAC flush <bcp14>SHOULD</bcp14> be
administrative choice on the system that MAY be configured per I-SID an
administrative choice on the system that <bcp14>MAY</bcp14> be configured
per I-SID
(I-Component, Service Instance Component), as opposed to being (I-Component, Service Instance Component), as opposed to being
configured for all I-SIDs. When enabled on a PE:</t> configured for all I-SIDs. When enabled on a PE:</t>
<ol spacing="normal" type="a"><li>
<t><list style="letters"> <t>The PE will be able to generate B-MAC/I-SID routes as C-MAC Flush
<t>The PE will be able to generate B-MAC/I-SID routes as C-MAC-Flush
notifications for the remote PEs.</t> notifications for the remote PEs.</t>
</li>
<li>
<t>The PE will be able to process B-MAC/I-SID routes received from <t>The PE will be able to process B-MAC/I-SID routes received from
remote PEs.</t> remote PEs.</t>
</list></t> </li>
</ol>
<t>The PE MUST follow the <xref target="RFC7623"/> procedures for <t>The PE <bcp14>MUST</bcp14> follow the procedures in <xref target="RFC76
C-MAC-flush. This specification brings some additional procedures when 23" format="default"/> for
I-SID-based C-MAC-flush is enabled.</t> C-MAC flush. This specification provides some additional procedures when
I-SID-based C-MAC flush is enabled.</t>
<t>This C-MAC-flush specification is described in three sets of <t>This C-MAC flush specification is described in three sets of
procedures:</t> procedures:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>I-SID-based C-MAC-flush activation</t> <t>I-SID-based C-MAC flush activation</t>
</li>
<t>C-MAC-flush notification generation upon AC failures</t> <li>
<t>C-MAC flush notification generation upon AC failures</t>
<t>C-MAC-flush process upon receiving a C-MAC-flush notification</t> </li>
</list></t> <li>
<t>C-MAC flush process upon receiving a C-MAC flush notification</t>
<section anchor="sect-4.1" </li>
title="ISID-based C-MAC-Flush activation procedures"> </ul>
<t>The following behavior MUST be followed by the PBB-EVPN PEs <section anchor="sect-4.1" numbered="true" toc="default">
following this specification. <xref <name>I-SID-Based C-MAC Flush Activation Procedures</name>
target="pbb-evpn-and-non-es-based-redundancy"/> is used as a <t>The following behavior <bcp14>MUST</bcp14> be followed by the PBB-EVP
N PEs
following this specification. <xref target="pbb-evpn-and-non-es-based-re
dundancy" format="default"/> is used as a
reference.</t> reference.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>As in <xref target="RFC7623"/>, each PE advertises a shared <t>As in <xref target="RFC7623" format="default"/>, each PE advertis
B-MAC in a B-MAC/0 route (with B-MAC1, B-MAC2, B-MAC3 and B-MAC4 es a shared
B-MAC in a B-MAC/0 route (with B-MAC1, B-MAC2, B-MAC3, and B-MAC4
in the MAC address field, respectively). This is the B-MAC that in the MAC address field, respectively). This is the B-MAC that
each PE will use as B-MAC SA (Source Address) when encapsulating each PE will use as B-MAC SA (Source Address) when encapsulating
the frames received on any local single-homed AC. Each PE will the frames received on any local single-homed AC. Each PE will
import the received B-MAC/0 routes from the remote PEs and will import the received B-MAC/0 routes from the remote PEs and will
install the B-MACs in its B-component (Backbone Component) install the B-MACs in its B-component (Backbone Component)
MAC-VRF. For instance, PE1 will advertise B-MAC1/0 and will MAC-VRF. For instance, PE1 will advertise B-MAC1/0 and will
install B-MAC2, B-MAC3 and B-MAC4 in its MAC-VRF.</t> install B-MAC2, B-MAC3, and B-MAC4 in its MAC-VRF.</t>
</li>
<t>Assuming I-SID-based C-MAC-flush is activated for I-SID 1, the <li>
PEs will advertise the shared B-MAC with I-SID 1 encoded in the <t>Assuming I-SID-based C-MAC flush is activated for I-SID1, the
PEs will advertise the shared B-MAC with I-SID1 encoded in the
Ethernet Tag. That is, PE1 will advertise B-MAC1/1 and will Ethernet Tag. That is, PE1 will advertise B-MAC1/1 and will
receive B-MAC2/1, B-MAC3/1 and B-MAC4/1. The receiving PEs MUST receive B-MAC2/1, B-MAC3/1, and B-MAC4/1. The receiving PEs
use these B-MAC/I-SID routes only for C-MAC-flush procedures and <bcp14>MUST</bcp14> use these B-MAC/I-SID routes only for
they MUST NOT be used them to add/withdraw any B-MAC entry in the C-MAC flush procedures and they <bcp14>MUST NOT</bcp14> be used to
MAC-VRFs. As per <xref target="RFC7623"/>, only B-MAC/0 routes can add/withdraw any B-MAC entry in the MAC-VRFs. As per <xref
be used to add/withdraw B-MACs in the MAC-VRFs.</t> target="RFC7623" format="default"/>, only B-MAC/0 routes can be
used to add/withdraw B-MACs in the MAC-VRFs.</t>
<t>The above procedure MAY also be used for dedicated B-MACs </li>
(B-MACs allocated per Ethernet Segment).</t> <li>
</list></t> <t>The above procedure <bcp14>MAY</bcp14> also be used for dedicated
B-MACs
(B-MACs allocated per ES).</t>
</li>
</ul>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
<section anchor="sect-4.2" title="C-MAC-Flush generation"> <name>C-MAC Flush Generation</name>
<t>If, for instance, there is a failure on PE1's AC, PE1 will generate <t>If, for instance, there is a failure on PE1's AC, PE1 will generate
an update including B-MAC1/1 along with the MAC Mobility extended an update including B-MAC1/1 along with the MAC Mobility extended
community where the Sequence Number has been incremented. The community where the Sequence Number has been incremented. The
reception of the B-MAC1/1 with an increment in the sequence number reception of the B-MAC1/1 with an increment in the sequence number
will trigger the C-MAC-flush procedures on the receiving PEs.</t> will trigger the C-MAC flush procedures on the receiving PEs.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>An AC going operationally down MUST generate a B-MAC/I-SID with <t>An AC going operationally down <bcp14>MUST</bcp14> generate a B-M
AC/I-SID with
a higher Sequence Number. If the AC going down makes the entire a higher Sequence Number. If the AC going down makes the entire
local I-SID go operationally down, the PE will withdraw the local I-SID go operationally down, the PE will withdraw the
B-MAC/I-SID route for the I-SID.</t> B-MAC/I-SID route for the I-SID.</t>
</li>
<t>An AC going operationally up SHOULD NOT generate any <li>
<t>An AC going operationally up <bcp14>SHOULD NOT</bcp14> generate a
ny
B-MAC/I-SID update, unless it activates its corresponding I-SID, B-MAC/I-SID update, unless it activates its corresponding I-SID,
in which case the PE will advertise the B-MAC/I-SID route.</t> in which case the PE will advertise the B-MAC/I-SID route.</t>
</li>
<li>
<t>An AC receiving a G.8032 flush notification or a flush message <t>An AC receiving a G.8032 flush notification or a flush message
in any other protocol from the access network MAY propagate it to in any other protocol from the access network <bcp14>MAY</bcp14> pro
the remote PEs by generating a B-MAC/I-SID route update with pagate it to
the remote PEs by generating a B-MAC/I-SID route update with a
higher Sequence Number.</t> higher Sequence Number.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="sect-4.3" numbered="true" toc="default">
<section anchor="sect-4.3" <name>C-MAC Flush Process upon Receiving a C-MAC Flush Notification</nam
title="C-MAC-flush process upon receiving a CMAC-flush notificati e>
on"> <t>A PE receiving a C-MAC flush notification will follow these
<t>A PE receiving a C-MAC-flush notification will follow these
procedures:</t> procedures:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>A received B-MAC/I-SID route (with non-zero I-SID) MUST NOT <t>A received B-MAC/I-SID route (with a non-zero I-SID) <bcp14>MUST
NOT</bcp14>
add/remove any B-MAC to/from the MAC-VRF.</t> add/remove any B-MAC to/from the MAC-VRF.</t>
</li>
<li>
<t>An update of a previously received B-MAC/I-SID route with an <t>An update of a previously received B-MAC/I-SID route with an
increment Sequence Number, MUST flush all the C-MACs associated to increment Sequence Number <bcp14>MUST</bcp14> flush all the C-MACs a
that I-SID and B-MAC. C-MACs associated to the same I-SID but ssociated with
different B-MAC MUST NOT be flushed.</t> that I-SID and B-MAC. C-MACs associated with the same I-SID but
different B-MAC <bcp14>MUST NOT</bcp14> be flushed.</t>
<t>A received B-MAC/I-SID withdraw (with non-zero I-SID) MUST </li>
flush all the C-MACs associated to that B-MAC and I-SID.</t> <li>
</list></t> <t>A received B-MAC/I-SID withdraw (with a non-zero I-SID) <bcp14>MU
ST</bcp14>
<t>Note that the C-MAC-flush procedures described in <xref flush all the C-MACs associated with that B-MAC and I-SID.</t>
target="RFC7623"/> for B-MAC/0 routes are still valid and a PE </li>
receiving <xref target="RFC7623"/> C-MAC-flush notification messages </ul>
MUST observe the behavior specified in <xref target="RFC7623"/>.</t> <t>Note that the C-MAC flush procedures described in <xref target="RFC76
23" format="default"/> for B-MAC/0 routes are still valid and a PE
receiving <xref target="RFC7623" format="default"/> C-MAC flush notifica
tion messages
<bcp14>MUST</bcp14> observe the behavior specified in <xref target="RFC7
623" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
<section anchor="sect-5" title="Conclusions"> <name>Conclusions</name>
<t>The I-SID-based C-MAC-flush solution described in this document has <t>The I-SID-based C-MAC flush solution described in this document has
the following benefits:</t> the following benefits:</t>
<ol spacing="normal" type="a"><li>
<t><list style="letters"> <t>The solution solves packet-loss scenarios in case of failures on
<t>The solution solves black-hole scenarios in case of failures on null ES ACs, since the C-MAC flush procedures are independent of the
null ES ACs, since the C-MAC-flush procedures are independent of the ES definition.</t>
Ethernet Segment definition.</t> </li>
<li>
<t>This extension can also be used with Single-Active non-null ES <t>This extension can also be used with Single-Active non-null ESs
and virtual ES, irrespective of the PE B-MAC address assignment and virtual ESs, irrespective of the PE B-MAC address assignment
(dedicated per-ES B-MAC or shared B-MAC).</t> (dedicated per-ES B-MAC or shared B-MAC).</t>
</li>
<t>It provides a C-MAC-flush notification at B-MAC and I-SID <li>
<t>It provides a C-MAC flush notification at B-MAC and I-SID
granularity level, therefore flushing a minimum number of C-MACs and granularity level, therefore flushing a minimum number of C-MACs and
reducing the amount of unknown unicast flooding in the network.</t> reducing the amount of unknown unicast flooding in the network.</t>
</li>
<t>It provides a reliable C-MAC-flush notification in PBB-EVPN <li>
networks that use RRs. RRs will propagate the C-MAC-flush <t>It provides a reliable C-MAC flush notification in PBB-EVPN
notifications for all the affected I-SIDs and irrespective of the networks that use RRs. RRs will propagate the C-MAC flush
notifications for all the affected I-SIDs, irrespective of the
order in which the notifications make it to the RR.</t> order in which the notifications make it to the RR.</t>
</li>
<li>
<t>The solution can coexist in a network with systems supporting or <t>The solution can coexist in a network with systems supporting or
not supporting this specification. Non-supporting systems ignore the not supporting this specification. Non-supporting systems ignore the
B-MAC/I-SID routes, however they still follow the C-MAC-flush B-MAC/I-SID routes; however, they still follow the C-MAC flush
procedures in <xref target="RFC7623"/>.</t> procedures in <xref target="RFC7623" format="default"/>.</t>
</list></t> </li>
</ol>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default">
<section anchor="sect-7" title="Security Considerations"> <name>Security Considerations</name>
<t>Security considerations described in <xref target="RFC7623"/> apply <t>Security considerations described in <xref target="RFC7623" format="def
ault"/> apply
to this document.</t> to this document.</t>
<t>In addition, this document suggests additional procedures that can
<t>In addition, this document suggests additional procedures, that can be activated on a per I-SID basis and generate additional EVPN MAC/IP
be activated on a per I-SID basis, and generate additional EVPN MAC/IP
Advertisement routes in the network. The format of these additional EVPN Advertisement routes in the network. The format of these additional EVPN
MAC/IP Advertisement routes is backwards compatible with <xref MAC/IP Advertisement routes is backwards compatible with the procedures in
target="RFC7623"/> procedures and should not create any issues on <xref target="RFC7623" format="default"/> and should not create any issues for
receiving PEs not following this specification, however, the additional receiving PEs that do not follow this specification. However, the addition
al
routes may consume extra memory and processing resources on the routes may consume extra memory and processing resources on the
receiving PEs. Because of that, it is RECOMMENDED to activate this receiving PEs. Because of that, it is <bcp14>RECOMMENDED</bcp14> to activa
feature only when necessary (when multi-homed networks or devices are te this
feature only when necessary (when multihomed networks or devices are
attached to the PBB-EVPN PEs), and not by default in any PBB-EVPN attached to the PBB-EVPN PEs), and not by default in any PBB-EVPN
PE.</t> PE.</t>
</section> </section>
<section anchor="sect-8" numbered="true" toc="default">
<section anchor="sect-8" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document requests no actions from IANA.</t> <t>This document has no IANA actions.</t>
</section>
<section anchor="sect-9" title="Acknowledgments">
<t>The authors want to thank Vinod Prabhu, Sriram Venkateswaran, Laxmi
Padakanti, Ranganathan Boovaraghavan for their review and
contributions.</t>
</section> </section>
</middle>
<section anchor="sect-10" title="Contributors"/>
</middle>
<back> <back>
<references title="Normative References">
&RFC7623;
&RFC7432; <displayreference target="I-D.ietf-bess-evpn-virtual-eth-segment" to="EVPN-VIRTU
AL-ES"/>
&RFC2119;
&RFC8174; <references>
</references> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
623.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references>
<references>
<name>Informative References</name>
<references title="Informative References"> <!--[I-D.ietf-bess-evpn-virtual-eth-segment] IESG state Publication Requested --
&I-D.ietf-bess-evpn-virtual-eth-segment; >
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-bess-evpn-virtual-eth-segment.xml"/>
&RFC4762; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 762.xml"/>;
<reference anchor="G.8032"> <reference anchor="G.8032" target="https://www.itu.int/rec/T-REC-G.8032-202003-I
<front> /en">
<title>Recommendation ITU-T G.8032/Y.1344, Ethernet ring protection <front>
switching</title> <title>Ethernet ring protection switching</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="March" year="2020" />
</front>
<seriesInfo name="ITU-T Recommendation" value="G.8032/Y.1344"/>
</reference>
</references>
</references>
<author> <section anchor="sect-9" numbered="false" toc="default">
<organization/> <name>Acknowledgments</name>
</author> <t>The authors want to thank <contact fullname="Vinod Prabhu"/>,
<contact fullname="Sriram Venkateswaran"/>, <contact fullname="Laxmi
Padakanti"/>, and <contact fullname="Ranganathan Boovaraghavan"/> for
their review and contributions.</t>
</section>
<date month="March" year="2020"/>
</front>
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 108 change blocks. 
453 lines changed or deleted 485 lines changed or added

This html diff was produced by rfcdiff 1.48.