<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC7623 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7623.xml"> nbsp    "&#160;">
  <!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"> zwsp   "&#8203;">
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbhy   "&#8209;">
  <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC4762 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.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"> wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-bess-pbb-evpn-isid-cmacflush-09" number="9541" ipr="trust200902" submissionType="IETF"> obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.18.2 -->
  <!-- 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 toc="yes"?>

  <front>

    <title abbrev="PBB-EVPN ISID-based CMAC-flush">PBB-EVPN ISID-based
    C-MAC-Flush</title> I-SID-Based C-MAC Flush">Flush Mechanism for Customer MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN)</title>
    <seriesInfo name="RFC" value="9541"/>
    <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabadan">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>520 Almanor Avenue</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94085</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <author fullname="Senthil Sathappan" initials="S." surname="Sathappan">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>520 Almanor Avenue</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94085</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>senthil.sathappan@nokia.com</email>
      </address>
    </author>
    <author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>520 Almanor Avenue</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94085</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>kiran.nagaraj@nokia.com</email>
      </address>
    </author>
    <author fullname="M. Miyake" initials="M." surname="Miyake">
      <organization>Softbank</organization>
      <address>
        <email>masahiro.miyake@g.softbank.co.jp</email>
      </address>
    </author>
    <author fullname="T. Matsuda" initials="T." surname="Matsuda">
      <organization>Softbank</organization>
      <address>
        <email>taku.matsuda@g.softbank.co.jp</email>
      </address>
    </author>
    <date day="23" month="October" year="2023"/>

    <workgroup>BESS Workgroup</workgroup> month="February" year="2024"/>
    <area>rtg</area>
    <workgroup>bess</workgroup>
    <abstract>
      <t>Provider Backbone Bridging (PBB) can be combined with Ethernet Virtual Private Networks (EVPN) (EVPNs) to deploy
      Ethernet Local Area Network
      (ELAN) (E-LAN) services in large Multi-Protocol Multiprotocol Label Switching (MPLS) networks. That combination
      is what we refer to as PBB-EVPN. "PBB-EVPN." Single-Active
      Multi-homing multihoming and per-I-SID (per per
      Service Instance Identifier)
      Load-Balancing Identifier (I-SID) load-balancing can be provided to
      access devices and aggregation networks. In order to speed up the
      network convergence in case of failures on Single-Active Multi-Homed multihomed
      Ethernet Segments (ES), (ESs), PBB-EVPN defines a flush mechanism for Customer
      MACs (C-MAC-flush) (C-MACs) called "C-MAC flush" that works for different Ethernet Segment
      Backbone MAC (B-MAC) address allocation models. This document
      complements those C-MAC-flush C-MAC flush procedures for cases in which no PBB-EVPN Ethernet Segments
      ESs are defined (the (i.e., the attachment circuit is associated to with a zero Ethernet
      Segment Identifier) and a
      Service Instance Identifier based (I-SID-based) C-MAC-flush granularity
      is required.</t> (ESI)) and the C-MAC flush requires I-SID-level granularity.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC7623"/> target="RFC7623" format="default"/> defines how Provider Backbone Bridging (PBB)
      can be combined with Ethernet Virtual Private Networks (EVPN) (EVPNs) to deploy
      ELAN
      E-LAN services in very large MPLS networks. <xref target="RFC7623"/> target="RFC7623" format="default"/> also
      describes how Single-Active Multi-homing multihoming and per-I-SID Load-Balancing load-balancing
      can be provided to access devices and aggregation networks. When Access
      Ethernet/MPLS Networks exists,
      Ethernet and/or MPLS networks exist, <xref
      target="I-D.ietf-bess-evpn-virtual-eth-segment"/> target="I-D.ietf-bess-evpn-virtual-eth-segment" format="default"/> describes how virtual
      Ethernet Segments (ES) (ESs) can be associated to with a group of Ethernet Virtual
      Circuits (EVCs) or even Pseudowires pseudowires (PWs). In order to speed up the
      network convergence in case of failures on Single-Active Multi-Homed
      Ethernet Segments, multihomed
      ESs, <xref target="RFC7623"/> target="RFC7623" format="default"/> defines a Customer MAC flush
      mechanism that works for different Ethernet Segment ES B-MAC address
      allocation models.</t>
      <t>In some cases, the administrative entities that manage the access
      devices or aggregation networks do not demand Multi-Homing Ethernet
      Segments (ES) multihomed ESs from the PBB-EVPN provider, but simply demand multiple
      single-homed ES. ESs. Single-homed ES ESs use null ESIs, whereas multi-homed ES multihomed ESs
      use non-null ESIs. If case of using single-homed ES, ESs, the PBB-EVPN
      network is no longer aware of the redundancy offered by the access
      administrative entity. <xref
      target="pbb-evpn-and-non-es-based-redundancy"/> target="pbb-evpn-and-non-es-based-redundancy" format="default"/> shows an example where
      the PBB-EVPN network provides four different Attachment Circuits (ACs) for
      I-SID1, with those Attachment Circuits ACs not being part of any Ethernet
      Segment ES or virtual Ethernet Segment (therefore ES. (Therefore, they are referred to as
      null virtual Ethernet Segment).</t> Segments.)</t>
      <figure anchor="pbb-evpn-and-non-es-based-redundancy"
              title="PBB-EVPN anchor="pbb-evpn-and-non-es-based-redundancy">
        <name>PBB-EVPN and non-ES based redundancy">
        <artwork><![CDATA[
     <----G.8032--><--PBB-EVPN Network---><----MPLS----> Non-ES-Based Redundancy</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
<----G.8032----><--PBB-EVPN Network-----><----MPLS---->
     Access          MPLS                Access
      Ring                               Network
I-SID1      ESI +------+         +------+
+----+      null| PE1  |---------| PE3  |
|CE1 |--------|B-MAC1| |----------|B-MAC1|         |B-MAC3| ESI null
+----+    active|      |         |      |----+ PW
  |             +------+         +------+     \active
  |               |                 |          \  +----+
  |               |                 |           ==|CE3 |I-SID1
  |               |                 |          /  +----+
       |stb
  |standby  ESI +------+         +------+     / PW
+----+      null| PE2  |         | PE4  |----+ standby
|CE2 |--------|B-MAC2| |----------|B-MAC2|         |B-MAC4| ESI null
+----+    active|      |---------|      |
I-SID1          +------+         +------+
]]></artwork>
      </figure>
      <t>In the example in <xref
      target="pbb-evpn-and-non-es-based-redundancy"/>, target="pbb-evpn-and-non-es-based-redundancy"
      format="default"/>, CE1, CE2 CE2, and CE3 are attached to the same service,
      identified by I-SID1, in the PBB-EVPN PEs.  CE1 and CE2 are connected to
      the PEs via G.8032 Ethernet Ring Protection
      Switching, "Ethernet ring protection switching" as specified in <xref target="G.8032"/>, and their Attachment Circuits
      ACs to PE1 and PE2 are represented by a port and VLAN
      identifier. CE3 is dual-homed to PE3 and PE4 through an active-standby active/standby
      PW, and its Attachment Circuit AC to the PEs is represented by
      a PW. Each of the four PEs uses a dedicated Backbone MAC address as a
      source MAC address (B-MAC1, B-MAC2, B-MAC3 B-MAC3, and B-MAC4, respectively)
      when encapsulating customer frames in PBB packets and forwarding those
      PBB packets to the remote PEs as per <xref
      target="RFC7623"/>. target="RFC7623"
      format="default"/>. There are no multi-homed Ethernet Segments multihomed ESs defined in
      the PBB-EVPN network of the example, example; that is why the four Attachment
      Circuits ACs in <xref target="pbb-evpn-and-non-es-based-redundancy"/> target="pbb-evpn-and-non-es-based-redundancy"
      format="default"/> show the text "ESI null", which means the Ethernet
      Segment Identifier on those Attachment Circuits ACs is zero. Since there are
      no multi-homed ES multihomed ESs defined, the PEs keep their Attachment Circuits ACs active
      as long as the physical connectivity is established and the CEs are
      responsible for managing the redundancy, avoiding loops loops, and providing
      per-I-SID load
      balancing load-balancing to the PBB-EVPN network. Examples of CEs
      managing their own redundancy are described in <xref target="G.8032"/>, target="G.8032"
      format="default"/>, or <xref
      target="RFC4762"/> target="RFC4762" format="default"/> for
      active/standby Pseudowires.</t> PWs.</t>
      <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
      failure in one of the redundant Attachment Circuits ACs will trigger the CEs
      to start using their redundant paths, however paths; however, those failures will not
      trigger any Customer MAC C-MAC flush procedures in the PEs that implement
      <xref target="RFC7623"/>, target="RFC7623" format="default"/>, since the PEs are not using the PBB-EVPN
      multi-homing
      multihoming procedures. For example:<list style="symbols">
          <t>if 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
          target="RFC7623"/>
          target="RFC7623" format="default"/> guarantee that all the remote
          PEs flush all the
          Customer MACs C-MACs associated with B-MAC3 (the B-MAC of
          PE3). In this case, CE3 detects the fault due to the PW going
          operationally down.</t>

          <t>however,
        </li>
        <li>
          <t>However, if the active PW from CE3 (to PE3) fails (but PE3 is
          still operationally up), following the procedures in <xref
          target="RFC7623"/>,
          target="RFC7623" format="default"/>, neither PE3 nor PE4 issue a Customer MAC
          C-MAC flush
          message and therefore message. Therefore, the remote PEs will continue
          pointing at PE3's
          Backbone MAC B-MAC to reach CE3's Customer MACs, C-MACs, until the Customer MACs C-MACs age
          out in the I-SID1 forwarding tables. In this case, PE3 may use any
          of the existing PW notifications so that CE3 switches the active PW
          to PE4.</t>

          <t>the
        </li>
        <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,
          neither PE3 nor PE4 trigger any Customer MAC C-MAC flush notification and the
          remote PEs continue sending the traffic to PE3 until the
          Customer MACs C-MACs age
          out.</t>
        </list></t>
        </li>
      </ul>
      <t><xref target="RFC7623"/> target="RFC7623" format="default"/> provides a Customer MAC C-MAC flush solution based
      on a shared Backbone MAC B-MAC update along with the MAC Mobility extended
      community where the sequence number is incremented. However, the
      procedure is only used along with multi-homed Ethernet Segments. multihomed ESs. Even if
      that procedure could be used for null Ethernet Segments, ESs, as in the
      example of <xref target="pbb-evpn-and-non-es-based-redundancy"/>, target="pbb-evpn-and-non-es-based-redundancy" format="default"/>, the
      <xref target="RFC7623"/> Customer MAC flush procedure in <xref target="RFC7623" format="default"/> would result in
      unnecessary flushing of unaffected I-SIDs on the remote PEs, and
      subsequent flooding of unknown unicast traffic in the network. For
      instance, in the case that CE3 switches its active PW over to PE4, a potential
      solution reusing the existing C-MAC Flush flush notifications in <xref
      target="RFC7623"/> could be target="RFC7623" format="default"/> is for PE3 to issue an update for the MAC/IP
      Advertisement route of B-MAC3 with a higher sequence number. However,
      this update would have caused cause unnecessary Customer MAC flushing for all
      the I-SIDs attached to PE3 (supposing multiple I-SIDs in PE3), and not PE3) rather than
      for only I-SID1.</t>
      <t>This document describes an extension of the <xref target="RFC7623"/>
      Customer MAC flush procedures, procedures in <xref target="RFC7623" format="default"/>, so that in the above failure example, example above, PE3
      can trigger a Customer MAC flush notification that makes PE1, PE2 PE2, and
      PE4 flush all the Customer MACs associated to with PE3's B-MAC3 and (only)
      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 Customer MAC C-MAC flush procedure explained in this document is referred
      to as "PBB-EVPN I-SID-based C-MAC-flush" C-MAC flush" and can be used in PBB-EVPN
      networks with null or non-null (virtual) Ethernet Segments.</t> ESs.</t>
      <t>This specification assumes that the reader is familiar with the
      procedures in <xref target="RFC7623"/>. target="RFC7623" format="default"/>. </t>

      <section anchor="sect-1.1" title="Terminology anchor="sect-abbrev" numbered="true" toc="default">
	<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 Conventions">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", Forwarding</dd>
        <dt>PBB-EVPN:</dt><dd>Provider Backbone Bridging and
        "OPTIONAL" in this document are to be interpreted as described EVPN (as in BCP
        14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, target="RFC7623" format="default"/>)</dd>
        <dt>PE:</dt><dd>Provider Edge</dd>
      </dl>
      </section>
      <section anchor="sect-term">
        <name>Terminology and only
        when, they appear Conventions</name>
	<t>Familiarity with the terminology in all capitals, as shown here.</t>

        <t>AC: Attachment Circuit.</t>

        <t>B-MAC: Backbone MAC address.</t>

        <t>B-MAC/0 route: <xref target="RFC7623"/> is expected.</t>

	<dl>
          <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.</t>

        <t>B-MAC/I-SID route: ID.</dd>

          <dt>B-MAC/I-SID route:</dt><dd>This is 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 field.
          It is used to notify remote PEs about the required C-MAC-flush 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:
          I-SID.</dd>

        <dt>G.8032:</dt><dd>Refers to Ethernet Virtual Private Networks, ring protection switching as described 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
        addresses.</t>

        <t>PBB-EVPN: Provider-Backbone-Bridging 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 EVPN, "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref
        target="RFC7623"/>.</t>

        <t>PE: Provider Edge router.</t>

        <t>Familiarity with the terminology in target="RFC2119"/> <xref target="RFC7623"/> is
        expected.</t>
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
    </section>
    <section anchor="sect-2" title="Solution requirements"> numbered="true" toc="default">
      <name>Solution Requirements</name>
      <t>The following requirements are followed by the C-MAC-flush C-MAC flush solution
      described in this document:</t>

      <t><list style="letters">
      <ol spacing="normal" type="a"><li>
          <t>The solution MUST <bcp14>MUST</bcp14> prevent black-hole packet-loss scenarios in case of
          failures on null ES ACs (Attachment Circuits not associated to ES, with an ES;
          that is, their corresponding ESI is zero) when the access
          device/network
          device or access network is responsible for the redundancy.</t>
        </li>
        <li>
          <t>This extension described in this document MUST <bcp14>MUST</bcp14> work with
          Single-Active non-null ES ESs and virtual ES, ESs, irrespective of the PE
          B-MAC address assignment (dedicated per-ES B-MAC or shared B-MAC, as
          in <xref target="RFC7623"/>).</t> target="RFC7623" format="default"/>).</t>
        </li>
        <li>
          <t>In case of failure on the egress PE, the solution MUST <bcp14>MUST</bcp14> provide a
          C-MAC-flush
          C-MAC flush notification at the B-MAC and I-SID granularity level.</t>
        </li>
        <li>
          <t>The solution MUST <bcp14>MUST</bcp14> provide a reliable C-MAC-flush C-MAC flush notification in
          PBB-EVPN networks that use Route-Reflectors Route Reflectors (RRs). MAC flushing
          needs to be provided to all affected I-SIDs in spite of the BGP
          flush notification messages being aggregated at the RR.</t>
        </li>
        <li>
          <t>The solution MUST <bcp14>MUST</bcp14> coexist in <xref target="RFC7623"/> target="RFC7623" format="default"/> networks
          where there are PEs that do not support this specification.</t>
        </li>
        <li>
          <t>The solution SHOULD <bcp14>SHOULD</bcp14> be enabled/disabled enabled or disabled by an administrative
          option on a per-PE and per-I-SID basis (as opposed to be always being
          enabled for all the I-SIDs).</t>
        </list></t>
        </li>
      </ol>
    </section>
    <section anchor="sect-3"
             title="EVPN numbered="true" toc="default">
      <name>EVPN BGP Encoding for ISID-based C-MAC-flush"> I-SID-Based C-MAC Flush</name>
      <t>The solution does not use any new BGP attributes but reuses the MAC
      Mobility extended community as an indication of C-MAC-flush C-MAC flush (as in <xref
      target="RFC7623"/>)
      target="RFC7623" format="default"/>) and encodes the I-SID in the
      Ethernet Tag field of the EVPN MAC/IP advertisement route. As a
      reference, <xref
      target="ure-cmac-flush-notification-encoding-bmac-isid-route"/>
      target="ure-cmac-flush-notification-encoding-bmac-isid-route"
      format="default"/> shows the MAC Mobility extended community and the
      EVPN MAC/IP advertisement route that are used as specified in <xref target="RFC7432"/>
      target="RFC7432" format="default"/> and used in this document as a C-MAC-flush
      C-MAC flush notification message.</t>
      <figure anchor="ure-cmac-flush-notification-encoding-bmac-isid-route"
              title="CMAC-Flush notification encoding: BMAC/ISID route">
        <artwork><![CDATA[ anchor="ure-cmac-flush-notification-encoding-bmac-isid-route">
        <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06     | Sub-Type=0x03 |   Flags       |   Reserved=0  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sequence Number                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            +---------------------------------------+
            |  Route Distinguisher                  |
            +---------------------------------------+
            |  ESI = 0                              |
            +---------------------------------------+
            |  Ethernet Tag ID = I-SID              |
            +---------------------------------------+
            |  MAC Address Length = 48              |
            +---------------------------------------+
            |  B-MAC Address                        |
            +---------------------------------------+
            |  IP Address Length = 0                |
            +---------------------------------------+
            |  MPLS Label1                          |
            +---------------------------------------+
]]></artwork>
      </figure>
      <t>Where:</t>

      <t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>The route's route distinguisher and route targets are the ones
          corresponding to its EVI. Alternatively to the EVI's RT, Route Target (RT), the route
          MAY
          <bcp14>MAY</bcp14> be tagged with an RT auto-derived from the Ethernet Tag (I-SID)
          instead. <xref target="RFC7623"/> target="RFC7623" format="default"/> describes how the EVPN MAC/IP
          Advertisement routes can be advertised along with the EVI RT or an
          RT that is derived from the I-SID.</t>
        </li>
        <li>
          <t>The Ethernet Tag encodes the I-SID for which I-SID. This indicates to the PE that receives
          the route it must flush the C-MACs for that encoded I-SID, upon reception of the route.</t>
        </li>
        <li>
          <t>The MAC address field encodes the B-MAC Address for which address. This indicates to the PE that receives the route it must flush the C-MACs associated with that encoded B-MAC, upon reception of the route.</t>
        </li>
        <li>
          <t>The MAC Mobility extended community is used as in <xref
          target="RFC7623"/>, target="RFC7623" format="default"/>, where an increment in the sequence number
          between two updates for the same B-MAC/I-SID will be interpreted as
          a C-MAC-flush C-MAC flush notification for the corresponding B-MAC and
          I-SID.</t>
        </list></t>
        </li>
      </ul>
      <t>All the other fields are set and used as defined in <xref
      target="RFC7623"/>.
      target="RFC7623" format="default"/>. This document will refer to this
      route as the
      B-MAC/I-SID route, "B-MAC/I-SID route", as opposed to the EVPN MAC/IP
      Advertisement route used in <xref target="RFC7623"/> target="RFC7623" format="default"/>
      that contains a specific B-MAC, B-MAC and the Ethernet Tag ID set to
      zero. This document uses the term B-MAC/0 route "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
      any RR as specified in <xref target="RFC7432"/> RR, 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
      update only in the case of supporting the procedures described in this
      document.</t>
    </section>
    <section anchor="sect-4" title="Solution description"> numbered="true" toc="default">
      <name>Solution Description</name>
      <t><xref target="pbb-evpn-and-non-es-based-redundancy"/> target="pbb-evpn-and-non-es-based-redundancy" format="default"/> will be used in
      the description of the solution. CE1, CE2 CE2, and CE3 are connected to ACs
      associated to with I-SID1, where no (Multi-Homed) Ethernet Segments (multihomed) ESs have been
      enabled, and the ACs and PWs are in active or standby state as per <xref
      target="pbb-evpn-and-non-es-based-redundancy"/>.</t> target="pbb-evpn-and-non-es-based-redundancy" format="default"/>.</t>
      <t>Enabling or disabling I-SID-based C-MAC-flush SHOULD C-MAC flush <bcp14>SHOULD</bcp14> be an
      administrative choice on the system that MAY <bcp14>MAY</bcp14> be configured per I-SID
      (I-Component, Service Instance Component), as opposed to being
      configured for all I-SIDs. When enabled on a PE:</t>

      <t><list style="letters">
      <ol spacing="normal" type="a"><li>
          <t>The PE will be able to generate B-MAC/I-SID routes as C-MAC-Flush C-MAC Flush
          notifications for the remote PEs.</t>
        </li>
        <li>
          <t>The PE will be able to process B-MAC/I-SID routes received from
          remote PEs.</t>
        </list></t>
        </li>
      </ol>
      <t>The PE MUST <bcp14>MUST</bcp14> follow the <xref target="RFC7623"/> procedures in <xref target="RFC7623" format="default"/> for
      C-MAC-flush.
      C-MAC flush. This specification brings provides some additional procedures when
      I-SID-based C-MAC-flush C-MAC flush is enabled.</t>
      <t>This C-MAC-flush C-MAC flush specification is described in three sets of
      procedures:</t>

      <t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>I-SID-based C-MAC-flush C-MAC flush activation</t>

          <t>C-MAC-flush
        </li>
        <li>
          <t>C-MAC flush notification generation upon AC failures</t>

          <t>C-MAC-flush
        </li>
        <li>
          <t>C-MAC flush process upon receiving a C-MAC-flush C-MAC flush notification</t>
        </list></t>
        </li>
      </ul>
      <section anchor="sect-4.1"
               title="ISID-based C-MAC-Flush activation procedures"> numbered="true" toc="default">
        <name>I-SID-Based C-MAC Flush Activation Procedures</name>
        <t>The following behavior MUST <bcp14>MUST</bcp14> be followed by the PBB-EVPN PEs
        following this specification. <xref
        target="pbb-evpn-and-non-es-based-redundancy"/> target="pbb-evpn-and-non-es-based-redundancy" format="default"/> is used as a
        reference.</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>As in <xref target="RFC7623"/>, target="RFC7623" format="default"/>, each PE advertises a shared
            B-MAC in a B-MAC/0 route (with B-MAC1, B-MAC2, B-MAC3 B-MAC3, and B-MAC4
            in the MAC address field, respectively). This is the B-MAC that
            each PE will use as B-MAC SA (Source Address) when encapsulating
            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
            install the B-MACs in its B-component (Backbone Component)
            MAC-VRF. For instance, PE1 will advertise B-MAC1/0 and will
            install B-MAC2, B-MAC3 B-MAC3, and B-MAC4 in its MAC-VRF.</t>
          </li>
          <li>
            <t>Assuming I-SID-based C-MAC-flush C-MAC flush is activated for I-SID 1, I-SID1, the
            PEs will advertise the shared B-MAC with I-SID 1 I-SID1 encoded in the
            Ethernet Tag. That is, PE1 will advertise B-MAC1/1 and will
            receive B-MAC2/1, B-MAC3/1 B-MAC3/1, and B-MAC4/1. The receiving PEs MUST
            <bcp14>MUST</bcp14> use these B-MAC/I-SID routes only for C-MAC-flush
            C-MAC flush procedures and they MUST NOT <bcp14>MUST NOT</bcp14> be used them to
            add/withdraw any B-MAC entry in the MAC-VRFs. As per <xref target="RFC7623"/>,
            target="RFC7623" format="default"/>, only B-MAC/0 routes can be
            used to add/withdraw B-MACs in the MAC-VRFs.</t>
          </li>
          <li>
            <t>The above procedure MAY <bcp14>MAY</bcp14> also be used for dedicated B-MACs
            (B-MACs allocated per Ethernet Segment).</t>
          </list></t> ES).</t>
          </li>
        </ul>
      </section>
      <section anchor="sect-4.2" title="C-MAC-Flush generation"> numbered="true" toc="default">
        <name>C-MAC Flush Generation</name>
        <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
        community where the Sequence Number has been incremented. The
        reception of the B-MAC1/1 with an increment in the sequence number
        will trigger the C-MAC-flush C-MAC flush procedures on the receiving PEs.</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>An AC going operationally down MUST <bcp14>MUST</bcp14> generate a B-MAC/I-SID with
            a higher Sequence Number. If the AC going down makes the entire
            local I-SID go operationally down, the PE will withdraw the
            B-MAC/I-SID route for the I-SID.</t>
          </li>
          <li>
            <t>An AC going operationally up SHOULD NOT <bcp14>SHOULD NOT</bcp14> generate any
            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>
          </li>
          <li>
            <t>An AC receiving a G.8032 flush notification or a flush message
            in any other protocol from the access network MAY <bcp14>MAY</bcp14> propagate it to
            the remote PEs by generating a B-MAC/I-SID route update with a
            higher Sequence Number.</t>
          </list></t>
          </li>
        </ul>
      </section>
      <section anchor="sect-4.3"
               title="C-MAC-flush process numbered="true" toc="default">
        <name>C-MAC Flush Process upon receiving Receiving a CMAC-flush notification"> C-MAC Flush Notification</name>
        <t>A PE receiving a C-MAC-flush C-MAC flush notification will follow these
        procedures:</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>A received B-MAC/I-SID route (with a non-zero I-SID) MUST NOT <bcp14>MUST NOT</bcp14>
            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
            increment Sequence Number, MUST Number <bcp14>MUST</bcp14> flush all the C-MACs associated to with
            that I-SID and B-MAC. C-MACs associated to with the same I-SID but
            different B-MAC MUST NOT <bcp14>MUST NOT</bcp14> be flushed.</t>
          </li>
          <li>
            <t>A received B-MAC/I-SID withdraw (with a non-zero I-SID) MUST <bcp14>MUST</bcp14>
            flush all the C-MACs associated to with that B-MAC and I-SID.</t>
          </list></t>
          </li>
        </ul>
        <t>Note that the C-MAC-flush C-MAC flush procedures described in <xref
        target="RFC7623"/> target="RFC7623" format="default"/> for B-MAC/0 routes are still valid and a PE
        receiving <xref target="RFC7623"/> C-MAC-flush target="RFC7623" format="default"/> C-MAC flush notification messages
        MUST
        <bcp14>MUST</bcp14> observe the behavior specified in <xref target="RFC7623"/>.</t> target="RFC7623" format="default"/>.</t>
      </section>
    </section>
    <section anchor="sect-5" title="Conclusions"> numbered="true" toc="default">
      <name>Conclusions</name>
      <t>The I-SID-based C-MAC-flush C-MAC flush solution described in this document has
      the following benefits:</t>

      <t><list style="letters">
      <ol spacing="normal" type="a"><li>
          <t>The solution solves black-hole packet-loss scenarios in case of failures on
          null ES ACs, since the C-MAC-flush C-MAC flush procedures are independent of the
          Ethernet Segment
          ES definition.</t>
        </li>
        <li>
          <t>This extension can also be used with Single-Active non-null ES ESs
          and virtual ES, ESs, irrespective of the PE B-MAC address assignment
          (dedicated per-ES B-MAC or shared B-MAC).</t>
        </li>
        <li>
          <t>It provides a C-MAC-flush C-MAC flush notification at B-MAC and I-SID
          granularity level, therefore flushing a minimum number of C-MACs and
          reducing the amount of unknown unicast flooding in the network.</t>
        </li>
        <li>
          <t>It provides a reliable C-MAC-flush C-MAC flush notification in PBB-EVPN
          networks that use RRs. RRs will propagate the C-MAC-flush C-MAC flush
          notifications for all the affected I-SIDs and I-SIDs, irrespective of the
          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
          not supporting this specification. Non-supporting systems ignore the
          B-MAC/I-SID routes, however routes; however, they still follow the C-MAC-flush C-MAC flush
          procedures in <xref target="RFC7623"/>.</t>
        </list></t> target="RFC7623" format="default"/>.</t>
        </li>
      </ol>
    </section>
    <section anchor="sect-7" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Security considerations described in <xref target="RFC7623"/> target="RFC7623" format="default"/> apply
      to this document.</t>
      <t>In addition, this document suggests additional procedures, procedures that can
      be activated on a per I-SID basis, basis and generate additional EVPN MAC/IP
      Advertisement routes in the network. The format of these additional EVPN
      MAC/IP Advertisement routes is backwards compatible with <xref
      target="RFC7623"/> the procedures in <xref target="RFC7623" format="default"/> and should not create any issues on for
      receiving PEs that do not following follow this specification, however, specification. However, the additional
      routes may consume extra memory and processing resources on the
      receiving PEs. Because of that, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to activate this
      feature only when necessary (when multi-homed multihomed networks or devices are
      attached to the PBB-EVPN PEs), and not by default in any PBB-EVPN
      PE.</t>
    </section>
    <section anchor="sect-8" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document requests has no actions from IANA.</t> 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 anchor="sect-10" title="Contributors"/>
   </middle>
  <back>
    <references title="Normative References">
      &RFC7623;

      &RFC7432;

      &RFC2119;

      &RFC8174;

<displayreference target="I-D.ietf-bess-evpn-virtual-eth-segment" to="EVPN-VIRTUAL-ES"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7623.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

    <references title="Informative References">
      &I-D.ietf-bess-evpn-virtual-eth-segment;

      &RFC4762;
      <references>
        <name>Informative References</name>

<!--[I-D.ietf-bess-evpn-virtual-eth-segment] IESG state Publication Requested -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-virtual-eth-segment.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4762.xml"/>

<reference anchor="G.8032"> anchor="G.8032" target="https://www.itu.int/rec/T-REC-G.8032-202003-I/en">
     <front>
          <title>Recommendation ITU-T G.8032/Y.1344, Ethernet
       <title>Ethernet ring protection switching</title>
       <author>
            <organization/>
         <organization>ITU-T</organization>
       </author>
       <date month="March" year="2020"/> year="2020" />
     </front>
     <seriesInfo name="ITU-T Recommendation" value="G.8032/Y.1344"/>
   </reference>
      </references>
    </references>

   <section anchor="sect-9" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <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>

  </back>
</rfc>